時光匆匆流逝~

今天是工程能力學習的最后一篇筆記了！

首先給堅持努力的自己呱唧呱唧！

然后搬好前排小板凳

學習啦！

本節(jié)課為《如何做好Code Review》，內(nèi)容包括：為什么要做好Code Review、如何做好Code Review、例子：Python代碼的Code Review、如何成為一個好的reviewer和公司針對Code Review的措施五個方面。

為什么要做好Code Review

Code Review是提升代碼質(zhì)量的最好方法

強化Code Review是提升代碼質(zhì)量的第一選擇。

在代碼開發(fā)過程中，我們越早發(fā)現(xiàn)問題、定位問題，在修復問題時付出的成本越小。

大約有50%以上的bug，都是在做Code Review時發(fā)現(xiàn)的。前期做好Code Review，后期將會減少反復修改等不必要的復工。

Code Review能夠在團隊內(nèi)傳遞知識

從知識傳遞的角度看，Code Review是極為重要的。

做好Code Review，能夠幫助團隊傳遞知識、溝通交流、互相學習，能夠提升學習能力、提升編寫代碼能力、提升代碼質(zhì)量、提升工作效率、降低項目風險。

另外，基于codebase可以使我們了解項目全局，培養(yǎng)系統(tǒng)的思考方式。

Code Review是輔導怎么寫代碼的最好方法

我們要意識到，做Code Review可以學習到別人的經(jīng)驗，同時也可以向別人傳遞我們的經(jīng)驗。

如果我們想輔導別人，最好的辦法就是讓對方先寫一段代碼，我們對他的代碼進行Code Review。在輔導他人的過程中，我們可以快速地發(fā)現(xiàn)問題，從而幫助改進。

做好Code Review 可以增加公司對最頂級開發(fā)者的吸引力

工作中是否有Code Review對于公司或團隊來說非常重要。不但對于公司或團隊內(nèi)的人員有所提升，而且能夠吸引出色的開發(fā)者加入開發(fā)團隊。

未做好Code Review的公司或團隊有如下特點：

①代碼質(zhì)量差。

②團隊內(nèi)人員備份差。

③其人得不到有效的輔導，提高慢。

為什要提高代碼質(zhì)量？

①提高代碼質(zhì)量可以提高代碼的可讀性。

②提高代碼質(zhì)量可以提高代碼的復用性和參考性。

③提高代碼質(zhì)量可以減少bug出現(xiàn)的風險。

④提高代碼質(zhì)量可以減少后期補丁的風險。

⑤提高代碼質(zhì)量可以降低代碼失控的風險。

⑥提高代碼質(zhì)量可以降低項目重構(gòu)和升級的麻煩。

為什么要提高寫代碼的能力

①代碼能力如果停滯不前，對于個人而言，將導致職業(yè)危機。

②代碼能力如果停滯不前，對于團隊而言，將意味著團隊沒有成長。

Code Review是一個非常重要的提升代碼質(zhì)量和代碼能力的手段。無論是從個人發(fā)展角度，還是團隊發(fā)展角度，我們都需要重視Code Review。

如何做好Code Review

在Code Review中可能發(fā)現(xiàn)的問題

→ 拼寫錯誤；

→ 未優(yōu)化的代碼；

→ 不必要的復雜代碼；

→ 已經(jīng)實現(xiàn)過的代碼，又重復實現(xiàn)；

→ 注釋不全；

→ case沒有覆蓋全等等問題。

在Code Review中要有一個好的態(tài)度 要做到以下幾點

（1）對所有檢查的代碼邏輯要做到“完全看懂”，對于審核的代碼，熟悉程度要做到“如數(shù)家珍”。如果在審核代碼后，對代碼的邏輯和背后的原因仍然很模糊，則是一個失敗的Code Review。

（2）好代碼的標準，不僅僅是“可以運行通過”，在正確性、可讀性、可重用性、可運維性等方面上，都需要綜合考慮。

（3）建立Code Review和寫代碼一樣重要的意識。即：

①Code Review和寫代碼一樣，也有產(chǎn)出，即產(chǎn)出更高質(zhì)量的代碼。

② 審核代碼在很多情況下比寫代碼還要辛苦，需要理解和找出問題等。

（4）以提升代碼質(zhì)量為最終目標。

（5）要投入足夠的時間和精力。

