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