軟體工程
為程式碼審查準備一項變更
小型、好懂的變更請求：行為已驗證，審查脈絡與已知風險都寫明白。
流程
照這個順序做。
- 重述預定使用者或系統成果，並把差異對照該範圍。
- 在檔案與系統脈絡中審查每一行變更的設計適配、正確性、安全、並行與可避免複雜度。
- 檢查測試能因損壞行為失敗、涵蓋相關邊界案例，並符合變更風險等級。
- 執行儲存庫要求的格式、靜態檢查、型別檢查、測試、建置與文件產生。
- 移除附帶變更、產生雜訊、除錯輸出、死碼與密鑰；若無法連貫審查則拆分變更。
- 撰寫拉取請求摘要，涵蓋為何、做了什麼、驗證證據、相關時的截圖或遷移說明、風險與回復。
先準備
貓會向你要的輸入。
- 變更分支或差異
- 議題或驗收準則
- 儲存庫貢獻與測試說明
路由器 + 一份 playbook
先路由。只選一份。
Cat Paw 每次任務只載入一份 playbook，不合併多份。先走這個路由器；其餘路徑是此 workflow 可檢查的候選。
- 路由器：
engineering-pack skills/engineering/mattpocock/code-review/SKILL.md
界線
界線跟著提示一起走。
- 未經執行不要宣稱檢查已通過。
- 不要在差異或證據中暴露憑證、權杖或個人資料。
- 把安全、隱私、無障礙或並行等專業領域升級給合格審查者。
完成代表
一個可核對的終點。
差異範圍清楚且可解釋，必要本機檢查通過，審查成品完整，沒有未決高嚴重自我審查發現。
來源
這個流程從哪來。
- google.github.io/eng-practices/review/reviewer/looking-for.html
- google.github.io/eng-practices/review/developer/small-cls.html
來源確立 workflow 的模式。若有 Reddit 或社群貼文，視為實務軼事，不是普遍事實。
