上篇[1]介紹了Google軟件工程中的文化部分，本篇介紹軟件工程中主要的過程部分，包括編碼風格指南、代碼評審、技術文檔、自動化測試（單元測試、集成測試與較大型測試）與棄用。

以下是《Software Engineering at Google》一書第三部分過程篇的思維導圖，由于此部分占全書近40%，所以本文不會詳細的介紹其中的概念，想詳細了解的讀者建議閱讀原書。本文會結合此書這部分內容分享作者的個人理解及相關經驗。

風格指南(Style Guide)

We value “simple to read" over "simple to write." (Software Engineering at Google - Style Guides and Rules)

代碼可能只會被寫一次，但會被讀很多次。如果團隊成員的代碼風格都不統一，可讀性會很差，所以保持團隊代碼風格統一很重要。

歷史證明，能寫的很飄逸的編程語言使用人數一般都不會很多，典型的如古老的Perl語言，可以達到“一人千面”的代碼風格。而寫起來中規中矩甚至沒有啥高級技巧的語言如Java、Go等在工業上反而用的很多。

Google的代碼風格指南不太適合一般規模的公司，所以此部分不做過多介紹。從我的個人經驗來說，一般項目上會配置一套自動化的代碼風格檢查工具（如checkstyle[2]），甚至會集成到流水線（Pipeline）中強制團隊保持一致的代碼風格。某些編程語言如Go在構建工具中也提供了gofmt的代碼格式化工具。

代碼風格指南只能解決一些很基本的可讀性問題，如代碼縮進、函數命名風格、代碼行數限制等。但代碼的可讀性可不只體現在這些表面，更深層次的可讀性問題如API語義的可讀性該怎么解決？一個可行的實踐是代碼評審。

代碼評審(Code Review)

代碼評審是如此重要，以至于其在Google是必須做的一個實踐過程。它能提供以下的好處：

?代碼正確性：評審人員可能發現評審代碼中的邏輯問題，從而提前消除一些潛在的Bug；?代碼可讀性：代碼能否被其他人很容易的理解？API語義設計是否合理？是否包含測試？是否有必要的文檔與注釋？?代碼一致性：代碼風格是否與團隊和組織保持一致？?促進團隊知識共享：代碼評審可以讓團隊其他成員了解你所做工作的上下文；?塑造團隊工程文化：團隊保持代碼評審的實踐，本身也是團隊工程文化的一部分，能讓新的成員迅速適應團隊工程文化；

代碼評審的最佳實踐有以下：

?友善且專業?小的變更?清晰的變更描述?小規模評審?盡可能自動化?金字塔模型

代碼評審金字塔模型如下圖所示：

代碼評審的反模式是倒金字塔模型，也就是很多時間花費在了可以自動化執行的部分比如代碼風格的統一、自動化測試等，但在金字塔模型里，代碼評審應該把主要的精力放在API語義、實現語義及文檔等部分。

Code Review v.s. Code Diff

Diff 和 Review 的區別在于前者是一個團隊集體行動，團隊成員一塊看某個開發者前一天寫的代碼，這樣的好處在于每個人都能反饋，也能了解其他人做的工作，防止一些信息不同步的問題。代碼評審一般是一兩個人（可能甚至是團隊外部的人）去審查對方要合入主干分支的代碼，更適合外部人員提交代碼到主干這種 GitHub PR 分支管理模式。

我所在項目的團隊每天會做 Code Diff ，這是個必須的實踐。團隊規模在幾人以內可以讓每個人都有時間講解自己的代碼，如果代碼太多，那可以給每個人一個時間限制。如果團隊太大那可以拆分成多個 stream 來管理，總之 Diff 的人員不能太多，但每天都應該花時間做，因為收益要高于成本，可以統一代碼風格，保證可讀性，提高成員技術水平。

技術文檔(Technical Documentation)-TechnicalDocumentatio

技術文檔與代碼一樣應該得到開發者同等的重視，但有太多文檔與代碼不同步的場景出現，導致文檔的可用性大大降低。為什么會出現這種問題？一方面是因為開發者重視度不夠的問題，另外一方面是因為寫一份好的技術文檔并不是一件簡單的事情。

如何寫一份好的技術文檔？推薦閱讀如下的文章：

?Technical Writing for Developers[3]?Technical Writing | Google Developers[4]?SEO Copywriting Guide[5]

