99精品伊人亚洲|最近国产中文炮友|九草在线视频支援|AV网站大全最新|美女黄片免费观看|国产精品资源视频|精彩无码视频一区|91大神在线后入|伊人终合在线播放|久草综合久久中文

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

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

Linux閱碼場 ? 來源:Linux閱碼場 ? 作者:Linux閱碼場 ? 2022-09-23 11:50 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

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

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

5477e760-3ad6-11ed-9e49-dac502259ad0.jpg

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

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

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

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

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

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

代碼評審(Code Review)

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

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

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

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

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

5539c088-3ad6-11ed-9e49-dac502259ad0.png

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

Code Review v.s. Code Diff

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

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

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

56af34e8-3ad6-11ed-9e49-dac502259ad0.jpg

技術(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ā)者的心智負擔(dān),這正是Docs-as-code[6]的設(shè)計理念,具體的流程實踐可以看這篇文章:

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

測試(Testing)

56daa272-3ad6-11ed-9e49-dac502259ad0.jpg

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

57438fc6-3ad6-11ed-9e49-dac502259ad0.jpg

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

?The Practical Test Pyramid[8]

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

?更少的Debugging:有了自動化測試后,系統(tǒng)的很多行為可以通過測試代碼觀察到。當(dāng)然Bug一旦產(chǎn)生說明測試代碼覆蓋不全面,需要補上相關(guān)的測試,久而久之,測試代碼就形成了非常全面的防護網(wǎng)。?提升對代碼變更的信心:當(dāng)有了測試防護網(wǎng)后,對代碼一旦產(chǎn)生破壞性的更新,測試代碼會失敗,這就給開發(fā)人員機會在部署前去修復(fù)此問題。?測試代碼是更好的文檔:當(dāng)面對一個完全陌生的代碼庫時,除了有限的文檔,另外一個了解系統(tǒng)行為的方式就是看測試代碼。測試代碼相比文檔,有著更全面清晰的業(yè)務(wù)細節(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)

575acf92-3ad6-11ed-9e49-dac502259ad0.jpg

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

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

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

?測試行為而非方法:很多測試框架如Junit都倡導(dǎo)Given/When/Then三段式測試編寫方式,這樣可以從驗收標(biāo)準(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)

57c95aca-3ad6-11ed-9e49-dac502259ad0.jpg

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

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

?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ù)謹慎使用,如果要用也僅在需測試函數(shù)副作用或調(diào)用次序時使用,并且不要過度測試不必要的數(shù)據(jù);

較大型的測試(Larger Testing)

57e67d80-3ad6-11ed-9e49-dac502259ad0.jpg

在測試金字塔的頂端是占比只有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)系。?負載下的問題:在壓力測試下,系統(tǒng)的行為表現(xiàn)如何?性能是否能達到業(yè)務(wù)要求?這類非功能性的需求測試只能在E2E測試中完成。?預(yù)期外的行為與副作用:單元測試是在開發(fā)者預(yù)期的視角下完成的,所以存在一定的視角盲區(qū)。在一個接近生產(chǎn)環(huán)境的測試環(huán)境測試是發(fā)現(xiàn)這類問題最好的辦法。?緊急行為和真空效應(yīng):如果系統(tǒng)的運行時環(huán)境發(fā)生一些意外的修改,如集群網(wǎng)絡(luò)配置或部署配置發(fā)生變更,這類問題也只能在集成環(huán)境中發(fā)現(xiàn)。

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

推薦進一步閱讀的文章:

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

棄用(Deprecation)

57fdc936-3ad6-11ed-9e49-dac502259ad0.jpg

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

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

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

總結(jié)

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

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

審核編輯 :李倩

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • Google
    +關(guān)注

    關(guān)注

    5

    文章

    1789

    瀏覽量

    59059
  • 代碼
    +關(guān)注

    關(guān)注

    30

    文章

    4900

    瀏覽量

    70776

原文標(biāo)題:Google軟件工程之過程篇

