1．關於Code Review

1.1 Code Review的目的

Code Review是一種用來確認方案設計和程式碼實現的質量保證機制，通過這個機制我們可以對程式碼、測試過程和註釋進行檢查。

Code Review主要用來在軟體工程過程中改進程式碼質量，通過Code Review可以達到如下目的目的：

（1）在專案早期就能夠發現程式碼中的BUG

（2）幫助初級開發人員學習高階開發人員的經驗，達到知識共享

（3）避免開發人員犯一些很常見，很普通的錯誤

（4）保證專案組人員的良好溝通

（5）專案或產品的程式碼更容易維護

1.2Code Review的前提

進入Code Review需要檢查的條件如下：

（1）Code Review人員是否理解了Code Review的概念和Code Review將做什麼

如果做Code Review的人員不能理解Code Review對專案成敗和程式碼質量的重要程度，他們的做法可能就會是應付了事。

（2）程式碼是否已經正確的build，build的目的使得程式碼已經不存在基本語法錯誤

我們總不希望高階開發人員或是主管將時間浪費在檢查連編譯都通不過的程式碼上吧。

（3）程式碼執行時功能是否正確

Code Review人員也不負責檢查程式碼的功能是否正確，也就是說，需要複查的程式碼必須由開發人員或質量人員負責該程式碼的功能的正確性。

（4）Review人員是否理解了程式碼

做複查的人員需要對該程式碼有一個基本的瞭解，其功能是什麼，是拿一方面的程式碼，涉及到資料庫或是通訊，這樣才能採取針對性的檢查

（5）開發人員是否對程式碼做了單元測試

這一點也是為了保證Code Review前一些語法和功能問題已經得到解決，Code Review人員可以將精力集中在程式碼的質量上。

1.3 Code Review需要做什麼

Code Review主要檢查程式碼中是否存在以下方面問題：

程式碼的一致性、編碼風格、程式碼的安全問題、程式碼冗餘、是否正確設計以滿足需求（效能、功能）等等

1.3.1 完整性檢查（Completeness）

程式碼是否完全實現了設計文件中提出的功能需求

程式碼是否已按照設計文件進行了整合和Debug

程式碼是否已建立了需要的資料庫，包括正確的初始化資料

程式碼中是否存在任何沒有定義或沒有引用到的變數、常數或資料型別

1.3.2 一致性檢查（Consistency）

程式碼的邏輯是否符合設計文件

程式碼中使用的格式、符號、結構等風格是否保持一致

1.3.3 正確性檢查（Correctness）

程式碼是否符合制定的標準

所有的變數都被正確定義和使用

所有的註釋都是準確的

所有的程式呼叫都使用了正確的引數個數

1.3.4 可修改性檢查（Modifiability）

程式碼涉及到的常量是否易於修改(如使用配置、定義為類常量、使用專門的常量類等)

程式碼中是否包含了交叉說明或資料字典，以描述程式是如何對變數和常量進行訪問的

程式碼是否只有一個出口和一個入口（嚴重的異常處理除外）

1.3.5 可預測性檢查（Predictability）

程式碼所用的開發語言是否具有定義良好的語法和語義

是否程式碼避免了依賴於開發語言預設提供的功能

程式碼是否無意中陷入了死迴圈

程式碼是否是否避免了無窮遞迴

1.3.6 健壯性檢查（Robustness）

程式碼是否採取措施避免執行時錯誤（如陣列邊界溢位、被零除、值越界、堆疊溢位等）

1.3.7 結構性檢查（Structuredness）

程式的每個功能是否都作為一個可辯識的程式碼塊存在

迴圈是否只有一個入口

1.3.8 可追溯性檢查（Traceability）

程式碼是否對每個程式進行了唯一標識

是否有一個交叉引用的框架可以用來在程式碼和開發文件之間相互對應

程式碼是否包括一個修訂歷史記錄，記錄中對程式碼的修改和原因都有記錄

是否所有的安全功能都有標識

1.3.9 可理解性檢查（Understandability）

註釋是否足夠清晰的描述每個子程式

