程序員寫代碼為什麼需要 review？

在日常寫完代碼之後，你是否會有 Code Review 的習慣？

Code Review 即代碼審查，其目的在於找到開發時被忽視的 Bug，以此極大地提高代碼質量也可以幫助開發者們更加熟悉項目。但遺憾的是，很多業界的開發者並沒有常規代碼審查的習慣。那麼對於程序員而言，Review 是否真的是一項必備的工作？

作者 | Gergely Orosz

譯者 | 彎月，責編 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下為譯文：

十多年來，我常常擔任代碼審查的工作。代碼審查的好處很多：從其他人的角度閱讀代碼變更、知識共享以及工具和自動化改進。如果你們沒有代碼審查，那麼我強烈建議你遵從Jeff Atwood於2006年分享的這項建議（https://twitter.com/codinghorror）。

許多人和組織分享了有關代碼審查的最佳實踐，以及良好的代碼審查的意義。SmartBear團隊、Palantir工程團隊和工程師Philipp Hauer分享的指南都是很好的閱讀材料。以下是我個人對良好的代碼審查的看法，以及怎樣才能做到更好。本文的背景是我工作中的技術環境，包括現在我所在的Uber，以及以前微軟的Skype和Skyscanner。

代碼審查所涵蓋的領域

良好的代碼審查人員會查看代碼本身的變更，以及這些變更是否適合已有代碼。他們會仔細研究標題和描述，以及代碼變更的「原因」。他們還會檢查代碼的正確性、測試覆蓋率、功能變更並確認是否遵循了編程指南和最佳實踐。同時，他們還會指出明顯有待改進的地方，例如難以理解的代碼、含混的名稱、注釋掉的代碼、未經測試的代碼或未處理的邊緣情況。最後，他們還會注意，如果一次提交包含了太多代碼變更的話，則建議代碼的變更應該保持單一目的性，並將代碼變更分解成目標更為集中的幾部分。

更優秀的代碼審查人員還會從系統整體的角度查看代碼變更，並檢查這些變更是否易於維護。他們可能會詢問代碼變更的必要性，或對系統其他部分造成的影響。他們會研究代碼中引入的抽象以及與現有的軟體架構的適應性。此外，他們還會觀察可維護性，例如是否可以簡化的複雜邏輯、測試結構、重複和其他可能的改進。工程師Joel Kemp在這篇文章中（https://medium.com/@mrjoelkemp/giving-better-code-reviews-16109e0fdd36），將這些代碼審查劃分成了兩個級別：初步審查與全面的審查。

審查的基調

代碼審查的基調可以極大地影響團隊內部的士氣。刺耳的評論可能會導致惡劣的工作環境。自以為是的語言可能會讓人們感受到敵對，從而引發激烈的爭論。同時，專業且積極的語氣可以培養更包容的環境。這些環境中的人們可以接受建設性的反饋，而且代碼審查會引發健康和熱烈的討論。

良好的代碼審查人員會提出開放式的問題，而不是發表強烈或自以為是的陳述。他們會提供替代方案或其他解決方法。這些審查人員會認為自己可能遺漏了某些內容，因此他們首先會要求對方澄清，而不是要求對方改正。

更優秀的代碼審查人員富有同情心。他們知道編寫代碼的人花了很多時間和精力來應對這些變化。這些代碼審查人員善良且不張揚。他們會大力讚賞良好的解決方案，並採取全面積極的行動。

批准與請求變更

良好的代碼審查人員不會在有開放式問題的時候批准代碼更改。 但是，他們會明確指出哪些問題或評論沒有造成阻塞或不重要，通常這樣的審核意見被稱為「挑剔」。他們只在變更非常明確的情況下批准變更（例如，註明「在我看來很好」）。當需要跟進時，他們同樣會明確地使用代碼審查工具或按照團隊的習慣進行溝通。

更優秀的代碼審查人員在面臨需要回答某些問題或解決重要問題之前，也不會批准代碼更改。這種審核在原則上是堅定的，但在實踐上卻是靈活的：有時，寫代碼的人會在後續代碼變更中單獨解決審核指摘的問題。有些更改比較緊急，所以審查人員會儘快地推動審查。

從代碼審查到彼此交談

良好的代碼審查人員會儘可能地留下評論和問題。如果經過修改後仍然有殘留問題，他們也會記錄下來。如果來回的評論過多，那麼審核人員會捨棄過於耗時的工具，而選擇面對面交談。

更優秀的代碼審查人員在第一次審核完畢，但有很多評論和問題時，會主動聯繫寫代碼的人。他們知道與其在評論中來回反覆，還不如面對面的交談，因為這種方式可以節省大量的時間，還可以省卻不少誤解和麻煩。很多針對代碼的評論表明，審查雙方往往會存在一些誤解。彼此的交談更容易消除誤解。

吹毛求疵

