快來領取這份程式碼審查問題手冊！

程式碼審查列表，是程式碼審查的明確規則和指導手冊，它可以使程式碼審查為你的團隊帶來更多好處，並且能夠顯著提升程式碼審查的速度。

研究表明，使用程式碼審查列表的審閱者的表現要優於不使用的審閱者。所以不管你是新手開發者還是經驗豐富的開發者，開始考慮使用程式碼審查列表吧。

程式碼作者應該關注的列表

作為程式碼的作者，你應該保證：

• 程式碼編譯成功並且通過靜態檢查（沒有警告）
• 程式碼通過所有的測試（單元測試、整合測試和系統測試）
• 你已經仔細檢查了拼寫錯誤，並做了處理（註釋、todo等）
• 概述程式碼修改的原因以及修改了哪些地方

除此之外，作為程式碼作者，也應該在提交審查之前，按照審查者的列表對自己的程式碼進行審查。

程式碼審查者應該關注的列表

作為程式碼審查者，你的任務是尋找最重要的問題。評論會要對程式碼的結構性或邏輯性問題更有價值，即使有時候會顯得挑剔。

你應該知道什麼是好的程式碼反饋。另外需要注意，最好的程式碼審查反饋不是點評，而是建議。所以不要說“變數名稱應該是removeObject“，最好說”呼叫變數removeObject怎麼樣？“。

下面這份列表足夠幫助你提出好的程式碼審查反饋了。

實現

• 此程式碼更改會執行它應該做的事情嗎？
• 這種解決方法是最簡單的嗎？
• 這個更改有引入一些不需要的編譯時或執行時的依賴嗎？
• 是否使用了不應該使用的框架、API、庫、服務？
• 是否存在可以提升解決方法的未使用的框架、API、庫、服務？
• 程式碼是否處於正確的抽象級別？
• 程式碼是否的模組化做的是否足夠好？
• 你是否有其他的解決方案，該方案在程式碼可維護性、可讀性、效能、安全方面表現更好？
• 是否已經存在類似功能的函式？如果有，為什麼不復用？
• 是否有最佳實踐、設計模式或特定語言模式可以優化程式碼？
• 程式碼是否遵循面向物件的分析和設計原則，例如單一責任原則，開閉原則，里氏替換原則，介面隔離，依賴注入？

邏輯錯誤或Bug

• 你能想到程式碼不按預期執行的任何用例嗎？
• 你能想到任何可能破壞程式碼的輸入或外部事件嗎？

錯誤處理和日誌

• 錯誤都被正確處理了嗎？
• 是否有需要增加或刪除的日誌/debug資訊？
• 錯誤訊息對使用者是否友好？
• 是否有足夠的日誌，它們的編寫方式是否是易於除錯的？

可用性和可訪問性

• 從可用性角度出發，所提出的解決方案是否設計合理？
• API文件是否足夠好？
• 提出的解決方案是否具備可訪問性？
• API/UI是否直觀易用？

測試與可測試性

• 程式碼是否達到可測試標準？
• 是否有足夠的自動化測試（單元測試/整合測試/系統測試）？
• 現有測試是否合理覆蓋程式碼變更？
• 是否有額外的測試用例、輸入或邊界用例以供測試？

依賴

• 如果這個修改需要更新程式碼以外的檔案，例如更新文件，配置，readme檔案。是否完成了這些更新？
• 這個修改是否會對系統其他地方造成影響？是否能後向後相容？

安全和隱私資料

• 這段程式碼是否開啟軟體的安全漏洞？
• 許可權和身份驗證是否被正確處理？
• 是否安全處理了敏感資料，例如使用者資料、信用卡資訊等？是否正確使用加密方法？
• 程式碼更改是否顯露了一些私密資訊（如迷藥，使用者名稱等）？
• 如果程式碼處理使用者輸入，是否解決了跨站點指令碼，SQL注入等安全漏洞，是否進行了輸入清洗和驗證？
• 從外部API或庫中獲得的資料是否進行了相應的檢查？

效能

• 這段程式碼修改是否會對系統性能產生負面影響？
• 是否可以進一步提升程式碼效能？

可讀性

• 程式碼是否容易理解？
• 哪一部分使你困惑，為什麼？
• 可以通過減小方法來提高程式碼可讀性嗎？
• 可以通過使用不同的函式/方法或變數名稱來提升程式碼可讀性嗎？
• 程式碼是否存放在正確的檔案/目錄/包？
• 你是否認為方法應該重構以擁有更直觀的控制流程？
• 資料流是否可理解？
• 是否有多餘的註釋？
• 某些註釋是否可以更好的傳達資訊？
• 是否更多的註釋會使你的程式碼更容易理解？
• 是否可以移除一些註釋，通過提升程式碼可讀性來理解程式碼？
• 是否存在註釋掉的程式碼？

專家意見

• 你是否認為特定專家（如安全專家或可用性專家）應該先檢查程式碼，然後再提交程式碼？
• 這個程式碼修改會影響其他團隊嗎？他們也應該發表意見嗎？

好了，以上就是最為緊迫的一些問題列表。

程式碼風格和約定

您的團隊或公司必須擁有清晰的編碼風格指南，這一點很重要。因為這是在程式碼庫中實施唯一性的唯一方法。並且一致性會使程式碼審查更快，使人們可以輕鬆地更改專案，並保持您程式碼的可讀性和可維護性。

Google是做到這一點的很好的例子，無疑，這使Google可以進行快速的程式碼審查。

首先，我建議使用現成的編碼樣式來支援Google提供的多種語言。設定基本規則很重要，但要確保一勞永逸。不要持續爭論。

儘可能自動化

確定了程式碼風格以後，請花一些時間正確安裝和配置工具，以便一鍵格式化程式碼。

另外還有很多事情可以做。例如使用靜態檢查來代替部分人工稽核。這是值得為之努力的。

完整問題列表

原文連結

https://www.michaelagreiler.com/code-review-checkli