是否使用到不明確或不必要的複雜程式碼，它們是否被清楚的註釋

使用一些統一的格式化技巧（如縮排、空白等）用來增強程式碼的清晰度

是否在定義命名規則時採用了便於記憶，反映型別等方法

每個變數都定義了合法的取值範圍

程式碼中的演算法是否符合開發文件中描述的數學模型

1.3.10可驗證性檢查(Verifiability)

程式碼中的實現技術是否便於測試

1.4  Code Review的步驟

這些是我在平時工作中的經驗總結，目前也是按照這個步驟在做。

(1)程式碼編寫者和程式碼稽核者坐在一起，由程式碼編寫者按照UC依次講解自己負責的程式碼和相關邏輯，從Web層->DAO層；

(2)程式碼稽核者在此過程中可以隨時提出自己的疑問，同時積極發現隱藏的bug；對這些bug記錄在案。

(3)程式碼講解完畢後，程式碼稽核者給自己安排幾個小時再對程式碼稽核一遍。

   程式碼需要一行一行靜下心看。同時程式碼又要全面的看，以確保程式碼整體上設計優良。

(4)程式碼稽核者根據稽核的結果編寫“程式碼稽核報告”，“稽核報告”中記錄發現的問題及修改建議，然後把“稽核報告”傳送給相關人員。

(5)程式碼編寫者根據“程式碼稽核報告”給出的修改意見，修改好程式碼，有不清楚的地方可積極向程式碼稽核者提出。

(6)程式碼編寫者 bug fix完畢之後給出反饋。

(7)程式碼稽核者把Code Review中發現的有價值的問題更新到"程式碼稽核規範"的文件中，對於特別值得提醒的問題可群發email給所有技術人員。

提示

Code Review必備的文件：

“程式碼稽核規範”文件：記錄程式碼應該遵循的標準。

程式碼稽核者根據這些標準來Code Review程式碼，同時在Code Review過程中不斷完善該文件。

2．Code Reivew的執行

一個標準的Code Reivew活動應該分為三個階段：

2.1．事前準備階段

在一次CR前，對以下內容進行充分準備。

2.1.1．CR的物件

在準備CR程式碼物件時，我們要注意程式碼的數量，如果程式碼量比較大，要對程式碼進行必要的分解，確定其中的關鍵程式碼，對關鍵程式碼進行CR，可以達到舉一反三的目的。

2.1.2．CR的內容

我們對程式碼的審查內容很多，如程式碼的編寫是否規範（註釋的書寫格式、命名規範等）、技術處理規範（異常處理、日誌處理、程式碼組織結構等）、業務實現等。我們不能希望通過一次CR活動，完成所有這些內容的審查，因此我們必須設定本次CR活動內容界限，確定審查重點；

2.1.3．評審規範和標準

在CR前設計確定評審規範和標準是必要，通過規範和標準我們在審查過程中可以有據可依，有理可循，而且還可以做到標準統一。

2.1.4．選擇CR活動的參與者

在CR開始前，必須把本次CR活動的物件、審查內容以及審查的規範和標準通報給所有的參與者。

2.1.5．選擇CR活動的實施方式。

CR活動有很多形式可供我們選擇，我們可以根據實際情況選擇桌面式CR、演示講解式CR、一對一的座位CR等等。

2.2．實施階段

充分的事前準備，只是做好CR活動的前提，在CR實施過程中，我們要做好以下工作。

2.2.1．準確記錄

對於CR過程發現的問題，我們必須清晰準確的記錄，可以使用問題點記錄單，明確記錄的專案和內容。

2.2.2．講解與提問

CR過程中，要採用程式碼作者講解和審查者提問方式。審查者不能只在發現問題時提問，同時也要根據本次審查的內容要求程式碼作者對某個特定問題的講解。

2.2.3．逐項審查

對事前確定的審查內容，要逐項審查，不能因為時間不足等因素一掃而過。

2.2.4．注意氣氛

實施審查時，要營造一個討論問題、解決問題的氛圍，不能把審查會搞成批判會，這樣會影響相關人員的積極性。

2.3. 事後跟蹤跟蹤。

