什麼不是codeReview
- Code reviews 不應該承擔發現代碼錯誤的職責。
Code Review主要是審覈代碼的質量，如可讀性，可維護性，以及程序的邏輯和對需求和設計的實現。代碼中的bug和錯誤應該由單元測試，功能測試，性能測試，迴歸測試來保證的（其中主要是單元測試，因爲那是最接近Bug，也是Bug沒有擴散的地方） - Code reviews 不應該成爲保證代碼風格和編碼標準的手段。
編碼風格和代碼規範都屬於死的東西，每個程序員在把自己的代碼提交團隊Review的時候，代碼就應該是符合規範的，這是默認值，屬於每個人自己的事情，不應該交由團隊來完成，否則只會浪費大家本來就不夠的時間。個人認爲“meeting”是奢侈的，因爲那需要大家在同一時刻都擠出時間，所以應該用在最需要的地方。代碼規範比起程序的邏輯和對需求設計的實現來說，太不值得讓大家都來了。
爲什麼要codeReview
- Code reviews 中，可以通過大家的建議增進代碼的質量。
- Code reviews 是一個傳遞知識的手段，可以讓其它並不熟悉代碼的人知道作者的意圖和想法，從而可以在以後輕鬆維護代碼。
- Code reviews 也鼓勵程序員們相互學習對方的長處和優點。
- Code reviews 也可以被用來確認自己的設計和實現是一個清楚和簡單的。
如何進行高效的codeReview
codeReview應該以工程化的思想來做，在正確的方法思想的指導下，通過各種輔助工具來保證整個codeReview過程的質量，並對其過程進行不斷優化迭代，更新我們的方法論。以期達到我們review的目標。
工具
- gitlib
- maven插件（阿里規約掃描插件）
- Jenkins自動化構建
- IDE重構、代碼檢查等
過程控制
1、項目組的codeReview過程控制
2、codeReview組委會的對於codeReview活動開展的過程控制
3、線上codeReview的過程控制
在公司開展codeReview工作看到的問題和想法
1、codeReview的推行，爲怎麼這麼難？（發現的問題,由研發團隊和需求團隊的矛盾導致，沒有時間進行codeReview（換句話說，發版任務需求、工期安排不妥帶來的問題，並不是codeReview本身的問題，這裏不再具體展開））
缺少科學體系化的codeReview方法論的指導：導致，無法迅速站在巨人的肩膀上進行快速學習和成長。
review的方式（強制&非強制、線上交流&線下會議、小片段&大模塊、事前&事後、高頻率&低頻率），如何取捨
時機如何選取？
流程/過程，如何控制？如何持續改進？ 以上的一系列問題，並沒有形成一個有效的理論支撐指導體系。
配套的codeReview制度和文化不完善，導致“結果更重要”，也就是說，做出來更重要，做漂亮不重要。因爲我的KPI和年終獎based on how many works I’ve done！而不是How perfect they are !
第一：如何更有效地激勵？（物質和精神獎勵，雙管齊下）
第二：如何用數據和事實，量化codeReview的考覈指標？
尚未形成統一的代碼規範，導致兩類問題：
第一：意見不一，影響review的效率。
第二：團隊根本不重視基本的代碼規範，從而導致沒有規範、風格不統一，根本無法愉快地進行codeReview。
缺乏review的check-list。
導致大部分的團隊review過程產生困惑和迷茫，不知道要review一些什麼內容，分不清階段性的重點。畢竟，老司機是少數人，咱們很多負責review的人，其實
也沒有什麼review的管理經驗。
缺乏強有力的工具和技術保證。
一、沒有高效的單元測試和接口自動化測試的保證，重構風險和成本巨大！
二、軟件開發、過程管理的工具利用不充分，大量的手工操作，導致review過程效率低下，review結果的產出差強人意。
人員能力不足，水平層次不一（代碼風格、基礎知識等欠缺。）
2、想在各個團隊高效地進行codeReview，我們還需要做些什麼？（參考解決方案）
從角色分工的角度：
codeReview組委會
前提：專人專項負責，加入個人考覈和績效考覈、貢獻度
指導手冊，提供codeReview方法論。
深度培訓和跟進，讓各個團隊落地方法論。
持續總結和優化，不斷改進方法論和實踐過程。
工具使用手冊和文檔的推廣：在保證產品按時發版的前提下，逐步提高review的量和質。
maven插件（阿里規約檢查插件）配合Jenkins的巧妙使用，強制、增量、逐步改善代碼的規範性問題。（適用於老代碼、老項目重構場景）
IDE：代碼重構技巧、規範檢查插件的使用，提高效率。
產品或者項目的直接負責人
進一步配合codeReview組委會，完善codeReview制度和文化。解決兩個問題：
第一：如何更有效地激勵？
首先，考慮直接和KPI、績效、工資掛鉤
其次，從個人價值、公司價值等精神角度，充分調動團隊中各類人羣的積極性？
根據不同的人羣，需求不一樣，區別對待。
利用好玩事兒的精神，將金豆、榮耀、獎章等和codeReview充分結合起來
接入jira、gitlib和codeReview主題相關的數據。並玩事兒結合起來，直接分配或者發放榮耀、金豆。
評選codeReview最佳團隊、個人（質量之星），當然如何評選以及如何獎勵，也是需要精心設計一番的。否則，容易適得其反！
第二：如何用數據和事實，量化codeReview的考覈指標？
通過jira，進行數據的分類統計。
通過gitlib進行數據的統計、分析和抽查。（線上review的頻度、質量）
項目經理
完善補充新人上手指導文檔，新人上崗前培訓和考覈（側重代碼規範、工具使用、環境操作規範等，納入經理考覈項）
促進團隊傳幫帶氛圍、定期技術主題分享。（納入經理考覈項）
主動發現和幫助需要進步的團隊成員。（納入經理考覈項）
組織團隊codeReview，並整理codeReview的相關數據、成果。（以備考覈、晉升）
督促技術專家和骨幹，完成各項工作。（納入經理考覈項）
檢查新人各項工作的執行情況。（納入每月、或者每週工作彙報中）
技術專家和骨幹
第一步：要解決單元測試缺乏，和接口自動化測試管理平臺缺乏的問題。
其次是：提供和完善check-list
最後：根據各自團隊情況，定期進行主題技術分享
新人和普通員工
按文檔或者規範、示例進行學習
執行規範
反講（自己講述給師傅們聽，並通過帶徒弟、新人進一步鞏固）
通過學一下、組織考試等。多積累。
總結
codeReview需要根據公司實際情況，在不同情況下不同階段可以不斷優化，不斷適應公司當下的需求才是最好的方案，任重道遠~