①審核代碼花費的時間經(jīng)常和寫代碼一樣多，有時甚至比寫代碼的時間更多，要有時間意識。

②要有責任意識。如果出現(xiàn)bug，不僅僅是寫代碼人員的職責，也不僅僅是QA的職責，代碼審核者也需要承擔相當大的責任。

在Code Review之前，一流代碼的特性

一流代碼有以下特性：①高效性；②魯棒性；③簡潔；④簡短；⑤可共享；⑥可測試；⑦可移植；⑧可監(jiān)控；⑨可運維；⑩可擴展。

將以上十條標準進行總結(jié)精簡，可歸納為：

①代碼的正確和性能；

②代碼的可讀和可維護性；

③代碼的可運維和可運行；

④代碼的可共享和可重用；

在Code Review時，綜合考慮以上一流代碼的特性，可以快速提升代碼質(zhì)量、提升編寫代碼的能力等。

在Code Review時 需要有對bad code 進行簡單判斷的能力

除了要了解一流代碼的特性之外，在Code Review時，需要有對bad code 進行簡單判斷的能力。通常bad code有以下特點：

①5分鐘內(nèi)不能看懂的代碼。

不能快速看懂的代碼，一定是有問題的代碼，可以先拋回給編寫代碼人員進行修正。一般一個函數(shù)的操作不能超過6個step，如果超過這個數(shù)量，則需要重新調(diào)整編碼邏輯。

②需要思考才能看懂的代碼。

好的代碼閱讀時基本不用動腦子，甚至看注釋就能看懂。

③需要來回翻屏才能看懂的代碼。

好的代碼，經(jīng)常在一屏內(nèi)就是一個完整的邏輯。

④沒有空行或注釋的代碼。

在Code Review時，發(fā)現(xiàn)不會用段落、不會寫注釋的代碼，肯定不是好的程序員寫的代碼，可以直接打回給編寫代碼人員進行修正。

Code Review的注意事項

①在必要時，review的雙方做面對面的溝通。

面對面溝通并不是單指當面溝通，還包括云共享、電話、視頻溝通等。在溝通時，對于背景、關鍵點等應進行說明，便于reviewer的理解。在必要時，應提供設計文檔。

②對于關鍵模塊，應該建立owner制度。

所有提交的代碼，必須由owner做最終確認。由owner掌握全局，并建立明確的責任關系。

③檢查中發(fā)現(xiàn)的問題，要一追到底。

④要注意細節(jié)。對每一行提交的代碼，都要進行檢查。

⑤Code Review的方式，要小步快跑。每次提交review的代碼量不要太多，降低復雜度。在特殊情況時，比如一個新模塊的構(gòu)建，最好逐步完成，通過多次進行提交。

⑥要為Code Review預留出足夠的時間。Code Review VS Coding的時間，有時可能達到1:1。在這里需要考慮到有時會做大的修改，科學地規(guī)劃工作量，盡量避免出現(xiàn)時間倒排。

⑦注意每天 review代碼的數(shù)量不宜過多。

Code Review的步驟

Code Review的步驟為以下幾點：

Step1：先看系統(tǒng)全貌

不深究細節(jié)，瀏覽系統(tǒng)全貌，理清模塊劃分的邏輯、模塊間的關系、如何構(gòu)成的整個系統(tǒng)等。

Step2：進入模塊級別

同樣不深究細節(jié)，瀏覽模塊內(nèi)的全貌，判斷模塊切分是否合理，理清模塊內(nèi)的邏輯，明確關鍵數(shù)據(jù)、關鍵的類和函數(shù)等。

Step3：理清類、函數(shù)內(nèi)部的邏輯。

Step4：進入細節(jié)。

比如Layout、命名等。

人為因素

除了代碼上的問題，在Code Review過程中還會有一些人為因素，例如：

①Q(mào)A人員

好的QA人員不僅僅會發(fā)現(xiàn)系統(tǒng)中的bug，還會質(zhì)疑或提出產(chǎn)品需求，挑戰(zhàn)或優(yōu)化系統(tǒng)架構(gòu)和實現(xiàn)方式。

②Code Reviewer

好的代碼審核人員不僅僅指出代碼表面的問題，還會檢查系統(tǒng)需求分析的質(zhì)量、接口或函數(shù)定義的合理性、模塊劃分的合理性、系統(tǒng)關鍵機制的合理性等。

