本文經機器之心（微信公眾號：almosthuman2014）授權轉載，禁止二次轉載
項目作者：Max Kanat-Alexander 機器之心編譯
谷歌以前建立了一套通用的工程實戰指南，它差不多囊括了所有編程語言與各種類型的項目。今天，谷歌將這一套代碼評審（Code Review）規范開源了出來，它代表了谷歌最佳實戰經驗的集合。
項目地址：https://github.com/google/eng-practices
開源項目作者或其它開發者都能從這個項目獲得有用的知識，因此谷歌開源了這一份代碼規范，並將持續維護。如項目所言，目前這份代碼評審規范主要包含兩組獨立的文檔：
1. 代碼評審者的指南
-
代碼評審標准
-
代碼評審希望達到什么
-
在代碼評審中導航修改列表
-
代碼評審的速度
-
如何寫審查的評論
-
處理代碼評審的回退
2.CL 作者指南
-
寫一個好的修改列表描述
-
構建一些小的修改列表
-
如何處理代碼評審者的評論
其中代碼評審者指南包括一些做代碼評審的最佳方式，它們都是根據長期經驗得出來的。代碼評審者指南本來是一個完整的文檔，但作者將其分為了 6 部分，讀者可根據需要閱讀。修改列表（Change List/CL）制定者指南包括一些瀏覽代碼評審的最佳方式，開發者可以快速處理評審結果。
代碼評審都在干些什么
代碼評審最主要的目的是確保代碼庫一直保持「健康」的狀態，代碼評審的所有工具和過程都是為了這個目的而構建的。代碼評審會系統化地查一遍源代碼，並希望檢查出開發初期未察覺的一些錯誤，從而提升代碼質量。
那么代碼評審都在感謝什么呢？一般而言，代碼評審希望完成以下的評估：
-
設計：代碼是不是經過精心的設計，並適合我們的系統？
-
功能性：代碼的行為是否和作者的意圖保持一致？代碼的行為方式對用戶是否正常？
-
復雜度：代碼能更簡單一些嗎？在未來，其它開發者能更容易地理解並使用這些代碼嗎？
-
測試：代碼是不是正確的，是不是通過了精心設計的自動測試？
-
命名：開發者是不是選擇易於理解的名稱給變量、類和方法進行命名？
-
評論：代碼評論是不是足夠清晰並有用？
-
風格：代碼是不是采用了標准的編寫風格？
-
文檔：開發者是不是更新了相關的文檔？
既然代碼評審要進行眾多的檢查，那么找一個優秀的評審者就非常重要了。一般對於修改列表的不同部分，都會有不同的評審者進行細致的審查。另外，關注公眾號Java技術棧回復手冊可以獲取阿里巴巴的最新Java開發手冊，非常有價值和參考意義。
當然如果是結對編程，且你的隊友能進行高質量的代碼評審，那么這樣寫的代碼一般可以視為已經過評審了。此外，我們也可以進行面對面的評審，評審者會問開發者一些問題。
代碼評審的通用規范
整個代碼評審指南分為了很多模塊，我們也沒辦法全部介紹一遍。因此，在本文的最后，我們將介紹谷歌開發者在做代碼評審時，最一般的評審標准。
谷歌表示他們以如下規則作為期望的標准：
「通常而言，一旦修改列表能提升整體代碼的健康程度，那么即使修改列表不完善，評審者同樣也應該傾向於批准該列表。」
這條准則是所有代碼評審指南的最高原則。它也會有一些限制，例如，如果 CL 添加了一些評審者不需要的特性，那么即使代碼經過了精心的設計，評審者也應該不予通過。
這里的一個關鍵點是沒有「完美」代碼這個概念，只有更好的代碼。評審者不應該要求代碼作者在批准前對每一小塊 CL 進行打磨。
相反，評審者應該權衡向前繼續開發的需求和修改建議的重要性。評審者要求的是持續性地改進，而不是追求完美的代碼。CL 作為一個整體，如果它能提升系統的可維護性、可讀性和可理解性，那么就不要因為它還不完美而推遲數天或數周更新。
評審者應該經常留下一些評論，以表達能導致更好性能的做法。如果這些做法並不是非常重要的，那么需要加上前綴「Nit:」，從而令代碼作者知道這些內容是可以忽略的。《兩年 Code Review 實戰經驗分享！》這篇推薦看下。
評審指導
代碼評審有一個很重要的功能，即教開發者一些開發經驗，不論是語言、框架還是一般軟件設計准則。留一些評論總會幫助開發者學習一些新的知識，共享知識也是改善系統代碼健康狀態的重要部分。當然，如果評審者的評論僅僅只是教育性的，且對於標准要求不那么重要，那么還是要加上前綴「Nit:」的。
評審准則
技術事實和數據要優先於觀點與個人風格。
在代碼風格方面，谷歌的代碼風格指南是最權威的參考資料。任何不在風格指南中的代碼習慣，都屬於個人風格，但我們應該保證基本的風格和谷歌風格指南是一致的。
谷歌風格指南：http://google.github.io/styleguide/
軟件設計方面幾乎不會有純粹的風格問題，或者純粹個人的習慣問題。很多風格問題都基於一些基本准測，它們並不是簡單地由個人觀點決定的。此外，如果代碼作者通過數據或基本工程原則證明了幾種方法同樣有效，那么評審者應該接受作者的風格。否則，偏好的選擇還是取決於軟件設計的標准原則。
如果沒有其它適用規則，那么評審者可以要求作者的偏好與當前代碼庫保持一致，同時不對整體的代碼健康水平產生影響。
解決沖突
在代碼評審中，如果發生了任何沖突，第一步應該是開發者和評審者基於本項目的 CL 指南達成共識。當達成共識非常困難時，開發者與評審者應該面對面地交流，而不只是通過審查中的評論來交流。如果開會討論還解決不了，那么就要擴大會議了，我們可以通過與代碼維護人員、工程經理等開發者的交流，達成最終的共識。
以上只是代碼規范的一般標准，它還是非常抽象的，如果讀者想要了解更多細節的內容，那么可以繼續查看該項目。
推薦去我的博客閱讀更多：
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
覺得不錯，別忘了點贊+轉發哦！