文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    Google Fast Pair服務(wù)簡介

    其谷歌賬號,并嘗試配對已保存到其谷歌賬號的設(shè)備時所發(fā)生的一系列事件。在此過程中,新手機會識別出廣播里的Model ID ,它已保存到用戶的 Google 帳號,并提供一條通知,以加快將該設(shè)備與這部
    發(fā)表于 06-29 19:28

    如何成為一名嵌入式軟件工程師?

    如何成為一名嵌入式軟件工程師? 01明確崗位的角色與定位 嵌入式軟件工程主要負責(zé)開發(fā)運行在特定硬件平臺上的軟件,這些軟件通常與硬件緊密集
    發(fā)表于 04-15 14:37

    學(xué)硬件好還是學(xué)軟件好?

    、計算機硬件等領(lǐng)域相關(guān)。 學(xué)習(xí)軟件則側(cè)重于編程、算法、數(shù)據(jù)結(jié)構(gòu)等方面。軟件工程師負責(zé)開發(fā)、測試和維護各種軟件應(yīng)用程序,如操作系統(tǒng)、辦公軟件、游戲等。如果你對編程、數(shù)學(xué)、邏輯或解決復(fù)雜問
    發(fā)表于 04-07 15:27

    半導(dǎo)體制造過程中的三個主要階段

    前段工藝(Front-End)、中段工藝(Middle-End)和后段工藝(Back-End)是半導(dǎo)體制造過程中的三個主要階段,它們在制造過程中扮演著不同的角色。
    的頭像 發(fā)表于 03-28 09:47 ?2728次閱讀
    半導(dǎo)體制造<b class='flag-5'>過程中</b>的三個<b class='flag-5'>主要</b>階段

    嵌入式軟件工程師就業(yè)好不好?

    嵌入式軟件工程師就業(yè)好不好?會不會越老越吃香?今天一起來看看。 首先看下市場需求。 隨著物聯(lián)網(wǎng)、人工智能、5G等前沿技術(shù)的快速發(fā)展,嵌入式系統(tǒng)的應(yīng)用領(lǐng)域不斷擴大,從智能家居、汽車電子到工業(yè)自動化
    發(fā)表于 02-20 10:19

    Google Play如何幫助您的應(yīng)用變現(xiàn)

    Play Partner Day 活動的應(yīng)用專題演講,我們分享了市場、用戶、變現(xiàn)等方面的干貨,包括 Google Play 的變現(xiàn)工具和不同類型應(yīng)用的用戶特點,如何留住用戶、吸引用戶回流,以及如何拓展
    的頭像 發(fā)表于 01-21 11:21 ?701次閱讀
    <b class='flag-5'>Google</b> Play如何幫助您的應(yīng)用變現(xiàn)

    Testin云測獲智能化軟件工程工作組優(yōu)秀單位榮譽

    隨著人工智能技術(shù)的深度應(yīng)用,大模型等AI技術(shù)在推動軟件行業(yè)智能化進程的重要性日益凸顯。軟件工程,作為大模型、智能體等AI技術(shù)落地應(yīng)用的前沿領(lǐng)域,正加速推進智能化轉(zhuǎn)型。在這場變革,企
    的頭像 發(fā)表于 01-21 10:46 ?375次閱讀

    伺服電機滑環(huán)的主要組成部分,伺服電機滑環(huán)怎么安裝?

    伺服電機滑環(huán)是一種用于電機與轉(zhuǎn)動部分之間傳遞電信號和電力的裝置。它主要用于需要360度連續(xù)旋轉(zhuǎn)的系統(tǒng),能夠有效解決傳統(tǒng)電纜在旋轉(zhuǎn)過程中扭結(jié)、磨損的問題。
    的頭像 發(fā)表于 01-06 09:36 ?632次閱讀
    伺服電機滑環(huán)的<b class='flag-5'>主要</b>組成<b class='flag-5'>部分</b>,伺服電機滑環(huán)怎么安裝?

    架構(gòu)建模與優(yōu)化咨詢和實施服務(wù)

    得益于硬件平臺算力的提升,汽車電子電氣架構(gòu)的集成度逐漸提高,從單體ECU、到功能域集成控制器、到區(qū)域集成控制器,多域融合成為了目前行業(yè)軟件工程的重要工作內(nèi)容。經(jīng)緯恒潤可以為汽車電子和軟件工程師在開發(fā)
    的頭像 發(fā)表于 12-27 14:21 ?1051次閱讀
    架構(gòu)建模與優(yōu)化咨詢和實施服務(wù)

    特斯拉招募軟件工程師強化無人駕駛與機器人遠程操作

    近日,據(jù)外媒最新報道,特斯拉正緊鑼密鼓地招募軟件工程師團隊,旨在加強其無人駕駛出租車及Optimus機器人的遠程操作能力。這一舉措標(biāo)志著特斯拉在推動自動駕駛與人工智能領(lǐng)域邁出了重要一步。 特斯拉此次
    的頭像 發(fā)表于 11-27 10:26 ?1022次閱讀

    工業(yè)工程軟件在企業(yè)導(dǎo)入的重要性與必要性

    在全球化競爭加劇、市場需求瞬息萬變的今天,企業(yè)為了保持競爭力,需要不斷優(yōu)化生產(chǎn)流程、提高生產(chǎn)效率、降低成本并保障產(chǎn)品質(zhì)量。而工業(yè)工程軟件作為一種強大的工具,其在企業(yè)導(dǎo)入的重要性和必要性日益凸顯
    的頭像 發(fā)表于 10-18 11:09 ?617次閱讀

    基于FPA的軟件工作量綜合評估研究與實踐

    軟件工程監(jiān)理項目中如何對軟件開發(fā)系統(tǒng)進行工作量評估,如何在實施過程中對承建單位已完成的工作量進行審核是實施信息化項目的難題。本文在分析專家經(jīng)驗評估法、FPA功能點分析法等方法的基礎(chǔ)上,給出了一種
    發(fā)表于 10-15 10:45 ?0次下載

    【「數(shù)字IC設(shè)計入門」閱讀體驗】+ 概觀

    寄存器、控制芯片運行狀態(tài),這些開發(fā)都是基于芯片提供的功能進行操作的,軟件工程師根據(jù)數(shù)據(jù)手冊對芯片進行操作,這些操作都是有套路的,這些套路是芯片設(shè)計好的,軟件工程師無法更改,感覺芯片內(nèi)部的運行過程真的很
    發(fā)表于 09-24 10:58