例子：Python代碼的 Code Review

以Python為例，從Python的編碼規(guī)范和Python編程規(guī)范的部分說明兩個維度來看一下Code Review的細節(jié)。這些Code Review細節(jié)，在其他語言中基本都是相通的。

Python的編碼規(guī)范

（1）代碼要寫的漂亮。

（2）代碼要明確直接，不要含蓄表達。

（3）代碼要簡潔，一個函數(shù)可以實現(xiàn)的功能就不要寫兩個函數(shù)。

（4）代碼深奧勝過代碼復雜。代碼可以寫的深奧難懂，但是不能寫的過于復雜。

（5）代碼要平鋪直敘，不要層層嵌套。

（6）代碼要做到合理間隔。

（7）代碼可讀性非常重要。

（8）代碼要有普適性。盡量規(guī)避代碼特殊性，用最簡潔最通用的代碼來實現(xiàn)。

（9）代碼要實用。

（10）要重視所有發(fā)現(xiàn)的錯誤。

（11）代碼邏輯要清晰。在含糊混亂的面前，我們要拒絕猜測。讀寫代碼時，不要出現(xiàn)“好像”、“可能”、“似乎”等猜測。當一段代碼很難懂的時候，代碼一定存在問題。

（12）寫代碼要注重行動。

（13）代碼實現(xiàn)方法要簡潔。如果一個方法很難解釋，就意味著這個方法存在一定的問題。

（14）要重視命名空間的使用。

關于Python編程規(guī)范的部分說明

Python編程規(guī)范有九個維度。

（1）模塊的劃分

我們要對模塊有概念，這是整個系統(tǒng)的基礎。

①一個.py文件是一個模塊。

②模塊的劃分對軟件的長期維護非常重要。

③每個模塊都應該有特定的功能。

比如：配置文件的讀取，網(wǎng)頁文件的寫入，網(wǎng)頁文件的解析，一個內(nèi)存數(shù)據(jù)表，一個抓取的線程等等。

④多個本應獨立的模塊，寫到一個.py文件中是常見的錯誤。從Code Review角度看，首先就是要看模塊切分的對不對。

（ 2 ）數(shù)據(jù)的封裝

在Code Review時，要著重注意數(shù)據(jù)是否封裝這一問題。

（ 3 ）import

Import在使用過程中，禁止使用from xxx import yyy語法直接導入類或函數(shù)。禁止使用from xxx import *這樣的方法。這樣做的目標是：容易判斷代碼中使用外部變量或函數(shù)的來源。

如果使用禁止中的語法，會大大增加判斷來源的難度，以及代碼閱讀的難度。

在Code Review時，遇到這種情況，及時將代碼打回給編程人員進行修正。

（ 4 ）異常

對于異常的處理有以下幾點需要注意：

①異常的使用

使用異常前請需要詳細了解異常的行為。不要主動拋出異常，使用返回值。如果一定要拋異常，需要注釋進行說明。

②異常的獲取強制

除非重新拋出異常，否則禁止使用except:捕獲所有異常，不建議捕獲Exception或StandardError。

在實際編碼中建議try中的代碼盡可能少，避免catch住未預期的異常，掩藏掉真正的錯誤。底線是至少要打印異常的日志，而不是捕獲后直接pass通過。

在對異常進行處理時盡量針對特定操作的特定異常來捕獲。

常犯的錯誤是：一是對IO等操作不捕獲異常。二是捕獲異常區(qū)域很大。

③函數(shù)的返回值

如果函數(shù)會拋出異常，需要在函數(shù)的注釋中明確說明。

在Code Review時，需要注意上述問題，及時返回給編程人員進行修正。

（ 5 ）構(gòu)造函數(shù)

對于構(gòu)造函數(shù)有以下幾點需要注意：

①規(guī)范：

類構(gòu)造函數(shù)應該盡量簡單，不能包含可能失敗或過于復雜的操作。

②解讀：

在構(gòu)造函數(shù)中常出現(xiàn)的錯誤是：無法判斷、或捕獲異常。

（ 6 ）函數(shù)返回值

對于函數(shù)返回值有以下幾點需要注意：

①規(guī)范：

函數(shù)返回值必須小于等于3個。返回值超過3個時必須通過class/namedtuple/dict等具名形式進行包裝。

②解讀：

a. 多數(shù)情況下的錯誤，是因為很多人不會思考和設計函數(shù)的語義。

