上篇[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ě)代碼這件事有更多的理解。
審核編輯 :李倩
-
Google
+關(guān)注
關(guān)注
5文章
1752瀏覽量
57333 -
代碼
+關(guān)注
關(guān)注
30文章
4700瀏覽量
68114
原文標(biāo)題:Google軟件工程之過(guò)程篇
文章出處:【微信號(hào):LinuxDev,微信公眾號(hào):Linux閱碼場(chǎng)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論