如前所述，良好的代碼審查人員會清楚地表明哪些評論不重要，或有點挑剔。這方面的審查問題包括變數聲明按字母順序排列、測試結構遵循某個結構或括弧位於同一行或下一行。

通常，良好的代碼審查人員不會有太多的挑剔。雞蛋裡挑骨頭會打擊人的積極性，而且也會讓大家喪失對重要問題的關注。

更優秀的代碼審查人員明白太多的挑剔意味著缺乏工具或缺乏標準。經常遇到這些問題的審核人員會考慮在代碼審查流程之外解決這個問題。 例如，大多數常見的挑剔都可以通過自動linting來解決。如果無法通過工具解決，則應該由團隊協商採用某些標準來解決，然後繼續跟進這個問題，甚至可以自動化。

新加入代碼審查的人

良好的代碼審查人員會一視同仁，採用相同的質量標準和方法，無論他們的職位，級別以及加入公司的長短。根據上述內容，通常代碼審查人員都會很和善，只在有必要的時候請求變更，並在收到許多意見時與他們進行交談。

更優秀的代碼審查人員更加註重給新加入的人留下一個好印象。審查人員明白新來的人可能不了解所有的編程指南，而且也可能不熟悉代碼的某些部分。所以，他們會進一步努力解釋替代方案，或建議他們閱讀編程指南。他們還會使用非常積極的語氣，鼓勵寫代碼的人剛開始提交的代碼變更。

跨辦公室及跨時區審查

如果寫代碼的人和審查人員不在同一個地點時，代碼審查會變得更困難。當審核人員位於不同的時區時，這種難度就會更高。多年來，我力爭公平地審查所有代碼，無論是美國、亞洲還是歐洲團隊所提交的代碼。

良好的代碼審查人員會儘可能地考慮時區差異。審查人員都會努力在雙方都辦公的時間內審查代碼。如果遇到很多評論的情況，則會選擇直接聊天或進行視頻通話。

更優秀的代碼審查人員在反覆遇到時區問題時，就會努力尋找代碼審查框架之外的系統解決方案。假設某個歐洲的團隊經常更改某項服務，而代碼審查則由美國負責這項服務的人來進行。系統級的問題是，這些變化如此頻繁發生的原因是什麼？隨著時間的推移，變化的頻率相同還是下降了？假設代碼變更是在正確的代碼庫中完成的，且頻率沒有下降，那麼是否應該打破這種跨部門的依賴性？解決這些問題往往不簡單，可能涉及重構，或者創建新的服務/介面，或改進工具。解除這種依賴關係會讓兩個團隊都更加輕鬆，更有效地推動工作。

組織的支持

公司及其工程組織如何看待代碼審查是影響代碼審查的重要因素。如果組織認為代碼審查無關緊要或微不足道，就不會在這方面投入太多。在這樣的文化中，在某些情況下，開發人員將不得不放棄代碼審查。倡導實施更好的代碼審查的工程師可能會感到孤立，而且也無法獲得獲得上述支持，最終放棄。如果組織認為代碼審查是工程中的關鍵部分，那麼他們就會為工程師提供更好的工作環境。

擁有良好代碼審查的組織會確保所有工程師都參與代碼審查流程，包括那些單獨在某個項目上工作的人員。他們鼓勵提高質量標準。這些團隊會積極地討論從團隊和組織層面開展代碼審查。通常，這些公司都有工程師發起和編寫的大型代碼庫的代碼審查指南。這樣的組織中，理解代碼審查會佔用工程師的很多時間。許多這樣的公司在招聘開發人員時，也會將代碼審查作為一項重要的工作能力，並希望高級工程師花費更多的時間來審查其他人的代碼。

擁有更好的代碼審查的組織會建立硬性規則：沒有經過代碼審查的代碼不能投入到生產中，就像沒有經過自動化測試的業務邏輯更改不能進入生產環境一樣。這些組織明白，削減這樣的成本根本不值得，相反他們擁有在緊急情況下，加快審查團隊和組織代碼審查的流程。這些組織會投資提高開發人員的工作效率，其中包括更有效的代碼審查和工具改進。這些公司的高管通常都是軟體工程師，你不需要說服他們有關代碼審查和其他工程最佳實踐的好處。相反，他們支持團隊利用更好的工具，或更有效的代碼審查流程。

當寫代碼的人感受到惡意的評論時，他們可以說出來並全力支持解決問題。高級工程師和管理人員認為不達標的代碼評審與劣質的代碼或不健全的功能同等嚴重。工程師和工程經理都感覺有責任改進代碼審查的開展方式。

原文：https://blog.pragmaticengineer.com/good-code-reviews-better-code-reviews/

作者：Gergely Orosz，軟體工程師，主要從事移動、Web和後台開發。

本文為 CSDN 翻譯，轉載請註明來源出處。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！