函數(shù)描述涉及的三要素為：功能描述、傳入?yún)?shù)描述和返回值描述。

每個函數(shù)都應該有足夠明確的語義?；诤瘮?shù)的語義，函數(shù)的返回值有三種類型：

第一種類型：在“邏輯判斷型”函數(shù)中，返回布爾類型的值——True或False，表示“真”或“假”。

第二種類型：在“操作型”函數(shù)中，作為一個動作，返回成功或失敗的結(jié)果——OK或ERROR。

第三種類型：在“獲取數(shù)據(jù)型”函數(shù)中，返回一個“數(shù)據(jù)”，或者返回“無數(shù)據(jù)/獲取數(shù)據(jù)失敗”。

b .另外，函數(shù)需要有返回值，對于正確或錯誤的情況，在返回值中要有體現(xiàn)。

c .還有一個問題是：Python的數(shù)據(jù)格式不需要定義，過于靈活。當程序規(guī)模變大、維護周期變長時，會導致后期極難維護。

應對措施是：多寫注釋，寫清楚返回值說明、參數(shù)說明。

在Code Review時，注釋未寫清楚的代碼，一定要打回給編程人員，進行修正、補注釋。

（ 7 ）代碼長度

關于代碼長度有以下幾點需要注意：

①每行不得超過120個字符。避免在終端上顯示出現(xiàn)折行。

②函數(shù)長度不得超過100行。函數(shù)過長會增加理解函數(shù)邏輯的難度。Python的函數(shù)應盡量控制在30~40行之間。

在Code Review時，代碼過長，建議全部打回給編程人員進行修正。

（ 8 ）空行、空格

關于空行、空格有以下幾點需要注意：

①空行

文件及定義之間隔兩個空行。比如類或全局函數(shù)。類方法之間隔一個空行。

②空格

逗號、分號、冒號前不加空格，后邊加一個空格。所有二元運算符前后各加一個空格。

在Code Review時，需要著重注意空行和空格。空行和空格不是可有可無的?？招泻涂崭竦拇嬖?#xff0c;是為了增加可讀性。不好讀的代碼，一律打回給編程人員進行修正。

（ 9 ）注釋

關于注釋有以下幾點需要注意：

Python中的注釋有一個特殊之處是docstring，docstring要和“＃”注意區(qū)分開。

相關規(guī)范有：

①使用docstring描述module、 function 、class和method接口時，docstring必須用三個雙引號括起來。

②對外接口部分必須用docstring描述。內(nèi)部接口視情況自行決定是否寫docstring。

③接口的docstring描述至少包括功能簡介、參數(shù)、返回值。如果可能拋出異常，必須使用注釋進行說明。

④每個文件都必須有文件聲明，文件聲明必須包括以下信息：版權(quán)聲明、功能和用途簡介、修改人及聯(lián)系方式。

在Code Review時，不符合上述規(guī)范的，及時打回給編程人員進行修正。

如何成為一個好的reviewer

代碼審核的質(zhì)量，和審核者的代碼能力直接相關。代碼審核的質(zhì)量差，反映的是審核者的代碼水平。如果作為一個代碼審核員不會寫代碼，就要承認真相，并且要不斷提高自己的代碼能力。

在這里推薦一些學習資料幫助大家進行學習。

①關于代碼的書籍：《編寫可讀代碼的藝術》，《代碼整潔之道》。

②綜合的書籍：《代碼大全》，《201 principles of software development》。

③其他：《代碼的藝術》課程，Python Good Coder考試指南。

公司針對Code Review的措施

1、建立高?？蛇\營的代碼審核機制，提升代碼質(zhì)量，降低代碼評審成本。

①基于平臺：icode+bugbye

②代碼檢查規(guī)則分級，分為ERROR、WARNING、ADVICE三類，對ERROR級別阻塞提交。

③通過統(tǒng)計數(shù)據(jù)驅(qū)動代碼檢測規(guī)則的優(yōu)化。

2、通過工程能力地圖考察項目的Code Review情況。

3、所有的Code Review行為，都基于icode平臺進行。良好的工具可以幫助更好的進行代碼審核

至此，

我們的工程能力筆記講解

就圓滿結(jié)束啦！
點擊進入獲得更多技術信息~~

總結(jié)

以上是生活随笔為你收集整理的如何做好Code Review的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。