【CSDN 編者按】這篇文章詳細讨論了如何進行高效的代碼審查，包括作者和審查者應遵循的指導原則。文章強調了尊重審查者的時間，自我審查代碼，将大的更改清單分解為小的、邏輯上的單元，自動化簡單的任務，限制代碼更改的範圍，優雅地接受批評，最小化審查回合之間的延遲，明确地溝通響應，不忘記文檔等。同時，審查者也需要驗證代碼是否必要、設計得當，是否易讀、清晰，注釋是否解釋了“為什麼”而不是“做什麼”，代碼是否過于複雜，是否遵循風格指南，是否經過充分的測試和文檔記錄等，對代碼審查實戰具有極大的參考價值。
原文連結：https://addyosmani.com/blog/code-reviews/
未經允許，禁止轉載！
作者 | Addy Osmani 譯者 | 明明如月
責編 | 夏萌出品 | CSDN（ID：CSDNnews）
代碼審查是作者和審查者共同學習、分享知識并提升軟體品質的有效途徑。它是我們走向卓越的一條必經之路。以下是有助于讓作者和審查者以更高效、更建設性的方式來進行代碼審查的一些建議。
尊重審查者的時間
在高效的代碼審查過程中，尊重審查者的時間至關重要。
這裡有一些面向作者的建議：
對自己的代碼進行自我審查
在将代碼送出審查之前，你應該先自己檢查一遍代碼。找出拼寫錯誤、邏輯錯誤以及需要改進的地方。這樣的初步審查可以幫助你在審查者介入之前就發現并改正一些小問題。
将大的變更拆分成小的變更
審查小而可管理的代碼塊比審查大塊的代碼更為容易、更為高效。通過将修改内容分解為更小、邏輯清晰的部分，這樣可以讓審查過程更順暢，也可以減輕審查者的壓力。
自動化簡單的任務
盡可能利用現有工具來自動化如 linting （一個代碼檢查過程，用于查找源代碼中的錯誤并标記潛在的錯誤）和格式化的任務。這樣，你可以節省審查者的時間，并確定你的代碼符合團隊的标準，無需人工幹預。這種方式通常需要在團隊或項目層面預先進行協調。
縮小變更的範圍
你的代碼變更應該盡可能地具體和緊湊。包含無關的變更會讓審查者難以了解，增大漏過錯誤的機會。
積極接受批評
你應對建設性的批評保持開放的态度，并視其為學習的機會。每個人都會犯錯誤，我們可以借助代碼審查從錯誤中學習。
減少審查回合之間的延遲
及時回應審查評論可以幫助保持審查流程的連續性，減少每次審查所花費的時間。
主動尋求缺失的資訊
如果你對某件事情感到不确定，應該主動進行積極的對話，以便讓作者或審閱者得到更多的資訊或解釋。建設性的對話可以讓作者和審查者都有所收獲。
清晰地傳達回報
始終要清晰地傳達你的改動。即使你已經根據審查者的建議進行了修改，也應明确地告知對方。
不要忘記編寫文檔
良好的文檔和代碼本身同樣重要。文檔提供了上下文，解釋了代碼為何以及如何工作，這使得其他人更容易了解你的代碼。同樣，對于其他期望的項目部分，如測試，也應編寫相應的文檔。
審查者的職責：驗證代碼是否...
必需且設計合理
在審查代碼時，你需要驗證代碼是否真正必要，以及是否可以與現有的代碼庫相容。所有的代碼部分都應該能與系統的其他部分順暢地互動，共同提升系統的整體功能。
易于閱讀且目标明确
代碼應清晰易懂，目标明确，這不僅對最終使用者有益，對未來的維護者也是如此。
注釋以“為什麼”為主，而非“做了什麼”
注釋應解釋代碼存在的理由，而非它在做什麼。遵循這個原則有助于了解代碼背後的思想和設計。
盡量避免編寫過于複雜的代碼
複雜的代碼更難維護，更容易出錯。是以，代碼應該盡可能地簡潔，同時又能實作所需的功能。
遵循樣式指南（Style Guide）
代碼應遵循團隊的程式設計樣式指南。所有主要的樣式修改應該與主要的變更清單分開進行。
充分測試且配有詳細的文檔說明
代碼應配有适當的測試，并且有詳盡的文檔描述。這種做法有助于保持代碼的完整性，并幫助其他人更好地了解它。
保證代碼審查的建設性
評論要針對代碼，而非開發者。評價程式設計技能不應作為代碼審查的環節。應避免輕率或含糊的評論，反之，評論應清晰、具體，并适當地給出積極回報。盡可能避免過度苛求細節，讓自動化的樣式檢查來處理微小問題。
标準很多，需要抓重點
在審查代碼的過程中，需要考慮的關鍵标準包括：代碼是否滿足需求、邏輯是否正确和安全、性能、健壯性和可觀察性如何、是否存在不必要的複雜性、API 和内部結構是否清晰以及是否引入了破壞性的變更。
總的來說，代碼審查應當是尊重的、有建設性的，并且聚焦的。作者和審查者在保證代碼品質以及確定其長期可維護性方面都扮演着關鍵角色。記住要保持開放的心态，并始終緻力于提升自我。祝你審查愉快！
你在代碼審查實踐過程中還有其他經驗嗎？歡迎在評論區分享你的觀點和建議。
粉絲福利：