狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

作者：xindoo

https://segmentfault.com/a/1190000041885333

在一個成熟的團(tuán)隊中，CodeReview 是整個研發(fā)流程中不可或缺的一步，而那些即將走向成熟的團(tuán)隊可能對 CodeReview 有很多的誤解和問題，也不清楚 CodeReview 該如何去做，本文筆者將結(jié)合自己的經(jīng)驗(yàn)和知識，談?wù)勎覍?CodeReview 流程的一些理解和建議 。

什么是CodeReview

CodeReview 國內(nèi)也稱「代碼評審或者代碼審查」，也簡稱CR，是指在軟件開發(fā)過程中，工程師對其他人所寫代碼做審閱（后文統(tǒng)稱CodeReview），以達(dá)到控制代碼質(zhì)量的目的。通常的流程都是由代碼寫作者發(fā)起，請團(tuán)隊內(nèi)其他人審閱代碼，其他人對代碼提出改進(jìn)建議，再由代碼寫作者修改重新提交，直至代碼通過大家的審閱為止。

為什么要做CodeReview？

其實(shí)很多人都不是很重視CodeReview，因?yàn)镃odeReview的效果短期很難看到，也很難量化衡量。就如同運(yùn)動一樣，偶爾過量的運(yùn)動不僅對身體無益，可能還會起反作用，不過長期的堅持肯定會讓你更健康，但能讓你健康多少很難量化，不過前一段時間github上爆火的項目《程序猿延壽指南》里給出了可參考的數(shù)據(jù)，每周3次45分鐘揮拍運(yùn)動可以減少全因死亡率47%，按其公式折算大概增加9年的預(yù)期壽命。運(yùn)動除了增加預(yù)期壽命外，也能顯著減少很多疾病的發(fā)病率。堅持CodeReview如同堅持運(yùn)動一樣，趨勢肯定是讓整個代碼庫更為健康長壽。

CodeReview從長期來看，有幾個明顯的好處，接下來就一一講一下。

提升代碼質(zhì)量

假如將一個系統(tǒng)比作一個生命體，一行行代碼比作一個個細(xì)胞，不好的設(shè)計宛如癌細(xì)胞，會逐漸擴(kuò)散，終將殺死系統(tǒng)。而CodeReview的過程就像是T細(xì)胞吞噬掉癌細(xì)胞，保證系統(tǒng)的健康成長。讓系統(tǒng)有更長久的生命力。

「沒有人Review的代碼，其代碼水準(zhǔn)就是寫代碼人的水準(zhǔn)，而被一個團(tuán)隊Review過的代碼，它的水準(zhǔn)將接近甚至超過整個團(tuán)隊的最高水準(zhǔn)。」

因?yàn)閱蝹€人可能在某些方便做的比較好，集大家之所長就能在各個方面都做的比較好。另外，隨著CodeReview流程日常化，每個參與人的編碼能力也會逐步提升，無限趨近于團(tuán)隊最高水準(zhǔn)，因?yàn)樵贑odeReview的過程中，你可以看到別人做的好的地方，可以學(xué)習(xí)到經(jīng)驗(yàn)，也可以看到別人做的不好的地方，吸取到教訓(xùn)。隨著時間的流逝，逐漸積累為參與者的能力。

提前發(fā)現(xiàn)問題

在沒有CodeReview流程的時候，我們都是依賴于測試，甚至是依賴于功能上線后用戶暴露問題，這種發(fā)現(xiàn)方式已經(jīng)偏晚了，尤其是讓用戶暴露問題的時候可能問題已經(jīng)非常大了。「問題暴露的越晚，風(fēng)險也就越大」。而CodeReview一般是放在代碼測試之前，如果能在這個階段就發(fā)現(xiàn)問題就能提前將各種風(fēng)險扼殺在搖籃中。但是，CodeReview真的能提前發(fā)現(xiàn)問題嗎？如果能的話，可以提前發(fā)現(xiàn)什么樣的問題？

