1.關於Code Review
1.1 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的團阿，那么，你會進入到一個生機勃勃的地方，在那里，每個人都能寫出質量非常好的代碼，在那里，你不需要經理的管理，團隊會自適應一切變化，他們相互學習，相互幫助，不僅僅是寫出好的代碼，而且團隊和其中的每個人都會自動進化，最關鍵的是，這個是一個團隊。
一、代碼規范的要點
代碼規范主要分為風格規范與設計規范兩大類：
1、代碼風格規范
主要是文字上的規定，看似表面文章，實際上非常重要。
具體有如下幾個方面：
（1）縮進
（2）行寬
（3）斷行/空白行
（4）括號
（5）命名（字母、下划線、大小寫）
（6）注釋
A、單行注釋
B、多行注釋
C、變量/方法/類/包注釋
2、代碼設計規范
牽涉到程序設計、模塊之間的關系、設計模式等方方面面的通用原則。
主要有如下幾個方面：
（1）方法/函數的寫法
A、方法命名
B、方法參數（入參/返回值）
C、方法的職責
比如：避免out型參數、用枚舉替代boolean、同類型參數最好間隔開、超過4個參數最好抽象成一個類、參數和返回值最好不傳null、用衛述句減少if嵌套、方法連續調用要注意空指針、for循環優於while
（2）異常處理原則
比如：異常的抽象層次應該與方法所在的層次一致，業務層方法要對底層異常進行轉譯為業務異常
（3）分層/類設計原則
比如：在某一個層進行防御式校驗，某一層按約定不做參數校驗；比如調用到的外部接口封裝為facade防腐層；
（4）單測原則
比如：快速/及時、獨立、可重復、覆蓋主要代碼路徑、無副作用
二、CodeReview注意事項
主要根據團隊設定的代碼規范，來review團隊成員的代碼，大致有以下幾個方面：
1、代碼有沒有不符合代碼規范的
比如：命名、注釋
2、代碼有沒有（業務/算法）邏輯錯誤
比如：功能與需求有偏差；參數傳遞順序出錯；方法的邊界條件有沒有考慮等
3、代碼有沒有回歸錯誤
比如：之前的功能回歸測試不通過
4、代碼有沒有潛在性能問題
比如：考慮大數據量、大並發量下的性能下sql是否有問題？是否會有內存泄露？死鎖等
5、代碼有沒有其他待改進的地方
比如：可擴展性/過度設計
