代碼審查是軟件開發生命周期中的重要環節，它可以顯著提高代碼質量。它類似於書籍的創作過程，作者寫作完成後需要經過編輯，以確保不會出現像混淆類似"you're"和"yours"這樣的錯誤。在這個背景下，代碼審查是指對其他人的代碼進行審查和評估。
代碼審查有不同的好處：
•確保設計和實現的一致性
•優化代碼以提升性能
•是學習的機會
•知識分享和指導，以及促進團隊凝聚力
代碼審查中需要檢查的內容
在代碼審查中應該查找什麼？有許多不同的事項需要檢查，從重要性的不同層次和自動化的可能性來看：
嘗試查找以下內容：
1.功能性和設計 — 這裡，我們需要找到答案，比如：這個更改是否遵循我們期望的架構，或者它是否與系統的其他部分集成良好？它的組件之間是否具有高內聚性和低耦合性？它是否遵循了如OO、SOLID、DRY、KISS、YAGNI等健壯的原則？
2.實現 — 在這裡，我們檢查解決方案是否在邏輯上正確（它確實改變了開發人員的意圖），如果代碼比應有的復雜，等等。這段代碼是否必要？我們還要檢查是否使用了良好的設計模式。以及關鍵的內容，例如API入口點。
3.測試 — 在這裡，我們檢查是否所有測試都通過了，我們是否對所有代碼路徑和行為使用單元測試，並對外部系統（數據庫、文件系統等）使用集成測試。我們是否檢查了所有邊界條件和代碼覆蓋率在60-80%之間？
4.文檔 — 我們的PR描述添加了嗎？我們的解決方案在存儲庫的README.md或其他地方是否有文檔更新？
5.代碼風格 — 我們是否遵循了項目的代碼風格？您是否知道命名是否良好？開發人員是否為類、方法等選擇了確切的名稱？代碼是否易讀？
代碼審查金字塔
進行代碼審查的一些良好實踐
以下是進行代碼審查時的一些良好實踐：
1.嘗試首先審查自己的代碼。
在將代碼發送給同事之前，嘗試先閱讀和理解它。尋找讓人困惑的部分。在IDE之外查看您的代碼通常有助於將其視為“新”的東西，從而避免操作性盲點。
2.編寫更改的簡短描述。
這應該以高層次解釋更改內容以及為何進行這些更改的方式來解釋。
3.自動化可以自動化的部分。
將所有可以自動化的工作留給系統，例如檢查成功構建（CI）、樣式更改（代碼檢查器）、自動化測試和靜態代碼分析（例如使用SonarQube）。我們已將其集成在PR級別，因此它將在每個PR上運行並為代碼合並提供阻礙。這將使我們能夠消除不必要的討論，為更重要的討論留出空間。
4.為更大的任務與團隊成員進行啟動會議。
如果您開始處理更大的任務，特別是在設計方面，請嘗試首先與代碼所有者或將成為您的代碼審查者的人進行啟動會議。這將在實施之前達成共識，並減少在PR審查階段的工作量，避免出現意外情況。
- 不要著急
您需要了解其周圍發生了什麼 — 每一行代碼。如果需要，逐類多次閱讀。應該查看分配給審查的每一行代碼。有些代碼需要更多的思考，有些則需要更少，但這是我們在審查過程中必須做出的決定。如果需要，為口頭討論保持自己的時間。
- 友善地評論
永遠不要提及個人（您），始終將註意力集中在更改上，以問題或建議的形式提出，並留下至少一個積極的評論。用您的話解釋“為什麼”，並建議如何改進。
- 在足夠好時批準PR
不要追求完美，但要保持高標準。不要小題大做。
- 控制審查的規模
我們應該限制一次審查的代碼行數。PR應該包含盡可能少的更改文件。我更喜歡更小的增量更改而不是重大的更改。我們的大腦無法一次處理那麼多信息。每次審查的核心行數的理想數量是200到400行，通常是60到90分鐘。如果任務龐大，請將其細分為可以快速審查的較小子任務。
5.使用工具
對於所有代碼審查，您應該使用一些工具，例如BitBucket、Azure DevOps、GitHub或GitLab。例如，Microsoft多年來一直使用名為CodeFlow的內部工具，它支持開發人員並指導他們完成所有代碼審查步驟。它在代碼準備階段有所幫助，自動通知審閱者，並具有豐富的評論和討論功能。在後來的幾年裡，他們轉向了GitHub拉取請求。Google也在代碼審查方面使用兩種解決方案。他們使用Gerrit代碼審查工具進行開源代碼審查，但在內部代碼方面，他們使用名為Critique的內部工具。
現在AI技術對CR的提供強大的支撐，前提是要註意保護好源代碼。像OpenAI的chatGPT，MS的Copilot
代碼審查的更好替代方案
除了傳統的PR審查之外，還有另一種模型可以幫助您在編碼過程中獲得更高的效率和速度。它基於一種不同於拉取請求的模型，稱為基於主幹的開發。在這裡，您同步進行代碼審查。通過這種方式，所有開發人員都在主線分支上工作，頻繁提交更改。這種做法的一個例子是協作編程方法（配對編程和集體編程），是由Kent Beck在90年代作為極限編程技術引入的。
配對編程
配對編程和集體編程是協作編程方法，涉及兩個或多個開發人員共同處理單個任務，共享編寫代碼時的想法和思路。在這裡，一個開發人員充當驅動者（編寫代碼）的角色，而另一個則充當導航者的角色（確保代碼準確性）。在過程中他們會定期交換位置。
與傳統代碼審查相比，這些方法提供了多種好處：
•實時反饋：配對編程和集體編程使開發人員能夠即時獲得有關其代碼的反饋，從而能夠解決問題並改進。這與傳統的代碼審查不同，後者可能要等到代碼審查階段才會收到反饋。
•增強的知識共享：協作編程使開發人員能夠從彼此的經驗和知識中學習，從而帶來更好的代碼和技能發展。這在使用新技術或面對新手時特別有用。此外，學習更容易在團隊成員之間傳播，降低了單個開發人員成為瓶頸的風險。
•更快的問題解決鼓勵開發人員共同解決問題，從而獲得更快、更高效的解決方案。這可以減少開發時間並改善項目結果。
•增強的關註和生產力：與另一位開發人員密切合作可以幫助保持專註並減少分心。•提高代碼質量：當多個開發人員共同合作時，他們更有可能在開發早期發現錯誤和設計問題，進而提高代碼質量。
這種方法在擁有大部分資深開發人員的團隊，必須快速迭代的情況下效果最佳。然而，如果團隊主要由初級開發人員組成，或者產品較為復雜需要多人審核代碼時，Pull Request 模型更為適用。