谷歌開源代碼評審規範:好壞代碼應該這樣來判斷
谷歌開源了一套代碼評審(Code Review)規範,它是谷歌一套通用的工程實戰指南,幾乎涵蓋了所有編程語言與各種類型的項目,這個規范代表了谷歌長期發展以來最佳實戰經驗的集合,谷歌表示希望開源項目或其他組織能夠從這套規範中受益。
代碼評審,也稱代碼複查,如果一個團隊正在使用任務分支工作流,那麼在所有代碼編寫完成並通過自動化測試之後,在代碼合併之前,就會啟動代碼評審。通常的目的是查找系統缺陷,保證軟件總體質量和提高開發者自身水平,代碼評審的所有工具和過程都是為了這個目的而構建的。代碼評審對於敏捷團隊來說的作用如下:
- 代碼評審共享知識
- 通過代碼評審可以更好的進行工作評估
- 代碼評審能讓你享受休假
- 通過代碼評審指導新工程師
既然代碼評審要進行眾多的檢查,那麼找一個優秀的評審者就非常重要了。一般對於變更列表的不同部分,都會有不同的評審者進行細緻的審查。當然如果是結對編程,且你的隊友能進行高質量的代碼評審,那麼這樣寫的代碼一般可以視為已經過評審了。此外,我們也可以進行面對面的評審,評審者會問開發者一些問題。
根據谷歌的項目描述,代碼審核規範為兩套獨立文檔組成,代表了兩方面內容的最佳實踐:
在其中一些文檔中使用了一些術語,如下:
- CL:表示“變更列表(changelist)”,意思是已經提交到版本控製或正在進行代碼檢查的一個獨立的更改。其他組織通常稱為“改變”或“補丁”
- LGTM:意思是“在我看來不錯(Looks Good to Me)”,這是代碼審閱者在批准CL 時說的
接下來我們來看看兩份文檔分別的主要內容是什麼:
1.代碼評審者的指南——如何進行代碼評審
代碼評審者指南本來是一個完整的文檔,但作者將其分為了 6 部分,讀者可根據需要閱讀。
2.CL 作者指南——CL 作者批准代碼的評審指南
CL 制定者指南包括一些進行代碼評審的開發人員的最佳經驗,這些經驗能夠幫助你更快、更高質量地完成評審。
在谷歌看來,代碼審核的目的是確保谷歌代碼庫的整體代碼健康程度。谷歌將以下規則作為代碼評審的標準:
一般來說,一旦CL 能提升整體代碼的健康程度,那麼即使CL 不完善,評審者同樣也應該傾向於批准該列表。這是所有代碼評審指南中的高級原則。它也會有一些限制,例如,如果CL 添加了一些評審者不需要的特性,那麼即使代碼做了不錯的設計,評審者也應該不予通過。
沒有所謂的“完美”代碼,只有更好的代碼。評審人員不應要求作者在批准前對CL的每一小部分過分完美。相反,評審者應該權衡向前繼續開發的需求和修改建議的重要性。評審者要求的是持續性地改進,而不是追求完美的代碼。CL作為一個整體,如果它能提升系統的可維護性、可讀性和可理解性,那麼就不要因為它還不完美而推遲數天或數週更新。
評審者應該經常留下一些評論,以表達能導致更好性能的做法。如果這些做法並不是非常重要的,那麼需要加上前綴“Nit:”,從而令代碼作者知道這些內容是可以忽略的。
評審指導
代碼評審有一個很重要的功能,即教開發者一些開發經驗,不論是語言、框架還是一般軟件設計準則。留一些評論總會幫助開發者學習一些新的知識,共享知識也是改善系統代碼健康狀態的重要部分。當然,如果評審者的評論僅僅只是教育性的,且對於標準要求不那麼重要,那麼還是要加上前綴“Nit:”的。
評審準則
技術事實和數據要優先於觀點與個人風格。
在代碼風格方面,谷歌的代碼風格指南是最權威的參考資料。任何不在風格指南中的代碼習慣,都屬於個人風格,但我們應該保證基本的風格和谷歌風格指南是一致的。
軟件設計方面幾乎不會有純粹的風格問題,或者純粹個人的習慣問題。很多風格問題都基於一些基本準測,它們並不是簡單地由個人觀點決定的。此外,如果代碼作者通過數據或基本工程原則證明了幾種方法同樣有效,那麼評審者應該接受作者的風格。否則,偏好的選擇還是取決於軟件設計的標準原則。
如果沒有其它適用規則,那麼評審者可以要求作者的偏好與當前代碼庫保持一致,同時不對整體的代碼健康水平產生影響。
解決衝突
在代碼評審中,如果發生了任何衝突,第一步應該是開發者和評審者基於本項目的CL 指南達成共識。當達成共識非常困難時,開發者與評審者應該面對面地交流,而不只是通過審查中的評論來交流。如果開會討論還解決不了,那麼就要擴大會議了,我們可以通過與代碼維護人員、工程經理等開發者的交流,達成最終的共識。
如果想要深入了解谷歌的這套代碼審核規範,可查看該項目。地址如下: