本文指出了所有開發人員在審查其程式碼或提交拉取請求時可能遇到的特定反模式，並對此進行了譴責。

程式碼作者花了數小時甚至數天的時間來建立他們認為最有效的解決方案。他們考慮了多種設計方案，並採取了最相關的道路。他們考慮了現有應用程式架構，並在適當的位置進行了更改。然後他們將其解決方案作為請求請求提交，或者開始了程式碼審查過程，並且收到的專家反饋是

• “您應該使用製表符，而不是空格。”
• “我不喜歡本節中的括號。”
• “檔案末尾沒有空白行。”
• “您的列舉是大寫的，應該用句子大寫。”

儘管使新程式碼與現有程式碼的樣式保持一致很重要，但這幾乎不需要人工檢查。人工稽核者很昂貴，可以完成計算機無法完成的任務。檢查計算機是否滿足樣式標準是計算機可以輕鬆完成的事情，並且會分散程式碼審查的真實目的。

如果開發人員在程式碼審查期間看到許多此類註釋，則表明團隊沒有樣式指南或只有樣式指南，而且這種樣式檢查沒有實現自動化。自動化的解決方案是使用諸如checkstyle之類的工具來確保遵循了樣式準則，或者使用sonarqube來識別常見的質量和安全性問題。持續整合環境可以做到這一點，而不是依靠人工稽核者來警告此類問題。

反模式：反饋不一致

對於每位受邀審查程式碼的開發人員，至少要徵詢一個意見，甚至更多。每個人可以同時持有多個意見。有時，程式碼審查可能會成為審查者之間關於不同方法的爭論。

當團隊不清楚其“最佳實踐”是什麼樣時，並且還沒有弄清其優先順序是什麼時，就會發生這種情況，例如：

• 程式碼是否應該朝著更現代的Java風格發展？還是更重要的是，程式碼是一致的，並因此繼續在各處使用“經典”構造？
• 在系統所有部分中對資料結構進行O（1）讀取操作是否重要？還是有O（n）可接受的部分？

幾乎所有設計問題都可以用“取決於”來回答。為了更好地瞭解答案，開發人員需要了解其應用程式和團隊的優先順序。

反模式：最後一刻的設計變更

開發人員在程式碼審查期間獲得的最令人沮喪的反饋是，當審查者從根本上不同意解決方案的設計和架構並強制完全重寫程式碼時。

程式碼審查不是審查設計的正確時機。如果團隊遵循經典的“閘道器”程式碼審查，則該程式碼應該可以正常工作，並且所有測試都應通過，然後再由另一個開發人員檢視該程式碼。在這一點上，需要花費數小時，數天甚至數週的時間（儘管我真的希望不要數週；程式碼審查應該很小，但這是另一個主題）。在程式碼審查期間指出底層設計是錯誤的，這是浪費每個人的時間。

反模式：打乒乓球式迴圈評論

在理想的情況下，作者將提交其程式碼以供審閱，審閱者將提出一些具有明確解決方案的評論，作者將提出建議的更改並重新提交程式碼，審閱將完成，程式碼將被推送。但是，如果這總是想打乒乓球一樣來回迴圈定期發生，誰能證明程式碼審查過程的合理性呢？

在現實生活中，經常發生以下情況：

1. 程式碼檢查開始。
2. 許多評論者提出了一些建議：一些小而輕鬆；一些蓬鬆而沒有明顯的解決方案；還有一些複雜。
3. 作者進行了一些更改：至少是簡單的修復，或者可能進行了一些更改，以使審閱者滿意。作者可能會問審稿人一些問題以澄清問題，或者作者可能會發表評論以解釋為什麼未進行特定更改。
4. 審閱者返回，接受一些更新，對其他評論進行進一步評論，找到其他他們對原始程式碼不滿意的事物，回答問題，並與其他審閱者或作者就審閱中的評論進行辯論。
5. 程式碼作者進行了更多更改，新增了更多註釋和問題，等等。
6. 審閱者檢查更改，提出更多評論和建議，等等。
7. 重複步驟5和6，也許永遠重複一次。

從理論上講，在此過程中，更改和註釋應降至零，直到程式碼準備就緒為止。最令人沮喪的情況是，每次迭代都帶來至少與已關閉的舊問題一樣多的新問題。在這種情況下，團隊已進入“程式碼審查的無限迴圈”。發生這種情況的原因有很多：

• 如果審稿人挑剔並且反饋不一致，就會發生這種情況。對於習慣於這些習慣的審閱者來說，有無數的問題可以識別，也有無數的評論可以發表。
• 當審查沒有明確的目的或審查期間沒有遵循準則時，就會發生這種情況，因為每個審查者都認為必須找到所有可能的問題。
• 當不清楚程式碼編寫者對審閱者的評論有何要求時，就會發生這種情況。每個評論是否都暗示必須進行更改？所有問題是否都暗示該程式碼不是自記錄文件，需要改進？還是隻是為了下一次教育程式碼作者而發表一些評論，而提出的問題僅僅是為了幫助審閱者理解和學習嗎？

註釋應該理解為顯示最高者或不是顯示最高者，並且如果審閱者決定程式碼需要更改才能簽名，則他們必須明確說明程式碼作者應採取的行動。

同樣重要的是要了解由誰來負責決定稽核是否“完成”。這可以通過已檢查並通過的專案的任務列表來實現，也可以由有權說“足夠好”的個人來完成。通常需要有人可以打破僵局並解決分歧。它可能是高階開發人員，主管或架構師，甚至可能是團隊中高度信任的程式碼編寫者。但是在某些時候，有人需要說“審查完成”或“這些步驟完成後，審查就完成了”。

反模式：Ghost Reviewer

在審閱期間根本不回應。也許有人要求我審查一個重要或有趣的功能，所以我決定將其保留，直到“更好的時間”，當我可以“正確地看待它”。

以下是解決方法的建議：

• 確保程式碼審查很小。每個團隊都必須確定其定義，但是要審查的時間是數小時或數天，而不是數週。
• 確保程式碼審查的目的明確，並且審查者應尋找的內容也明確。當範圍“找到程式碼中的任何可能的問題”時，很難激勵自己去做某事。
• 在開發過程中留出時間進行程式碼審查。

最後一點可能需要團隊紀律，或者團隊可能希望通過（例如）通過目標或用於確定開發人員生產率的任何機制來獎勵良好的程式碼審查行為來鼓勵時間。