我個人覺得CodeReview可以提前發(fā)現(xiàn)流程或者實(shí)現(xiàn)上的問題，尤其是在做業(yè)務(wù)需求的時候，不同工作經(jīng)驗(yàn)的人對同一個需求的理解肯定會有差異，代碼實(shí)現(xiàn)上也會有很大的差異，有時候一點(diǎn)點(diǎn)的理解偏差，導(dǎo)致出現(xiàn)那種失之毫厘謬以千里的后果，寫代碼的人也會因?yàn)樘幵谧约旱乃季S定式中發(fā)現(xiàn)不了問題，而別人可能因?yàn)榻?jīng)驗(yàn)豐富或者需求相關(guān)背景了解更多，就能很輕易發(fā)現(xiàn)問題。像這種情況一般出現(xiàn)在團(tuán)隊新人身上，他們對已有系統(tǒng)和業(yè)務(wù)了解不多，實(shí)現(xiàn)需求時很容易出現(xiàn)問題，這時候如果有人幫忙指出就能避免更嚴(yán)重的后果，另外也有助于新人了解業(yè)務(wù)和融入團(tuán)隊。

在CodeReview過程中另外一種問題也比較容易發(fā)現(xiàn)，就是那些別人之前踩過的坑。比如Java中SimpleDateFormat其實(shí)有線程安全的問題，不了解的人很容易就踩坑了。如果別人踩過這個坑，就可以在CodeReview過程中提前幫你指出來。很多開源的類庫，甚至Jdk中很多包或多或少都有使用上的坑…… 這種例子就數(shù)不勝數(shù)了。

當(dāng)然CodeReview也不是萬能的，也有很多問題發(fā)現(xiàn)不了的，比如一些邊緣Case或者是代碼計算結(jié)果的準(zhǔn)確性，比如你代碼實(shí)現(xiàn)了一個很復(fù)雜公式的計算，你總不能指望有人能通過看代碼來發(fā)現(xiàn)問題吧。這些還是老老實(shí)實(shí)去做測試吧！

經(jīng)驗(yàn)和知識的傳遞

程序猿可以寫出能運(yùn)行的代碼，但真正的工程師才能寫出低bug、易擴(kuò)展、易維護(hù)的高質(zhì)量代碼，更高級的工程師還能幫其他人成為一名合格的工程師。CodeReview的流程也是高級工程師來幫助其他人最直接的方式。

在CodeReview中，你可以看到其他人寫出來的優(yōu)秀代碼、優(yōu)秀的設(shè)計，甚至和改動相關(guān)的業(yè)務(wù)背景知識……，Review越多，學(xué)到的也越多。另外，即便是哪些不太好的代碼，經(jīng)過別人的Review，必然會留下很多評論或者是改動建議，甚至是別人之前踩的坑，你都能看到，從這些內(nèi)容上你也可以學(xué)到很多新的知識。CodeReview不僅僅是一個提升代碼質(zhì)量方式，它也可以肩負(fù)起知識積累和消息集散的功能。

舉個我之前遇到過的例子，我們之前有個功能需要操作機(jī)器上的文件，當(dāng)然用Java的File也能實(shí)現(xiàn)，但是對操作多層級的文件夾時就很不方便了，需要自己寫很多的代碼，搞不好還容易出bug。后來我發(fā)現(xiàn)apache-common包中提供了IOUtils類，可以很方便操作文件夾。我把這個寫到CodeReview的評論中，只要看到過的人都會知道原來有這個東西可以用。

所以，Review別人代碼時請毫不吝嗇地留下你的建議吧，另外，CodeReview時也不要忘記關(guān)注下別人的建議，說不定可以學(xué)到新的東西。

如何做好CodeReview

說完了CodeReview的好處，相信你肯定已經(jīng)躍躍欲試了，如何能做好CodeReview？這里我根據(jù)我的知識和經(jīng)驗(yàn)分享下我的看法。

CodeReview的步驟

了解改動的背景

CodeReview不是一上來就看代碼，這樣有可能你會看的云里霧里，純粹是浪費(fèi)時間。CodeReview雖然是Review代碼，但是首先你的知道你要看的代碼實(shí)現(xiàn)了什么樣的功能，是在什么樣的背景下去做的，清楚前因后果之后，你才能知道這個代碼大概應(yīng)該怎么去寫，你才能更好的去Review別人的代碼、去發(fā)現(xiàn)別人的問題。

縱觀全局

知道背景之后，在你腦海中就會有一個大概的編碼思路，也有個流程主線。這個時候可能有兩種情況，你和寫代碼人的思路相同，那你就順著你們共同的思路去幫忙Review整個流程是否正確。另一種情況就是你們思路不同，你就得看代碼去了解寫作者的思路，然后確認(rèn)是誰的思路有問題，或者是誰的思路更好，然后同寫作者一起將這個流程優(yōu)化到更優(yōu)。

