時光匆匆流逝~
今天是工程能力學習的最後一篇筆記了！
首先給堅持努力的自己呱唧呱唧！
然後搬好前排小板凳
學習啦！
本節課為《如何做好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平台進行。良好的工具可以幫助更好的進行代碼審核
至此，
我們的工程能力筆記講解
就圓滿結束啦！
點擊進入獲得更多技術信息~~
