Google軟件工程中主要的過(guò)程部分

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

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

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

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

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

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

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

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

代碼評(píng)審(Code Review)

代碼評(píng)審是如此重要，以至于其在Google是必須做的一個(gè)實(shí)踐過(guò)程。它能提供以下的好處：

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

代碼評(píng)審的最佳實(shí)踐有以下：

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

代碼評(píng)審金字塔模型如下圖所示：

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

Code Review v.s. Code Diff

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

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

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

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

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

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

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

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

測(cè)試(Testing)

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

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

?The Practical Test Pyramid[8]

開(kāi)發(fā)人員寫(xiě)自動(dòng)化測(cè)試有如下好處：

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

沒(méi)有測(cè)試代碼的系統(tǒng)是遺留系統(tǒng)。

單元測(cè)試(Unit Testing)

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

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

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

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

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

測(cè)試替身(Test Doubles)

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

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

?TestDouble[10]

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

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

較大型的測(cè)試(Larger Testing)

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

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

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

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

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

棄用(Deprecation)

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

對(duì)開(kāi)發(fā)人員來(lái)說(shuō)，棄用是個(gè)難以接受的過(guò)程，因?yàn)樾铱鄬?xiě)的代碼，很難下定決心去銷毀它。所以一個(gè)中庸之道是在代碼將要被棄用前，想辦法通過(guò)演進(jìn)的方式給予其二次生命。如果非要棄用，也只是停止維護(hù)和運(yùn)行，舊的代碼依舊會(huì)在代碼倉(cāng)庫(kù)中可被搜索到，歷史記錄也會(huì)被保留。

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

總結(jié)

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

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

審核編輯 ：李倩