逐層細(xì)化

確定完整個流程之后，就可以逐步深入到代碼細(xì)節(jié)中了，細(xì)節(jié)可以Review的地方就很多了，可以看下下一節(jié)的內(nèi)容，這里就先不展開了。

CodeReview的關(guān)注點(diǎn)

在CodeReview的過程中，如果有一些立足點(diǎn)的話可以幫助大家更好的完成CodeReview的過程，我大概總結(jié)出以下幾點(diǎn)：

• 「功能性：」 代碼所實(shí)現(xiàn)的功能是否和預(yù)期一樣，是否實(shí)現(xiàn)了所有必須的功能？
• 「復(fù)雜性：」 功能實(shí)現(xiàn)是否過于復(fù)雜？過于復(fù)雜的代碼更容易出問題，而且可維護(hù)性也會更低。
• 「代碼風(fēng)格：」 代碼是否符合團(tuán)隊編碼規(guī)范？
• 「文檔&注釋：」 如果代碼功能有改動，關(guān)注下相關(guān)文檔和注釋有沒有同步改動。錯誤的注釋和文檔可能會讓未來的開發(fā)者產(chǎn)生理解成本。
• 「代碼亮點(diǎn)：」 如果你看到變更中做得好的地方，也別吝嗇你的贊美。

上面描述更偏概括性，我們來舉一些更詳細(xì)的例子，幫助大家理解上面幾點(diǎn)。

• 代碼設(shè)計良好，可讀性和可維護(hù)性高。
• 是否有線程安全的bug。
• 代碼沒有增加不必要的復(fù)雜性。
• 開發(fā)者沒有寫一些目前沒有在用的代碼，這種無用的代碼未來大概率也不會用，所以不要假設(shè)。
• 代碼有適當(dāng)?shù)膯卧獪y試。
• 測試邏輯設(shè)計良好。
• 開發(fā)者使用了清晰明了的變量和函數(shù)命名。
• 注釋清晰明了且實(shí)用，并且解釋清楚了為什么這么做，而不僅僅是做了啥。
• 代碼有相應(yīng)完善的文檔。
• 代碼風(fēng)格符合規(guī)范。
• 代碼有沒有更優(yōu)的實(shí)現(xiàn)？（性能、資源占用……）
• …… 更多更細(xì)節(jié)的內(nèi)容，可以參考谷歌工程實(shí)踐——代碼評審

注意事項

CodeReview的禮節(jié)

首先CodeReview不是你個人炫技的舞臺，看到別人代碼的問題需要禮貌指出，切忌diss別人。其次，CodeReview不要為了提問題而提問題，有些代碼就是沒問題，你也沒必要糾結(jié)必須要提個問題，直接通過即可。這里在額外說一點(diǎn)，大部分Review別人的代碼，只關(guān)注到別人做的不好的地方，而忽視了別人做的好的地方，遇到好的代碼、好的設(shè)計也別忘記點(diǎn)個贊。

CodeReview應(yīng)當(dāng)及時

別人提的CodeReview應(yīng)當(dāng)及時處理，在很多公司中CodeReview是開發(fā)流程中必要的一環(huán)，沒有Review通過的肯定是不能上線的，如果CodeReview長時間不處理可能會延誤后續(xù)的流程。另外一點(diǎn)，CodeReview是相互的，今天你及時幫別人Review了，明天別人也會及時幫你Review，「與人方便即與己方便」。

如何寫出對CodeReview友好的代碼

「程序?qū)懗鰜硎墙o人看的，附帶能在機(jī)器上運(yùn)行。——Harold Abelson」

時刻謹(jǐn)記上面這句話。

提交前先做好自審

提前自己處理掉一些低級錯誤，可以先借助一些工具完成一些簡單的檢查。例如我們團(tuán)隊會借助checkstyle、spotbug、sonar、pmd等工具完成代碼風(fēng)格和一些潛在bug的檢查。然后自己做好功能的自測，盡可能先消滅一部分bug，為CodeReview減少一些負(fù)擔(dān)。

寫清楚變更描述

