Google軟件工程中主要的過程部分

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

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

風(fēng)格指南(Style Guide)

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

代碼可能只會被寫一次，但會被讀很多次。如果團(tuán)隊成員的代碼風(fēng)格都不統(tǒng)一，可讀性會很差，所以保持團(tuán)隊代碼風(fēng)格統(tǒng)一很重要。

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

Google的代碼風(fēng)格指南不太適合一般規(guī)模的公司，所以此部分不做過多介紹。從我的個人經(jīng)驗來說，一般項目上會配置一套自動化的代碼風(fēng)格檢查工具（如checkstyle[2]），甚至?xí)傻搅魉€（Pipeline）中強(qiáng)制團(tuán)隊保持一致的代碼風(fēng)格。某些編程語言如Go在構(gòu)建工具中也提供了gofmt的代碼格式化工具。

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

代碼評審(Code Review)

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

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

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

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

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

代碼評審的反模式是倒金字塔模型，也就是很多時間花費(fèi)在了可以自動化執(zhí)行的部分比如代碼風(fēng)格的統(tǒng)一、自動化測試等，但在金字塔模型里，代碼評審應(yīng)該把主要的精力放在API語義、實現(xiàn)語義及文檔等部分。

Code Review v.s. Code Diff

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

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

技術(shù)文檔(Technical Documentation)-TechnicalDocumentatio

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

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

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

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

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

測試(Testing)

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

關(guān)于測試金字塔的細(xì)節(jié)，推薦閱讀這篇文章：

?The Practical Test Pyramid[8]

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

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

沒有測試代碼的系統(tǒng)是遺留系統(tǒng)。

單元測試(Unit Testing)

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

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

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

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

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

測試替身(Test Doubles)

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

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

?TestDouble[10]

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

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

較大型的測試(Larger Testing)

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

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

較大型測試的編寫與維護(hù)都是成本高昂的，在我們項目實踐中，一般和業(yè)務(wù)系統(tǒng)強(qiáng)相關(guān)的集成測試和部分E2E測試都是業(yè)務(wù)開發(fā)團(tuán)隊完成的。但一些公共的E2E測試，比如某個全局性的功能性測試，可能由一個獨(dú)立的小組完成，也可能只完成一個MVP的版本，之后由業(yè)務(wù)系統(tǒng)維護(hù)團(tuán)隊開發(fā)完成。

推薦進(jìn)一步閱讀的文章：

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

棄用(Deprecation)

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

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

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

總結(jié)

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

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

審核編輯 ：李倩