開發人員不喜歡文檔的另外一個原因在于，代碼和文檔的工作流程并不相同，一般文檔都存放在與代碼不同的位置，比如某個FTP目錄以Word的格式存在。要是文檔的編寫可以和代碼在同一套工作流里，就能極大的降低開發者的心智負擔，這正是Docs-as-code[6]的設計理念，具體的流程實踐可以看這篇文章：

?Working in public — our docs-as-code approach[7]

測試(Testing)

測試是軟件工程過程中很重要的一個組成部分，而這里的測試主要指自動化測試過程，人工測試占比很少。測試也有一個金字塔模型，如下圖所示：

關于測試金字塔的細節，推薦閱讀這篇文章：

?The Practical Test Pyramid[8]

開發人員寫自動化測試有如下好處：

?更少的Debugging：有了自動化測試后，系統的很多行為可以通過測試代碼觀察到。當然Bug一旦產生說明測試代碼覆蓋不全面，需要補上相關的測試，久而久之，測試代碼就形成了非常全面的防護網。?提升對代碼變更的信心：當有了測試防護網后，對代碼一旦產生破壞性的更新，測試代碼會失敗，這就給開發人員機會在部署前去修復此問題。?測試代碼是更好的文檔：當面對一個完全陌生的代碼庫時，除了有限的文檔，另外一個了解系統行為的方式就是看測試代碼。測試代碼相比文檔，有著更全面清晰的業務細節，能給予開發人員更多的信息去了解此業務系統。?讓代碼評審更簡單：測試代碼相比生產代碼更接近業務視角，能讓評審人員從業務系統對外行為的視角去了解生產代碼的意圖。這樣也能讓評審人員做出更有效的反饋意見。?好的測試反向提升代碼設計：要讓系統模塊具備一定的測試性才能寫出測試代碼，所以有測試的代碼從設計的角度看，其可讀性與解耦度相比沒有測試代碼的要更高。敏捷實踐中推崇的TDD(Test Driven Development)就是一種通過測試驅動出好的實現代碼的實踐。?自動化測試讓持續交付變的更容易：如果沒有自動化測試的幫助，代碼部署上去后出Bug的概率要更高，這會提高系統交付的時間。

沒有測試代碼的系統是遺留系統。

單元測試(Unit Testing)

單元測試作為占比測試金字塔最大部分的底座，重要性不言而喻。它的優勢很多，但Google在多年的實踐中發現，提高單元測試的可維護性非常重要。而難以維護的測試代碼主要有兩方面造成：

?測試脆弱：當在代碼重構、添加新特性及修復Bug時，會出現一些測試無法跑通，只能通過修改測試的方式來解決，這說明已有的測試很脆弱。好的測試應該只有在系統的業務行為發生改變時，才需要修改生產代碼和測試代碼。造成測試脆弱的原因有很多種，可能的原因包括測試隔離沒做好，比如依賴了很多共享的全局性狀態，或者測試了非公開的函數或方法，又或者測試的粒度過細，把很多實現細節給測試了。?測試不清晰：不清晰的原因也有很多方面，比如測試的名稱并沒有體現其測試意圖，在單個測試中測試了一些不必要的行為，又或包含了很多無關的信息。

要提高可維護性，一些好的實踐包括以下方面：