2.3.1. 確認發現的問題

CR結束後，對發現的問題，首先需要確定以下內容。
1．問題點的難易程度以及影響的範圍；

2．解決問題的責任者和問題點修正結果的確認者；

3．解決問題點的時限。

2.32. 修正問題責任者

對於修正問題責任者，在問題點的修正過程中，要三方面內容的記錄。
1．問題點的原因；
2．解決問題點的對策；
3．修正的內容。

2.3.3. 修正結果確認者

做為修正結果的確認者，必須按照事前約定的時限及時的對修正結果進行全面的確認

3．注意事項

3.1. 經常進行Code Review

（1）要Review的程式碼越多，那麼要重構，重寫的程式碼就會越多。而越不被程式作者接受的建議也會越多，唾沫口水戰也會越多。

（2）程式設計師程式碼寫得時候越長，程式設計師就會在程式碼中加入越來越多的個人的東西。

（3）越接近軟體釋出的最終期限，程式碼也就不能改得太多。

3.2.  Code Review不要太正式，而且要短

忘了那個程式碼評審的Checklist吧，走到你的同事座位跟前，像請師父一樣請他坐到你的電腦面前，然後，花5分鐘給他講講你的程式碼，給他另外一個5分鐘讓他給你的程式碼提提意見，這比什麼都好。而如果你用了一個Checklist，讓這個事情表現得很正式的話，下面兩件事中必有一件事會發生：

（1）只有在Checklist上存在的東西才會被Review。

（2）Code Reviews 變成了一種禮節性的東西，你的同事會裝做很關心你的程式碼，但其實他心裡想著儘快地離開你。

只有不正式的Code Review才會讓你和評審者放輕鬆，人只有放鬆了，才會表現得很真實，很真誠。記住Review只不過是一種形式，而只有在相互信任中通過相互的討論得到了有意義和有建設性的建議和意見，那才是最實在的。不然，作者和評審者的關係就會變成小偷和警察的關係。

3.3. 儘可能的讓不同的人Reivew你的程式碼

如果可能的話，不要總是隻找一個人來Review你的程式碼，不同的人有不同的思考方式，有不同的見解，所以，不同的人可以全面的從各個方面評論你的程式碼。

但不要太多了，人多嘴雜反而適得其反，基本上來說，不要超過3個人，這是因為，這是一個可以圍在一起討論的最大人員尺寸。

下面是幾個優點：

（1）從不同的方向評審程式碼總是好的。

（2）會有更多的人幫你在日後維護你的程式碼。

（3）這也是一個增加團隊凝聚力的方法。

3.4. 保持積極的正面的態度

程式設計師最大的問題就是“自負”，尤其當我們Reivew別人的程式碼的時候，我已經見過無數的場面，程式設計師在Code Review的時候，開始抨擊別人的程式碼，質疑別人的能力。太可笑了，我分析了一下，這類的程式設計師其實並沒有什麼本事，因為他們指責對方的目的是想告訴大家自己有多麼的牛，靠這種手段來表現自己的程式設計師，其實是就是傳說中所說的“半瓶水”。

所以，無論是程式碼作者，還是評審者，都需要一種積極向上的正面的態度，作者需要能夠虛心接受別人的建議，因為別人的建議是為了讓你做得更好；評審者也需要以一種積極的正面的態度向作者提意見，因為那是和你在一個戰壕裡的戰友。記住，你不是一段程式碼，你是一個人！

3.5. 學會享受Code Reivew

這可能是最重要的一個提示了，如果你到了一個人人都喜歡Code Reivew的團阿，那麼，你會進入到一個生機勃勃的地方，在那裡，每個人都能寫出質量非常好的程式碼，在那裡，你不需要經理的管理，團隊會自適應一切變化，他們相互學習，相互幫助，不僅僅是寫出好的程式碼，而且團隊和其中的每個人都會自動進化，最關鍵的是，這個是一個團隊。

相關資料

5個開源的程式碼審查工具http://coolshell.cn/articles/1218

 

轉：https://www.cnblogs.com/IT-Bear/archive/2012/07/04/2576367.html