本文經機器之心（微信公眾號：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 指南達成共識，當達成共識非常困難時，開發者與評審者應該面對面地交流，而不只是通過審查中的評論來交流，如果開會討論還解決不了，那么就要擴大會議了，我們可以通過與代碼維護人員、工程經理等開發者的交流，達成最終的共識，
以上只是代碼規范的一般標準，它還是非常抽象的，如果讀者想要了解更多細節的內容，那么可以繼續查看該專案，
推薦去我的博客閱讀更多：
1.Java JVM、集合、多執行緒、新特性系列教程
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
4.Java、后端、架構、阿里巴巴等大廠最新面試題
覺得不錯，別忘了點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/5031.html
標籤：Java