時光匆匆流逝~

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

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

然后搬好前排小板凳

學習啦！

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

為什么要做好Code Review

Code Review是提升代碼質量的最好方法

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

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

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

Code Review能夠在團隊內傳遞知識

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

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

另外，基于codebase可以使我們了解項目全局，培養系統的思考方式。

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

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

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

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

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

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

①代碼質量差。

②團隊內人員備份差。

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

為什要提高代碼質量？

①提高代碼質量可以提高代碼的可讀性。

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

③提高代碼質量可以減少bug出現的風險。

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

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

⑥提高代碼質量可以降低項目重構和升級的麻煩。

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

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

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

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

如何做好Code Review

在Code Review中可能發現的問題

→ 拼寫錯誤；

→ 未優化的代碼；

→ 不必要的復雜代碼；

→ 已經實現過的代碼，又重復實現；

→ 注釋不全；

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

在Code Review中要有一個好的態度 要做到以下幾點

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

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

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

①Code Review和寫代碼一樣，也有產出，即產出更高質量的代碼。

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

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

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

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

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

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

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

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

①代碼的正確和性能；

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

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

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

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

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

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

①5分鐘內不能看懂的代碼。

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

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

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

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

好的代碼，經常在一屏內就是一個完整的邏輯。

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

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

Code Review的注意事項

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

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

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

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

③檢查中發現的問題，要一追到底。

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

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

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

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

Code Review的步驟

Code Review的步驟為以下幾點：

Step1：先看系統全貌

不深究細節，瀏覽系統全貌，理清模塊劃分的邏輯、模塊間的關系、如何構成的整個系統等。

Step2：進入模塊級別

同樣不深究細節，瀏覽模塊內的全貌，判斷模塊切分是否合理，理清模塊內的邏輯，明確關鍵數據、關鍵的類和函數等。

Step3：理清類、函數內部的邏輯。

Step4：進入細節。

比如Layout、命名等。

人為因素

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

①QA人員

好的QA人員不僅僅會發現系統中的bug，還會質疑或提出產品需求，挑戰或優化系統架構和實現方式。

②Code Reviewer

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

例子：Python代碼的 Code Review

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

Python的編碼規范

（1）代碼要寫的漂亮。

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

（3）代碼要簡潔，一個函數可以實現的功能就不要寫兩個函數。

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

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

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

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

（8）代碼要有普適性。盡量規避代碼特殊性，用最簡潔最通用的代碼來實現。

（9）代碼要實用。

（10）要重視所有發現的錯誤。

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

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

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

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

關于Python編程規范的部分說明

Python編程規范有九個維度。

（1）模塊的劃分

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

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

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

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

比如：配置文件的讀取，網頁文件的寫入，網頁文件的解析，一個內存數據表，一個抓取的線程等等。

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

（ 2 ）數據的封裝

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

（ 3 ）import

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

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

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

（ 4 ）異常

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

①異常的使用

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

②異常的獲取強制

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

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

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

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

③函數的返回值

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

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

（ 5 ）構造函數

對于構造函數有以下幾點需要注意：

①規范：

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

②解讀：

在構造函數中常出現的錯誤是：無法判斷、或捕獲異常。

（ 6 ）函數返回值

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

①規范：

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

②解讀：

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

函數描述涉及的三要素為：功能描述、傳入參數描述和返回值描述。

每個函數都應該有足夠明確的語義。基于函數的語義，函數的返回值有三種類型：

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

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

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

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

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

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

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

（ 7 ）代碼長度

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

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

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

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

（ 8 ）空行、空格

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

①空行

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

②空格

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

在Code Review時，需要著重注意空行和空格。空行和空格不是可有可無的。空行和空格的存在，是為了增加可讀性。不好讀的代碼，一律打回給編程人員進行修正。

（ 9 ）注釋

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

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

相關規范有：

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

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

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

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

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

如何成為一個好的reviewer

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

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

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

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

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

公司針對Code Review的措施

1、建立高校可運營的代碼審核機制，提升代碼質量，降低代碼評審成本。

①基于平臺：icode+bugbye

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

③通過統計數據驅動代碼檢測規則的優化。

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

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

至此，

我們的工程能力筆記講解

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。