?測試行為而非方法：很多測試框架如Junit都倡導Given/When/Then三段式測試編寫方式，這樣可以從驗收標準(Acceptance Criteria)的業務視角去編寫測試，而非針對單個函數或方法去編寫測試（這很容易寫出脆弱的測試）。?測試名稱應提現測試行為：當單元測試失敗時，最先看到的就是測試失敗單元的名稱，好的測試名稱能以最直接的方式體現該測試意圖，所以測試名稱長一些也可以。?測試不應包含邏輯：因為測試單元本身并沒有額外的測試，如果測試包含了比較復雜的邏輯，可能會導致測試代碼的Bug。所以測試代碼中盡可能不包含邏輯計算的過程。?DAMP(Descriptive And Meaningful Phrases)原則：在生產代碼上業界倡導DRY[9](Don't repeat yourself)的基本原則。而在測試代碼中，正如上面幾條實踐表明，一定程度上的代碼冗余是有必要的，這能幫助我們編寫出簡單而清晰的測試代碼。

單元測試的代碼執行速度一定要快，但在要測試的生產代碼中，可能包含了執行速度很慢的代碼，比如網絡或文件等I/O操作，又或者對數據庫的請求，甚至需要整個應用啟動來獲得完整的執行環境。如何將這類慢的代碼與真正要測試業務邏輯的代碼隔離開來？那就是接下來要介紹的測試替身技術。

測試替身(Test Doubles)

測試替身能通過一些模擬或偽造的技術來控制被測試代碼的執行路徑，比如在OOP中我們可以通過接口的多個實現，來完成生產代碼與測試代碼的不同實現。

由于測試替身技術本身非常成熟，所以本文不做基本的介紹，推薦閱讀這篇文章進一步了解：

?TestDouble[10]

在Google的多年實踐中發現，測試替身很容易被濫用，造成很多脆弱的測試，而被濫用最多的就是打樁(Stubbing)技術。不同替身技術都有其適用場景，推薦的一個決策流程是：

?如果生產代碼的執行時間足夠快，那就不需要替身技術，直接測試生產代碼；?如果偽造（Faking）的實現成本很低，且偽造的保真度夠高（能盡可能模擬真實的使用場景），則推薦使用偽造替身技術；?如果在前兩者都不可用的情況下，僅被測試代碼只依賴少量函數或方法的返回值時，可以使用打樁(Stubbing)替身技術；?交互測試(Interaction Testing)替身技術謹慎使用，如果要用也僅在需測試函數副作用或調用次序時使用，并且不要過度測試不必要的數據；

較大型的測試(Larger Testing)

在測試金字塔的頂端是占比只有20%的集成測試與E2E測試，雖然占比少，但其卻可解決單元測試的以下問題：

?保真度的問題：單元測試因使用測試替身來加速執行時間，但替身與實現本身就存在保真度的問題，一旦被替身的實現發生改變，單元測試因模擬行為未變，可能造成一些意想不到的Bugs。?環境配置的問題：環境的問題只能在接近生產環境的測試環境（如UAT）環境中去測試與發現問題，這是單元測試無法覆蓋的測試范圍。如Google的一些重大全球性的Bug都和環境配置問題有關系。?負載下的問題：在壓力測試下，系統的行為表現如何？性能是否能達到業務要求？這類非功能性的需求測試只能在E2E測試中完成。?預期外的行為與副作用：單元測試是在開發者預期的視角下完成的，所以存在一定的視角盲區。在一個接近生產環境的測試環境測試是發現這類問題最好的辦法。?緊急行為和真空效應：如果系統的運行時環境發生一些意外的修改，如集群網絡配置或部署配置發生變更，這類問題也只能在集成環境中發現。

較大型測試的編寫與維護都是成本高昂的，在我們項目實踐中，一般和業務系統強相關的集成測試和部分E2E測試都是業務開發團隊完成的。但一些公共的E2E測試，比如某個全局性的功能性測試，可能由一個獨立的小組完成，也可能只完成一個MVP的版本，之后由業務系統維護團隊開發完成。

推薦進一步閱讀的文章：

?淺談契約測試[11]?契約測試之核心解惑[12]

棄用(Deprecation)

代碼是資產還是負債？Google的答案是負債，因為代碼需要不斷的維護才能正常工作。負債是有高昂的利息，降低負債最好的辦法就是在不需要的時候砍掉它。而這就是棄用過程的價值。

對開發人員來說，棄用是個難以接受的過程，因為幸苦寫的代碼，很難下定決心去銷毀它。所以一個中庸之道是在代碼將要被棄用前，想辦法通過演進的方式給予其二次生命。如果非要棄用，也只是停止維護和運行，舊的代碼依舊會在代碼倉庫中可被搜索到，歷史記錄也會被保留。

我的個人項目實踐是，下線一個系統是一件需要重視的過程。一個系統一旦被發布，它被使用的場景就很難以想象，API的用戶可能會以意想不到的方式去使用它。所以盡可能通過代碼搜索去找到其被使用的場景，之后再給充足的Deadline廣而告之，甚至可以主動與用戶溝通，確保不會讓其出現大的損失。

總結

代碼可能只會被寫一次，但會被讀很多次。所以軟件工程中的過程部分主要致力于解決代碼可讀性的問題。無論是風格指南、代碼評審、文檔甚至自動化測試，很大程度上都在為提高代碼可讀性。

寫代碼很容易，能寫出易懂的代碼卻有難度。所以從這個角度看，寫代碼是個入門簡單精通卻難的技能，需要我們不斷的精進，通過多種實踐去提高這個技能。希望這篇文章能讓你對寫代碼這件事有更多的理解。

審核編輯 ：李倩