這里對應(yīng)上文中CodeReview步驟中的了解改動背景，作為代碼的寫作者，你不能一上來就讓別人從代碼入手吧，可能看你代碼的很多其他人都缺少代碼改動相關(guān)的上下文信息，完全理解代碼成本很高，所以需要在變更描述中將這些信息描述清楚，包括但不僅限于改動背景、改動點(diǎn)、流程、具體設(shè)計…… 一句話概括就是「好的變更描述應(yīng)該說清楚這次是做了什么變更，以及為什么要這么做」。

更詳實(shí)的變更描述可以讓Review代碼人減少理解成本，更快完成CodeReview的流程，你代碼改動也就能更快進(jìn)入后續(xù)流程了。

單個變更盡可能短

一個非常大的變更幾乎沒有Review，因?yàn)榇蟮母膭邮紫染秃茈yReview，其實(shí)也更耗費(fèi)時間，還有出問題的概率也更大，誰Review通過了代碼但之后上線出問題，可能是要和你一起背鍋的。所以建議大家將大的代碼變更盡可能拆小，因?yàn)樾〉淖兏幸韵逻@些好處:

• 「代碼評審更快」 與比起花30分鐘評審一個大的變更相比，對Review代碼的人來說花5分鐘審查一系列小的變更更加容易.
• Review「更加徹底。」 進(jìn)行較大的更改后，審閱者和作者往往會因大量詳細(xì)評論的來回移動而感到沮喪，有時這些評論會漏掉或遺漏重要的觀點(diǎn)。
• 「減少導(dǎo)致bug的可能性。」 由于您所做的更改較少，因此您和您的審閱者更容易有效地推斷出CL的影響，并查看是否導(dǎo)致bug。
• 「減少不必要的工作」 當(dāng)你寫了一個巨大的變更，然后評審者覺得你總體方向錯了，這會導(dǎo)致你浪費(fèi)大量的工作。
• 「更方便合并代碼」 因?yàn)榇笮偷淖兏鼤?dǎo)致大量的沖突，因此合代碼的時候會耗費(fèi)很多時間，而且可能因合并代碼導(dǎo)致問題，我們就出現(xiàn)過好幾次代碼合并的時候沖掉別人代碼的情況。
• 「有助于你作出更好的設(shè)計」 優(yōu)雅的設(shè)計并且完善一個小的改動比大的改動更加容易
• 「降低評審者的難度」 提審部分改動，不會影響你繼續(xù)編碼。
• 「如果真出問題，回滾更容易」 這個就不用多解釋了吧。

對于那些很難拆分的變更，也不是需要完全禁止，有時候就是有改動非常大，而且無法再去拆分了，這時候還是建議通過其他方式來保證代碼質(zhì)量，比如全流程測試。然后也建議做好出問題時的快速恢復(fù)方案。

注意事項

注意自己的情緒

代碼的寫作者在CodeReview的流程中是弱勢的一方，很多人代碼在收到評論被要求要修改代碼的時候，都有一種不太愿意接受的心態(tài)，其實(shí)我自己也經(jīng)常會有這種心態(tài)，尤其是在時間比較緊張的情況下。其實(shí)這是很正常的心態(tài)，但是還是需要去控制自己的情緒的，從評論者的角度出發(fā)，他肯定也不是在刁難你，也是希望代碼質(zhì)量能更高。如果真遇到這種情況，首先可以和評論者討論清楚他的要求是否合理，如果確定了合理性當(dāng)然還是要改的。但如果在時間比較緊張的情況下，協(xié)商是否可以不修改或者是之后再修改，確實(shí)有些錦上添花的修改沒必要阻塞之后的流程。

CodeReview流程應(yīng)該盡早提交

日常情況下，還是建議早點(diǎn)提交CodeReview，并留出一定的時間來做修改，盡可能不要讓這個流程變的匆忙。大部分公司的實(shí)踐都是在進(jìn)入測試流程的時候同時進(jìn)入CodeReview流程。

關(guān)于CodeReview的幾個誤區(qū)

CodeReview是純浪費(fèi)時間？

如果你的團(tuán)隊剛開始推行CodeReview流程，這個問題肯定是會被很多人問到的。所以是不是呢? 這里我拿鍛煉身體類比下，大家都知道堅持運(yùn)動對健康有益，但如果只是一時興起，偶爾過量的運(yùn)動不僅對身體無益，可能還會起反作用。實(shí)際上，堅持運(yùn)動對健康的影響其實(shí)很難量化，但我們現(xiàn)在都知道，運(yùn)動是好的。同樣，CodeReview如同運(yùn)動一樣，它可能會耗費(fèi)一定的精力和時間，但長期堅持下來必然會讓整個代碼庫、整個系統(tǒng)甚至這個團(tuán)隊更加健康。

