來源：小技術君

軟體開發生命週期中至關重要的一步是程式碼審查。它使開發人員能夠顯著提升程式碼質量。它類似於書籍的創作過程。首先，作者寫故事，然後經過編輯以確保不會出現諸如混淆“you’re”和“yours”之類的錯誤。在這個語境中，程式碼審查指的是檢查和評估他人的程式碼。它基於拉取請求模型，這個模型在開源專案中廣受歡迎。

程式碼審查有不同的好處：

•確保設計和實現的一致性，•最佳化程式碼以提升效能，•是學習的機會，•知識分享和指導，以及促進團隊凝聚力。

程式碼審查中需要檢查的內容

程式碼審查有不同的好處：

在程式碼審查中應該查詢什麼？有許多不同的事項需要檢查，從重要性的不同層次和自動化的可能性來看：

嘗試查詢以下內容：

1.功能性和設計 — 這裡，我們需要找到答案，比如：這個更改是否遵循我們期望的架構，或者它是否與系統的其他部分整合良好？它的元件之間是否具有高內聚性和低耦合性？它是否遵循瞭如OO、SOLID、DRY、KISS、YAGNI等健壯的原則？2.實現 — 在這裡，我們檢查解決方案是否在邏輯上正確（它確實改變了開發人員的意圖），如果程式碼比應有的複雜，等等。這段程式碼是否必要？我們還要檢查是否使用了良好的設計模式。以及關鍵的內容，例如API入口點。3.測試 — 在這裡，我們檢查是否所有測試都透過了，我們是否對所有程式碼路徑和行為使用單元測試，並對外部系統（資料庫、檔案系統等）使用整合測試。我們是否檢查了所有邊界條件和程式碼覆蓋率在60-80%之間？4.文件 — 我們的PR描述新增了嗎？我們的解決方案在儲存庫的README.md或其他地方是否有文件更新？5.程式碼風格 — 我們是否遵循了專案的程式碼風格？您是否知道命名是否良好？開發人員是否為類、方法等選擇了確切的名稱？程式碼是否易讀？

程式碼審查金字塔（基於Gunnar Morling的原始作品）

進行程式碼審查的一些良好實踐

以下是進行程式碼審查時的一些良好實踐：

1.嘗試首先審查您自己的程式碼。

在將程式碼傳送給同事之前，嘗試先閱讀和理解它。尋找讓您困惑的部分。在IDE之外檢視您的程式碼通常有助於將其視為“新”的東西，從而避免操作性盲點。

1.編寫更改的簡短描述。

這應該以高層次解釋更改內容以及為何進行這些更改的方式來解釋。

1.自動化可以自動化的部分。

將所有可以自動化的工作留給系統，例如檢查成功構建（CI）、樣式更改（程式碼檢查器）、自動化測試和靜態程式碼分析（例如使用SonarQube）。我們已將其整合在PR級別，因此它將在每個PR上執行併為程式碼合併提供阻礙。這將使我們能夠消除不必要的討論，為更重要的討論留出空間。

1.為更大的任務與團隊成員進行啟動會議。

如果您開始處理更大的任務，特別是在設計方面，請嘗試首先與程式碼所有者或將成為您的程式碼審查者的人進行啟動會議。這將在實施之前達成共識，並減少在PR審查階段的工作量，避免出現意外情況。

1.不要著急

您需要了解其周圍發生了什麼 — 每一行程式碼。如果需要，逐類多次閱讀。應該檢視分配給審查的每一行程式碼。有些程式碼需要更多的思考，有些則需要更少，但這是我們在審查過程中必須做出的決定。如果需要，為口頭討論保持自己的時間。

1.友善地評論

永遠不要提及個人（您），始終將注意力集中在更改上，以問題或建議的形式提出，並留下至少一個積極的評論。用您的話解釋“為什麼”，並建議如何改進。

1.在足夠好時批准PR。

不要追求完美，但要保持高標準。不要小題大做。

1.控制審查的規模。

我們應該限制一次審查的程式碼行數。PR應該包含儘可能少的更改檔案。我更喜歡更小的增量更改而不是重大的更改。我們的大腦無法一次處理那麼多資訊。每次審查的核心行數的理想數量是200到400行，通常是60到90分鐘。如果任務龐大，請將其細分為可以快速審查的較小子任務。

1.使用工具

對於所有程式碼審查，您應該使用一些工具，例如BitBucket、Azure DevOps、GitHub或GitLab。例如，Microsoft多年來一直使用名為CodeFlow的內部工具，它支援開發人員並指導他們完成所有程式碼審查步驟。它在程式碼準備階段有所幫助，自動通知審閱者，並具有豐富的評論和討論功能。在後來的幾年裡，他們轉向了GitHub拉取請求。Google也在程式碼審查方面使用兩種解決方案。他們使用Gerrit程式碼審查工具進行開原始碼審查，但在內部程式碼方面，他們使用名為Critique的內部工具。

程式碼審查的更好替代方案

除了傳統的PR審查之外，還有另一種模型可以幫助您在編碼過程中獲得更高的效率和速度。它基於一種不同於拉取請求的模型，稱為基於主幹的開發。在這裡，您同步進行程式碼審查。透過這種方式，所有開發人員都在主線分支上工作，頻繁提交更改。這種做法的一個例子是協作程式設計方法（配對程式設計和集體程式設計），是由Kent Beck在90年代作為極限程式設計技術引入的。

配對程式設計（來源：Unsplash）

配對程式設計和集體程式設計是協作程式設計方法，涉及兩個或多個開發人員共同處理單個任務，共享編寫程式碼時的想法和思路。在這裡，一個開發人員充當驅動者（編寫程式碼）的角色，而另一個則充當導航者的角色（確保程式碼準確性）。在過程中他們會定期交換位置。

與傳統程式碼審查相比，這些方法提供了多種好處：

•實時反饋：配對程式設計和集體程式設計使開發人員能夠即時獲得有關其程式碼的反饋，從而能夠解決問題並改進。這與傳統的程式碼審查不同，後者可能要等到程式碼審查階段才會收到反饋。•增強的知識共享：協作程式設計使開發人員能夠從彼此的經驗和知識中學習，從而帶來更好的程式碼和技能發展。這在使用新技術或面對新手時特別有用。此外，學習更容易在團隊成員之間傳播，降低了單個開發人員成為瓶頸的風險。•更快的問題解決鼓勵開發人員共同解決問題，從而獲得更快、更高效的解決方案。這可以減少開發時間並改善專案結果。•增強的關注和生產力：與另一位開發人員密切合作可以幫助保持專注並減少分心。•提高程式碼質量：當多個開發人員共同合作時，他們更有可能在開發早期發現錯誤和設計問題，進而提高程式碼質量。

這種方法在擁有大部分資深開發人員的團隊，必須快速迭代的情況下效果最佳。然而，如果團隊主要由初級開發人員組成，或者產品較為複雜需要多人稽核程式碼時，Pull Request 模型更為適用。