代碼審查不是戰場，審查員也不是作者的對手。他們的目標是一致的——解決產品問題並創建高質量的代碼庫。讓我們深入探討並瞭解如何從審查者的角度進行一次代碼審查。

不要浪費時間

總有些問題時常重複出現。先是在一個拉取請求中，然後又在另一個拉取請求中；先是來自一個作者，然後又來自另一個作者。這些問題完全相同，這就是例行公事。事實上，如果某件事情可以自動化，那麼它就必須自動化。

代碼風格。沒有必要為代碼風格而爭論不休，因為早在幾十年前，項目中的每個人或整個社區就已經對代碼風格進行了多次定義。在 linter（代碼檢查工具） 和 formatter（格式化工具） 中設置字符串的長度、方法和類的名稱，然後忘掉它吧。

測試。要將所有測試（單元測試、集成測試、端到端測試）及其啓動、覆蓋範圍等相關事項實現自動化。只需進行設置，併為指標設定一個可接受的閾值，例如，在 PR（拉取請求）中的新代碼覆蓋率不應低於 90%，這種簡單的設置能讓很多人的工作更輕鬆。

不要自我重複（DRY）。應該將常見的重複內容集中到一個地方，以便對其進行簡單、集中的更改或修復。收集所有應用程序的代碼重複百分比，並以相同的方式進行測試。

代碼分析。代碼分析有助於收集更多數據和指標。它不僅會檢查審查中的代碼，還會檢查如何將其集成到現有生態系統中。一些分析工具會根據歷史案例提供可能存在的漏洞或安全熱點報告。將存儲庫與代碼分析工具集成，並在每次代碼審查時運行這些工具。

總結。工程師應該專注於解決問題，而不是重複常規。我可以保證的是，如果能將上述任何事件至少基本自動化，代碼審查的平均質量就會大幅提高。這能為審查人員節省時間。如果出現以下情況，就需要檢查代碼：

• 並非所有測試都通過
• 測試覆蓋率不足/低於公認的百分比
• 代碼重複率高於可接受水平
• 代碼有異味
• 意外的安全熱點

通用規則

尊重。禮貌待人，尊重作者。請記住，代碼審查的參與者是來互相幫助的，他們有着共同的目標。可以批評代碼，但絕不能批評人。

任務。在完全理解問題所在之前，不要進行代碼審查。獲取有關問題所在、實際案例、條件、重現步驟、功能受眾等信息。要求進行代碼演示、代碼評審會議，甚至只是同步會議，以明確特定任務的各個方面。

建議。當提出任何改變的建議時，解釋原因。提供背景、示例、細節和信息，並分享有關資源的鏈接——為什麼作者應該進行更新。一個詞或一行話的評論有時真的很難理解。請記住，通常任務可能有多個解決方案，因此在建議更改之前，請嘗試理解選擇此解決方案的確切原因。使用提交歷史，以及帶有良好消息的結構化提交可以提供理解的關鍵。

審查流程

下面我收集了一些真正值得關注的基本類別和問題，按照優先級從最重要的開始排序。

業務目標

深入研究，不僅要研究代碼，還要研究其背後的業務邏輯。首先，任何代碼都必須執行指定的任務並達到指定的目標。不管代碼有多好，不管它寫得有多好，如果它不能實現它的目標，它就是無用的。代碼不是為代碼而寫的。編寫代碼是為了添加新功能，開發和推動產品向前發展。不要將檢查限制在快樂路徑上，要考慮邊緣情況以及如何處理它們。所有這些都可以概括為這個問題——它能解決問題嗎?

實現

接下來，開始關注數字、指標和報告。從不同角度分析代碼。

安全性。它帶來了漏洞還是解決了漏洞？在受到攻擊時它會有多穩定？被動還是主動？比如分佈式拒絕服務攻擊（DDoS）或者任何類型的注入（如 SQL 注入、跨站腳本等）？

錯誤處理。如何正確處理錯誤？應用程序會崩潰或向錯誤跟蹤軟件發送報告嗎？它會向最終用户顯示所有堆棧跟蹤嗎？它是可恢復的失敗操作嗎?數據會被損壞或碰撞嗎？

性能。新更改後性能是否受到影響?該代碼可能導致內存泄漏？優化有多好?是否做了所有的事情來使代碼高效(緩存系統、資源池、數據壓縮等)？

集成。它如何與其他模塊和系統協同工作？是否能提高代碼的一致性？能否方便地與其他實現或集成進行交換？代碼與系統其他部分其他版本的兼容性如何（如新版本的向後兼容性）？

日誌和跟蹤。這可以簡化調試和故障排除過程，也可以使其變得更加複雜。例如，記錄集成的第三方服務的響應時間有助於識別停機時間。日誌和跟蹤是否足夠？多還是少？

仔細研究並回答這些問題，就能確定實施工具的正確選擇。

可維護性

這裏的一個主要問題是——“沒有作者的代碼如何生存？”

可讀性。代碼如同構成單詞或者句子的字母，所有的代碼組成完成後，就如同在閲讀一本書籍，不過這本“書籍”是用一種特定的語言寫的：編程語言。所以可讀性應該從字面上理解，代碼應該用寫得好的字符（如參數、變量等）構建一個故事（如類、函數），它們應該採取行動（調用其他函數、變異或不可變等）。

值得關注的問題：該代碼的可讀性如何？它可以由作者以外的人來維護嗎？命名參數、變量、函數等的可理解性如何等等。

文檔。在開發過程中，文檔可以節省大量時間，減少同步時間，簡化入職流程，總之是項目知識庫的良好存儲。

值得關注的問題：代碼文檔的質量如何？閲讀後是否會留下疑問？所有需要的 MD 文件和外部文檔是否會根據變更進行添加/更新？

可重用性。為防止代碼重複，如果多個模塊的邏輯是共通的，就可將其移至助手、實用程序等共享位置。

值得關注的問題：代碼的某些部分能否在其他地方重複使用？如果不能，其獨特性是否合理？如果是，是否為達到這一指標而進行了過度設計？

設計。代碼不應該重新發明輪子。在社區中已經有許多被認可的最佳實踐和定義好的設計模式，它們是軟件工程中常見問題的解決方案。

值得關注的問題：代碼是否採用了最佳實踐和模式？是否以正確的方式使用？

印象。代碼應當激勵以某種方式與它現在或未來產生交集的任何人，努力做到同樣出色和高質量，甚至更好。

值得關注的問題：在合併之後，代碼庫是否變得更好？其他工程師會對使用這段代碼感到興奮嗎？

代碼審查：成長的機會

做好代碼審查是一項艱鉅的工作。審核員是第一道技術質量關。在合併之前，代碼歸作者所有並由其管理，但合併之後，責任將移交給整個團隊。這就是為什麼審查員應該關注代碼的穩定、可靠和無懈可擊。代碼審查是一次成長的機會。對審閲者和作者來説都是成長。