背景
今時今日，軟體工程的開發工作早已不是一個人的單打獨鬥，而是一個團隊的互相配合、共同前進。有位作家寫過一句很流行的話，叫“一個人要像一支隊伍”,而作為一個組織進行高效率的腦力生産勞動時，更需要追求的反而是“一支隊伍要像一個人”，這個人走路不會同手同腳，四肢要協調，前進方向隻有一個。
那怎麼實作這個目标呢？Code Review，即代碼評審，是必不可少的一個環節。
什麼是 Code Review（代碼評審）？
當一個程式員寫完了一段代碼後，由另外的程式員花時間來浏覽閱讀這些代碼，并進行審閱。
Code Review 是以輪轉的方式進行的，是以參與代碼審閱的人有兩種，分别是作者（author）以及評審者（reviewer）。當作者将寫好的代碼送出給評審者後，評審者對這次變動作出回報，作者根據回報修改代碼，并重新送出，經過一次或多次往返後，評審者同意（approve）這次代碼變動，允許代碼進入倉庫儲存，Code Review 就完成了。
制圖來源
此時評審者要考慮的問題包括：
- 總體邏輯上的實效效果
- 檢查是否滿足了所有需求
- 之前的自動化測試需要額外做修改才能跑通嗎
- 與其他子產品之間有沒有程式檢查不出來的沖突
由此可見，Code Review 基本上就相當于老師在給學生一字一句地批改作業，學生訂正後又交給老師再次檢查，如此往複。是以，為了節約精力，以便代碼審閱工作可持續性開展，評審者可以交給程式去處理的問題包括：
- 發現代碼中的 bug 與錯誤
- 代碼風格和編碼标準的統一
Code Review 的好處
熱力學三大基本定律中有一條叫“熵增原理”，即：一個孤立系統總朝着混亂無序的方向發展。軟體工程也是如此，如果沒有人把控輸入的代碼，隻管一個勁地堆砌，久而久之，這坨代碼也就失去秩序，成一團亂麻了，人見人嫌。是以在工程的一開始就引入代碼審閱，可以非常有效地提高代碼品質。
更重要的是，Code Review 是一個雙向的過程，雙方借助針對具體代碼的交流，得以了解對方的想法，進行互相探讨，這是幫助團隊中的成員成長，賦予團隊自我管理、良性發展的能力。歸根結底，人才是首要的生産力。
高效進行 Code Review 的方法
版本對比 / 檔案改動
在“上古”時代，代碼作者在開始 Code Review 前，還需要手動做一份變更清單（changelist），來告訴評審者這一次送出做了什麼改動。得益于 Git 的誕生，今天的我們可以借助基于 Git 版本控制系統的平台，來更輕松無痛地開展代碼審閱，比如「CODING 企業版」，作為企業級軟體研發管理系統，其提供的 Code Review 功能簡單好用，能大大提高代碼審閱效率：
借助 Git 自動實作精細的檔案改動，紅色代表删減，綠色代表新增，支援行級評論，再也不用在不同工位間來回走動，直接在具體代碼下進行交流。
資源關聯
代碼不是孤立的一串文本字元串，而是實作目标的其中一項資源，那麼必然需要與其他資源互相組合才能掌握全局。落實到代碼審閱中也是如此，放到具體的上下文環境裡方能見微知著：
「#」關聯任務、檔案等資源，「@」通知相關同僚，實作垂直關聯場景下的精細調控。
多人協同審閱
不同的人有不同的思考方式與見解，對同一段代碼能從不同的角度出發考慮。盡可能的讓不同的人 reivew 你的代碼，不僅會有更多的人日後有能力維護你的代碼，也是一個增加團隊凝聚力的好方法。
學會享受 Code Review
不用擔心收到批評面子過不去，也不用一枚追求“同意+1”，代碼審閱是一個團隊生機勃勃的象征，這裡面的每一個人都在互相鼓勵、互相交流以及互相進步，參與其中，與團隊共同成長吧。