另外，如果一個團(tuán)隊CodeReview機(jī)制很成熟，寫代碼的人隨著被Review的次數(shù)增加，其代碼質(zhì)量必然也會逐步提交，那么代碼中的問題肯定也會逐步減少，隨之而來的就是CodeReview的過程越來越輕松。

「困難的路會越走越簡單，而簡單的路會越走越困難。」

工期很緊，沒時間做CodeReview！

這也是很多團(tuán)隊不做CodeReview的借口。你不做CodeReview省下的時間，會在后面測試，甚至是在后面長期維護(hù)中花費(fèi)更多的時間。我們有句耳熟能詳?shù)睦显捊凶觥澳サ恫徽`砍柴工”，其實(shí)CodeReview和測試在軟件開發(fā)過程中就是“磨刀”的工作。

「做好事前控制而不是事后彌補(bǔ)。因?yàn)闀r候彌補(bǔ)的代價會非常高，」

只有高級工程師才有資格Review別人代碼？

雖然事實(shí)上幾乎都是高級工程師在Review別人的代碼，我理解造成這種現(xiàn)象的原因其實(shí)也比較簡單，高級工程師確實(shí)經(jīng)驗(yàn)豐富一些，也更容易Review出別人代碼中的問題，所以會留下更多的Review記錄，造成只有高級工程師才參與CodeReview的假象。但這絕不意味著初級工程師沒有資格Review別人的代碼，所謂三人行必有我?guī)煟幢闶浅跫壒こ處熞灿锌赡馨l(fā)現(xiàn)Review出別人代碼中的問題。

即便你暫時確實(shí)經(jīng)驗(yàn)不夠豐富，很難找出別人的問題，但你也可以從別人Review代碼的過程中學(xué)到很多東西，就像上文所說CodeReview也是團(tuán)妒經(jīng)驗(yàn)和知識的一種傳遞方式。參與CodeReview也是成為高級工程師必不可少的一步。

都有測試流程了，為什么還要做CodeReview？

這個問題算是已經(jīng)在上文中回答過了，CodeReview需要看很多個方面的內(nèi)容，而測試只能保證其結(jié)果的準(zhǔn)確性。

有了CodeReview就不需要測試了？

問這個問題的人相比于問上個問題的人又走了另一個極端，又把CodeReview和測試放在了對立面上。雖然CodeReview如果做的比較好的話，確實(shí)能提前發(fā)現(xiàn)一些比較明顯的問題，但是做CodeReview的是人，人是無法大規(guī)模且精準(zhǔn)的去校驗(yàn)程序的執(zhí)行過程，而這恰恰是自動化測試所擅長的，所以說CodeReview和測試并不是對立關(guān)系，而是一種互補(bǔ)關(guān)系。

只要我在團(tuán)隊推行了CodeReview流程，代碼質(zhì)量就會迅速提高？

首先可以肯定的是代碼質(zhì)量是會提高的，但也許沒有那么快。我之前從一個沒有CodeReview流程的團(tuán)隊加入到一個有嚴(yán)格CodeReview流程的團(tuán)隊時，有較長一段適應(yīng)期。我當(dāng)時最大的感受就是CodeReview太耗時間了，尤其是我剛開始還沒適應(yīng)新團(tuán)隊開發(fā)規(guī)范的時候，寫代碼和被Review后改代碼所花費(fèi)的時間基本上五五開，當(dāng)然之后會好很多。另外，每個人也需要花20%左右的時間和精力去Review別人的代碼，相當(dāng)于花接近三分之一的開發(fā)時間來處理CodeReview相關(guān)工作，這個比例高到可能你們老板都會懷疑，但我們當(dāng)時就做到了，結(jié)果就是我們的代碼質(zhì)量非常高。

以我的經(jīng)歷來看，如果CodeReview想要有效果，時間投入肯定是少不了的，冰凍三尺非一日之寒,滴水石穿非一日之功。不要高估它的短期價值，也不要低估它的長期價值。

參考資料

• 谷歌工程實(shí)踐——代碼評審 https://github.com/xindoo/eng-practices-cn