讓我們來談談程式碼審查（Code Review）。如果花幾秒鐘去搜尋有關內容，你會發現許多論述程式碼審查好處的文章（例如，Jeff Atwood的這篇文章）。你還會發現許多介紹如何使用程式碼審查工具的文件，比如我們常用的Upsource。但能夠在你審查他人程式碼時指導查什麼的內容卻很少見。

或許沒有明確審查條目的原因是：有太多不同的因素需要考慮。就像對任何（功能性或非功能性）需求，個體組織對各個方面的優先順序都有不同的考慮。

由於文章主題覆蓋面廣，本文旨在概述了程式碼審查者在程式碼審查時可以關注的一些方面。各方面優先順序的分配和持續檢查是一個非常複雜課題，具有研究價值。

審查他人程式碼時，查什麼？

無論是使用 Upsource 類似工具審查程式碼，還是在同事查他們程式碼期間，不管哪種情況，相比較而言評審有些內容要更容易。例如：

• 格式：在什麼地方放置空格和斷行符？使用製表符還是空格？大括號如何放置？
• 風格：變數、引數是否宣告為final？函式變數的定義是否與呼叫程式碼或函式開始程式碼太相似？
• 命名：域、常量、變數、引數、類的名稱是否符合標準？命名是否太短？
• 覆蓋測試：這段程式碼是否進行了測試？

這些檢查都是有意義的——你希望儘可能減少不同程式碼間的上下文切換並減少認知負荷，那麼程式碼看上去越一致越好。（譯者注：認知負荷（Cognitive Load）是指人在完成任務過程中進行資訊加工所需要的認知資源的總量。）

但是，人工審查這些內容可能沒有充分利用團隊的時間和資源，因為其中大部分檢查可以自動化。許多工具都能確保程式碼格式一致，包括命名和 final 關鍵字的使用規範，而且能發現簡單程式設計錯誤造成的常見bug。例如，你在命令列中執行IntelliJ IDEA的檢查，那麼就不需要所有團隊成員在他們的整合開發環境中進行相同的檢查。

你應該審查什麼？

哪些事情適合程式碼審查者做？在程式碼審查時，哪些事情是工具不能代勞的？

事實上，程式碼審查者可以做的事情很多。當然，下面給出的不是一份詳盡的列表，這裡也不會深入探討其中的任何一項。相反，這應該是團隊交流的起點，現在你們在程式碼審查中關注什麼，也許正是你們需要審查的內容。

設計

• 新程式碼是否與整體架構匹配？
• 程式碼是否遵循SOLID原則、領域驅動設計以及團隊喜愛的其它設計模式。
• 新程式碼採用哪些設計模式？這些模式合適嗎？
• 如果程式碼庫採用混合標準或設計風格，新程式碼是否符合當前風格？程式碼遷移是按正確的方向進行，還是效仿即將被淘汰的陳舊程式碼？
• 程式碼是否處於正確的位置？例如，如果程式碼執行與順序有關，它是否能按順序執行？
• 新程式碼能否複用部分已存在程式碼？新程式碼能否給已存在程式碼提供複用部分？
• 新程式碼是否包含冗餘程式碼？如果包含，是應該重構成更加可複用部分，還是在這個階段能接受這種冗餘？
• 程式碼是否超出設計標準？這種複用構造現在是不是不需要？團隊如何根據YAGNI權衡複用？

可讀性與可維護性

• 命名（欄位、變數、引數、函式以及類）能否反映它們代表的事物？
• 通過閱讀程式碼，我能否理解程式碼的目的？
• 我能否理解測試的目的？
• 測試是否覆蓋了絕大部分情況？是否覆蓋常見情況和異常情況？是否存在沒考慮到的情況？
• 異常錯誤訊息是否易於理解？
• 難以理解的程式碼段是否進行了備註、評論或者使用易懂的測試案例進行覆蓋（符合團隊的偏好）？

功能

• 程式碼的實際工作是否符合預期？如果有自動化測試來確保程式碼的正確，測試能否測出程式碼滿足約定要求？
• 程式碼看上去是否含有細微錯誤，比如使用錯誤變數進行檢查，或者把 or 誤用為 and？

你是否考慮過……？

• 程式碼中是否存在潛在的安全問題？
• 是否需要滿足規範要求？
• 對於沒有覆蓋自動化效能測試的程式碼段，新程式碼是否引入了不可避免的效能問題，比如不必要的資料呼叫或遠端服務？
• 作者是否需要建立公共文件，或者修改現有的幫助文件。
• 展示給使用者的訊息是否檢查無誤？
• 是否存在導致產品崩潰的明顯錯誤？程式碼是否會意外指向測試資料庫，或者是否有應該替換成真正服務的硬編碼存根程式碼？

請關注本部落格中詳細探究這些主題的文章。

如何編寫“良好”程式碼是每個開發者都能各抒己見的主題。如果你有一些可以加入我們列表的內容，希望能在評論中收到你的回覆。