Code Review代碼審查的思路
1．關(guān)于Code Review
1.1 Code Review的目的
Code Review主要用來在軟件工程過程中改進代碼質(zhì)量，通過Code Review可以達到如下目的目的：
（1）在項目早期就能夠發(fā)現(xiàn)代碼中的BUG
（2）幫助初級開發(fā)人員學(xué)習(xí)高級開發(fā)人員的經(jīng)驗，達到知識共享
（3）避免開發(fā)人員犯一些很常見，很普通的錯誤
（4）保證項目組人員的良好溝通
（5）項目或產(chǎn)品的代碼更容易維護
1.2Code Review的前提
進入Code Review需要檢查的條件如下：
（1）Code Review人員是否理解了Code Review的概念和Code Review將做什么
如果做Code Review的人員不能理解Code Review對項目成敗和代碼質(zhì)量的重要程度，他們的做法可能就會是應(yīng)付了事。
（2）代碼是否已經(jīng)正確的build，build的目的使得代碼已經(jīng)不存在基本語法錯誤
我們總不希望高級開發(fā)人員或是主管將時間浪費在檢查連編譯都通不過的代碼上吧。
（3）代碼執(zhí)行時功能是否正確
Code Review人員也不負責(zé)檢查代碼的功能是否正確，也就是說，需要復(fù)查的代碼必須由開發(fā)人員或質(zhì)量人員負責(zé)該代碼的功能的正確性。
（4）Review人員是否理解了代碼
做復(fù)查的人員需要對該代碼有一個基本的了解，其功能是什么，是拿一方面的代碼，涉及到數(shù)據(jù)庫或是通訊，這樣才能采取針對性的檢查
（5）開發(fā)人員是否對代碼做了單元測試
這一點也是為了保證Code Review前一些語法和功能問題已經(jīng)得到解決，Code Review人員可以將精力集中在代碼的質(zhì)量上。
1.3 Code Review需要做什么
Code Review主要檢查代碼中是否存在以下方面問題：
代碼的一致性、編碼風(fēng)格、代碼的安全問題、代碼冗余、是否正確設(shè)計以滿足需求（性能、功能）等等
1.3.1 完整性檢查（Completeness）
代碼是否完全實現(xiàn)了設(shè)計文檔中提出的功能需求
代碼是否已按照設(shè)計文檔進行了集成和Debug
代碼是否已創(chuàng)建了需要的數(shù)據(jù)庫，包括正確的初始化數(shù)據(jù)
代碼中是否存在任何沒有定義或沒有引用到的變量、常數(shù)或數(shù)據(jù)類型
1.3.2 一致性檢查（Consistency）
代碼的邏輯是否符合設(shè)計文檔
代碼中使用的格式、符號、結(jié)構(gòu)等風(fēng)格是否保持一致
1.3.3 正確性檢查（Correctness）
代碼是否符合制定的標(biāo)準(zhǔn)
所有的變量都被正確定義和使用
所有的注釋都是準(zhǔn)確的
所有的程序調(diào)用都使用了正確的參數(shù)個數(shù)
1.3.4 可修改性檢查（Modifiability）
代碼涉及到的常量是否易于修改(如使用配置、定義為類常量、使用專門的常量類等)
代碼中是否包含了交叉說明或數(shù)據(jù)字典，以描述程序是如何對變量和常量進行訪問的
代碼是否只有一個出口和一個入口（嚴重的異常處理除外）
1.3.5 可預(yù)測性檢查（Predictability）
代碼所用的開發(fā)語言是否具有定義良好的語法和語義
是否代碼避免了依賴于開發(fā)語言缺省提供的功能
代碼是否無意中陷入了死循環(huán)
代碼是否是否避免了無窮遞歸
1.3.6 健壯性檢查（Robustness）
代碼是否采取措施避免運行時錯誤（如數(shù)組邊界溢出、被零除、值越界、堆棧溢出等）
1.3.7 結(jié)構(gòu)性檢查（Structuredness）
程序的每個功能是否都作為一個可辯識的代碼塊存在
循環(huán)是否只有一個入口
1.3.8 可追溯性檢查（Traceability）
代碼是否對每個程序進行了唯一標(biāo)識
是否有一個交叉引用的框架可以用來在代碼和開發(fā)文檔之間相互對應(yīng)
代碼是否包括一個修訂歷史記錄，記錄中對代碼的修改和原因都有記錄
是否所有的安全功能都有標(biāo)識
1.3.9 可理解性檢查（Understandability）
注釋是否足夠清晰的描述每個子程序
是否使用到不明確或不必要的復(fù)雜代碼，它們是否被清楚的注釋
使用一些統(tǒng)一的格式化技巧（如縮進、空白等）用來增強代碼的清晰度
是否在定義命名規(guī)則時采用了便于記憶，反映類型等方法
每個變量都定義了合法的取值范圍
代碼中的算法是否符合開發(fā)文檔中描述的數(shù)學(xué)模型
1.3.10可驗證性檢查(Verifiability)
代碼中的實現(xiàn)技術(shù)是否便于測試
1.4 Code Review的步驟
這些是我在平時工作中的經(jīng)驗總結(jié)，目前也是按照這個步驟在做。
(1)代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UC依次講解自己負責(zé)的代碼和相關(guān)邏輯，從Web層->DAO層；
(2)代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發(fā)現(xiàn)隱藏的bug；對這些bug記錄在案。
(3)代碼講解完畢后，代碼審核者給自己安排幾個小時再對代碼審核一遍。
代碼需要一行一行靜下心看。同時代碼又要全面的看，以確保代碼整體上設(shè)計優(yōu)良。
(4)代碼審核者根據(jù)審核的結(jié)果編寫“代碼審核報告”，“審核報告”中記錄發(fā)現(xiàn)的問題及修改建議，然后把“審核報告”發(fā)送給相關(guān)人員。
(5)代碼編寫者根據(jù)“代碼審核報告”給出的修改意見，修改好代碼，有不清楚的地方可積極向代碼審核者提出。
(6)代碼編寫者 bug fix完畢之后給出反饋。
(7)代碼審核者把Code Review中發(fā)現(xiàn)的有價值的問題更新到"代碼審核規(guī)范"的文檔中，對于特別值得提醒的問題可群發(fā)email給所有技術(shù)人員。
提示
Code Review必備的文檔：
“代碼審核規(guī)范”文檔：記錄代碼應(yīng)該遵循的標(biāo)準(zhǔn)。
代碼審核者根據(jù)這些標(biāo)準(zhǔn)來Code Review代碼，同時在Code Review過程中不斷完善該文檔。
2．Code Reivew的執(zhí)行
一個標(biāo)準(zhǔn)的Code Reivew活動應(yīng)該分為三個階段：
2.1．事前準(zhǔn)備階段
在一次CR前，對以下內(nèi)容進行充分準(zhǔn)備。
2.1.1．CR的對象
在準(zhǔn)備CR代碼對象時，我們要注意代碼的數(shù)量，如果代碼量比較大，要對代碼進行必要的分解，確定其中的關(guān)鍵代碼，對關(guān)鍵代碼進行CR，可以達到舉一反三的目的。
2.1.2．CR的內(nèi)容
我們對代碼的審查內(nèi)容很多，如代碼的編寫是否規(guī)范（注釋的書寫格式、命名規(guī)范等）、技術(shù)處理規(guī)范（異常處理、日志處理、代碼組織結(jié)構(gòu)等）、業(yè)務(wù)實現(xiàn)等。我們不能希望通過一次CR活動，完成所有這些內(nèi)容的審查，因此我們必須設(shè)定本次CR活動內(nèi)容界限，確定審查重點；
2.1.3．評審規(guī)范和標(biāo)準(zhǔn)
在CR前設(shè)計確定評審規(guī)范和標(biāo)準(zhǔn)是必要，通過規(guī)范和標(biāo)準(zhǔn)我們在審查過程中可以有據(jù)可依，有理可循，而且還可以做到標(biāo)準(zhǔn)統(tǒng)一。
2.1.4．選擇CR活動的參與者
在CR開始前，必須把本次CR活動的對象、審查內(nèi)容以及審查的規(guī)范和標(biāo)準(zhǔn)通報給所有的參與者。
2.1.5．選擇CR活動的實施方式。
CR活動有很多形式可供我們選擇，我們可以根據(jù)實際情況選擇桌面式CR、演示講解式CR、一對一的座位CR等等。
2.2．實施階段
充分的事前準(zhǔn)備，只是做好CR活動的前提，在CR實施過程中，我們要做好以下工作。
2.2.1．準(zhǔn)確記錄
對于CR過程發(fā)現(xiàn)的問題，我們必須清晰準(zhǔn)確的記錄，可以使用問題點記錄單，明確記錄的項目和內(nèi)容。
2.2.2．講解與提問
CR過程中，要采用代碼作者講解和審查者提問方式。審查者不能只在發(fā)現(xiàn)問題時提問，同時也要根據(jù)本次審查的內(nèi)容要求代碼作者對某個特定問題的講解。
2.2.3．逐項審查
對事前確定的審查內(nèi)容，要逐項審查，不能因為時間不足等因素一掃而過。
2.2.4．注意氣氛
實施審查時，要營造一個討論問題、解決問題的氛圍，不能把審查會搞成批判會，這樣會影響相關(guān)人員的積極性。
2.3. 事后跟蹤跟蹤。
2.3.1. 確認發(fā)現(xiàn)的問題
CR結(jié)束后，對發(fā)現(xiàn)的問題，首先需要確定以下內(nèi)容。
1．問題點的難易程度以及影響的范圍；
2．解決問題的責(zé)任者和問題點修正結(jié)果的確認者；
3．解決問題點的時限。
2.32. 修正問題責(zé)任者
對于修正問題責(zé)任者，在問題點的修正過程中，要三方面內(nèi)容的記錄。
1．問題點的原因；
2．解決問題點的對策；
3．修正的內(nèi)容。
2.3.3. 修正結(jié)果確認者
做為修正結(jié)果的確認者，必須按照事前約定的時限及時的對修正結(jié)果進行全面的確認
3．注意事項
3.1. 經(jīng)常進行Code Review
（1）要Review的代碼越多，那么要重構(gòu)，重寫的代碼就會越多。而越不被程序作者接受的建議也會越多，唾沫口水戰(zhàn)也會越多。
（2）程序員代碼寫得時候越長，程序員就會在代碼中加入越來越多的個人的東西。
（3）越接近軟件發(fā)布的最終期限，代碼也就不能改得太多。
3.2. Code Review不要太正式，而且要短
忘了那個代碼評審的Checklist吧，走到你的同事座位跟前，像請師父一樣請他坐到你的電腦面前，然后，花5分鐘給他講講你的代碼，給他另外一個5分鐘讓他給你的代碼提提意見，這比什么都好。而如果你用了一個Checklist，讓這個事情表現(xiàn)得很正式的話，下面兩件事中必有一件事會發(fā)生：
（1）只有在Checklist上存在的東西才會被Review。
（2）Code Reviews 變成了一種禮節(jié)性的東西，你的同事會裝做很關(guān)心你的代碼，但其實他心里想著盡快地離開你。
只有不正式的Code Review才會讓你和評審者放輕松，人只有放松了，才會表現(xiàn)得很真實，很真誠。記住Review只不過是一種形式，而只有在相互信任中通過相互的討論得到了有意義和有建設(shè)性的建議和意見，那才是最實在的。不然，作者和評審者的關(guān)系就會變成小偷和警察的關(guān)系。
3.3. 盡可能的讓不同的人Reivew你的代碼
如果可能的話，不要總是只找一個人來Review你的代碼，不同的人有不同的思考方式，有不同的見解，所以，不同的人可以全面的從各個方面評論你的代碼。
但不要太多了，人多嘴雜反而適得其反，基本上來說，不要超過3個人，這是因為，這是一個可以圍在一起討論的***人員尺寸。
下面是幾個優(yōu)點：
（1）從不同的方向評審代碼總是好的。
（2）會有更多的人幫你在日后維護你的代碼。
（3）這也是一個增加團隊凝聚力的方法。
3.4. 保持積極的正面的態(tài)度
程序員***的問題就是“自負”，尤其當(dāng)我們Reivew別人的代碼的時候，我已經(jīng)見過無數(shù)的場面，程序員在Code Review的時候，開始抨擊別人的代碼，質(zhì)疑別人的能力。太可笑了，我分析了一下，這類的程序員其實并沒有什么本事，因為他們指責(zé)對方的目的是想告訴大家自己有多么的牛，靠這種手段來表現(xiàn)自己的程序員，其實是就是傳說中所說的“半瓶水”。
所以，無論是代碼作者，還是評審者，都需要一種積極向上的正面的態(tài)度，作者需要能夠虛心接受別人的建議，因為別人的建議是為了讓你做得更好；評審者也需要以一種積極的正面的態(tài)度向作者提意見，因為那是和你在一個戰(zhàn)壕里的戰(zhàn)友。記住，你不是一段代碼，你是一個人！
3.5. 學(xué)會享受Code Reivew
這可能是最重要的一個提示了，如果你到了一個人人都喜歡Code Reivew的團阿，那么，你會進入到一個生機勃勃的地方，在那里，每個人都能寫出質(zhì)量非常好的代碼，在那里，你不需要經(jīng)理的管理，團隊會自適應(yīng)一切變化，他們相互學(xué)習(xí)，相互幫助，不僅僅是寫出好的代碼，而且團隊和其中的每個人都會自動進化，最關(guān)鍵的是，這個是一個團隊。
原文鏈接：http://www.cnblogs.com/IT-Bear/archive/2012/07/04/2576367.html
【編輯推薦】
