模板
教程
環境
性能
功能
管理
送給你的代碼審查問題手冊
代碼審查列表，是代碼審查的明確規則和指導手冊，它可以使代碼審查為你的團隊帶來更多好處，并且能夠顯著提升代碼審查的速度。
研究表明，使用代碼審查列表的審閱者的表現要優于不使用的審閱者。所以不管你是新手開發者還是經驗豐富的開發者，開始考慮使用代碼審查列表吧。
代碼作者應該關注的列表
作為代碼的作者，你應該保證：
除此之外，作為代碼作者，也應該在提交審查之前，按照審查者的列表對自己的代碼進行審查。
代碼審查者應該關注的列表
作為代碼審查者，你的任務是尋找最重要的問題。評論會要對代碼的結構性或邏輯性問題更有價值，即使有時候會顯得挑剔。
你應該知道什么是好的代碼反饋。另外需要注意，最好的代碼審查反饋不是點評，而是建議。所以不要說“變量名稱應該是removeObject“，最好說”調用變量removeObject怎么樣？“。
下面這份列表足夠幫助你提出好的代碼審查反饋了。
實現
-
此代碼更改會執行它應該做的事情嗎？
-
這種解決方法是最簡單的嗎？
-
這個更改有引入一些不需要的編譯時或運行時的依賴嗎？
-
是否使用了不應該使用的框架、API、庫、服務？
-
是否存在可以提升解決方法的未使用的框架、API、庫、服務？
-
代碼是否處于正確的抽象級別？
-
代碼是否的模塊化做的是否足夠好？
-
是否已經存在類似功能的函數？如果有，為什么不復用？
-
是否有最佳實踐、設計模式或特定語言模式可以優化代碼？
-
代碼是否遵循面向對象的分析和設計原則，例如單一責任原則，開閉原則，里氏替換原則，接口隔離，依賴注入？
邏輯錯誤或Bug
-
你能想到代碼不按預期運行的任何用例嗎？
-
你能想到任何可能破壞代碼的輸入或外部事件嗎？
錯誤處理和日志
-
錯誤都被正確處理了嗎？
-
是否有需要增加或刪除的日志/debug信息？
-
錯誤消息對用戶是否友好？
-
是否有足夠的日志，它們的編寫方式是否是易于調試的？
可用性和可訪問性
-
從可用性角度出發，所提出的解決方案是否設計合理？
-
API文檔是否足夠好？
-
提出的解決方案是否具備可訪問性？
-
API/UI是否直觀易用？
測試與可測試性
依賴
-
如果這個修改需要更新代碼以外的文件，例如更新文檔，配置，readme文件。是否完成了這些更新？
-
這個修改是否會對系統其他地方造成影響？是否能夠向后兼容？
安全和隱私數據
-
這段代碼是否打開軟件的安全漏洞？
-
權限和身份驗證是否被正確處理？
-
是否安全處理了敏感數據，例如用戶數據、信用卡信息等？是否正確使用加密方法？
-
代碼更改是否顯露了一些私密信息（如迷藥，用戶名等）？
-
如果代碼處理用戶輸入，是否解決了跨站點腳本，SQL注入等安全漏洞，是否進行了輸入清洗和驗證？
-
從外部API或庫中獲得的數據是否進行了相應的檢查？
性能
-
這段代碼修改是否會對系統性能產生負面影響？
-
是否可以進一步提升代碼性能？
可讀性
-
代碼是否容易理解？
-
哪一部分使你困惑，為什么？
-
可以通過減小方法來提高代碼可讀性嗎？
-
可以通過使用不同的函數/方法或變量名稱來提升代碼可讀性嗎？
-
代碼是否存放在正確的文件/目錄/包？
-
你是否認為方法應該重構以擁有更直觀的控制流程？
-
數據流是否可理解？
-
是否有多余的注釋？
-
某些注釋是否可以更好的傳達信息？
-
是否更多的注釋會使你的代碼更容易理解？
-
是否可以移除一些注釋，通過提升代碼可讀性來理解代碼？
-
是否存在注釋掉的代碼？
專家意見
-
你是否認為特定專家（如安全專家或可用性專家）應該先檢查代碼，然后再提交代碼？
-
這個代碼修改會影響其他團隊嗎？他們也應該發表意見嗎？
好了，以上就是最為緊迫的一些問題列表。
代碼風格和約定
您的團隊或公司必須擁有清晰的編碼風格指南，這一點很重要。因為這是在代碼庫中實施唯一性的唯一方法。并且一致性會使代碼審查更快，使人們可以輕松地更改項目，并保持您代碼的可讀性和可維護性。
Google是做到這一點的很好的例子，無疑，這使Google可以進行快速的代碼審查。
首先，我建議使用現成的編碼樣式來支持Google提供的多種語言。設定基本規則很重要，但要確保一勞永逸。不要持續爭論。
盡可能自動化
確定了代碼風格以后，請花一些時間正確安裝和配置工具，以便一鍵格式化代碼。
另外還有很多事情可以做。例如使用靜態檢查來代替部分人工審核。這是值得為之努力的。
完整問題列表
原文轉自：https://www.michaelagreiler.com/code-review-checklist/
