程式碼審查
審查使用者指出的變更（diff、分支、PR 或未提交的工作樹）。如果使用者未指定，則審查未提交的變更，然後是相對於其基礎分支的當前分支。
如何審查
- 先理解意圖。 閱讀 PR 描述、提交訊息和關聯的議題。只有在相對於其試圖達成的目標時，變更才可能出錯。
- 閱讀完整 diff，然後是周邊程式碼。 開啟已變更的函式及其呼叫者。大多數真正的錯誤存在於新程式碼和現有程式碼之間的邊界。
- 按此順序檢查：
- 正確性：邏輯錯誤、差一錯誤、錯誤條件、未處理的
null/空值/錯誤情況、競爭條件、資源洩漏、中斷的錯誤傳遞。 - 行為變更：未附帶遷移腳本或說明的公用 API、檔案格式、預設值或資料庫架構變更。
- 安全性：未受信任的輸入到達查詢、shell、檔案路徑、HTML 或反序列化器；程式碼或日誌中的機密；遺失的授權檢查。
- 測試：如果還原變更，測試是否會失敗？是否涵蓋了邊界情況？
- 可讀性：誤導的名稱、做兩件事的函式、與程式碼矛盾的註解、無用程式碼。
- 正確性：邏輯錯誤、差一錯誤、錯誤條件、未處理的
- 在報告前驗證。 對於每個懷疑的錯誤，追蹤一個能觸發它的具體輸入。丟棄任何無法具體化的內容，或將其標記為問題。
如何報告
- 以一行結論開頭：準備好合併、修復後合併，或需要重做。
- 先列出最嚴重的發現。對於每個發現：
file:line、出了什麼問題、具體的失敗情境，以及建議的修復方式。 - 將必須修復與建議和問題分開。
- 不要為了格式化工具或 linter 會捕捉的風格問題而填充審查內容，也不要複述 diff 做了什麼。
- 如果值得注意，請說出優點（例如清晰的測試、謹慎的遷移）。保持在一行內。