Google 家的這份工程實踐文件，你不看？

王老闆的前端發表於2020-05-22

今天跟大家分享一份來自 Google 團隊的工程實踐文件：

Google’s Engineering Practices documentation。

這份文件是 Google 團隊長期以來的內部專案最佳實踐。其目的是幫助開發者更好地進行程式碼審查工作，通過 Code Review 來提升並優化當前專案的程式碼質量，便於開發人員維護和維護舊專案。

在國內，程式碼審查一直沒有沒有被重視，一般都是有了問題才去修修補補。但是，構建一個健壯的大型軟體應用是必須有程式碼審查環節的。

如果你的團隊開始程式碼審查環節，但沒有正確的方法，這份文件就很適合你了。

我摘抄了一些片段。

首先，它包含兩個部分

程式碼審查者指南
程式碼開發者指南

程式碼審查者指南

本節是基於過往經驗編寫的 Code Review 最佳方式建議。其中分為了很多獨立的部分，共同組成完整的文件。雖然您不必閱讀文件，但通讀一遍會對您自己和團隊很有幫助。

Code Review 標準[1]
Code Review 要點[2]
檢視 CL 的步驟[3]
Code Review 速度[4]
如何撰寫 Code Review 評論[5]
處理 Code Review 中的牴觸[6]

另請參閱程式碼開發者指南[7]，該指南為正在進行 Code Review 的開發開發者提供詳細指導。

程式碼審查者應該關注哪些方面？

程式碼審查時應該關注以下方面：

設計：程式碼是否經過精心設計並適合您的系統？
功能：程式碼的行為是否與作者的意圖相同？程式碼是否可以正常響應使用者的行為？
複雜度：程式碼能更簡單嗎？將來其他開發人員能輕鬆理解並使用此程式碼嗎？
測試：程式碼是否具有正確且設計良好的自動化測試？
命名：開發人員是否為變數、類、方法等選擇了明確的名稱？
註釋：評論是否清晰有用？
風格：程式碼是否遵守了風格指南[8]？
文件：開發人員是否同時更新了相關文件？

程式碼開發者指南

本節頁面的內容為開發人員進行程式碼審查的最佳實踐。這些指南可幫助您更快地完成稽核並獲得更高質量的結果。您不必全部閱讀它們，但它們適用於每個 Google 開發人員，並且許閱讀全文通常會很有幫助。

寫好 CL 描述[9]
小型 CL[10]
如何處理審查者的評論[11]

另請參閱程式碼審查者指南[12]，它為程式碼審閱者提供了詳細的指導。

寫好 CL 描述

CL 描述是進行了哪些更改以及為何更改的公開記錄。CL 將作為版本控制系統中的永久記錄，可能會在長時期內被除審查者之外的數百人閱讀。

開發者將來會根據描述搜尋您的 CL。有人可能會僅憑有關聯性的微弱印象，但沒有更多具體細節的情況下，來查詢你的改動。如果所有重要資訊都在程式碼而不是描述中，那麼會讓他們更加難以找到你的 CL 。

首行

正在做什麼的簡短摘要。
完整的句子，使用祈使句。
後面跟一個空行。

CL 描述的第一行應該是關於這個 CL 是做什麼的簡短摘要，後面跟一個空白行。這是將來大多數的程式碼搜尋者在瀏覽程式碼的版本控制歷史時，最常被看到的內容，因此第一行應該提供足夠的資訊，以便他們不必閱讀 CL 的整個描述就可以獲得這個 CL 實際上是做了什麼的資訊。

按照傳統，CL 描述的第一行應該是一個完整的句子，就好像是一個命令（一個命令句）。例如，“Delete the FizzBuzz RPC and replace it with the new system.”而不是“Deleting the FizzBuzz RPC and replacing it with the new system.“ 但是，您不必把其餘的描述寫成祈使句。