review還是非常有必要的，類似於非常初期的白盒測試過程，能幫助發現程式碼中明顯的問題，包括邏輯問題，程式碼風格問題等。

當然執行review也是件比較困難的事情，因為大家潛意識都會認為review沒什麼意義，甚至review很多場合下都是管理制度上的要求下才去做，也就是非自願的

當你去接手別人的程式碼，當你管理負責程式碼交接的時候，當你線上出現很初級的錯誤帶來重大影響的時候，很多人才覺得review有點重要

第一，review能減輕一點點負罪感，沒做review在管理制度上肯定承擔更多的責任，你的錯，別人可能會透過更多方式推責於你，你做好了，別人就沒辦法說什麼。

第二，很多人寫程式碼太隨意了，太應付了，尤其當有些人開始有離職想法的時候，對待程式碼更加隨意，反正要走了，誰接誰的鍋。等到下一個接手程式碼的時候，就開始噴寫程式碼的人辣雞什麼的，沒註釋啊，各種隱藏的彩蛋啊，這個時候只能慢慢改了

第三，對於初學者或者初入程式設計的人可能更能接受review，因為他們一般會比較小心翼翼，生怕出錯，所以他們會希望review能幫他們發現一些問題，然後改進，對於他們來說就有進步，下次就不會犯錯。

我們現在的專案是會做Code Review的，也就是程式碼稽核；但是說實話，我們公司雖然對Code Review要求很嚴格，但是形式大於實用；下面我就談談我對Code Review的一些看法。

為什麼要做Code Review

提高程式碼質量：程式碼稽核確實在一定程度上可以提高程式碼的質量；每個程式設計師或多或少都有一些不好的程式設計習慣，自認為理所應當的程式碼可能是有問題的；在程式碼稽核的過程中，別的開發人員可以幫其發現和糾正；

“威懾性”的作用：“我的程式碼要是被查到太多的問題，那多沒面子”，很多程式設計師會這樣想；

熟悉專案所有的程式碼：在做Code Review的時候，也是熟悉專案其他模組的過程；讓每個開發人員都熟悉整個專案程式碼，可以減少某個程式設計師在休假、離職的時候帶來的風險；

打造技術氛圍：追求更完美的程式碼，Code Review的過程，本身也是一種技術交流；

對程式碼的可讀性有比較高的要求：Code Review是檢查程式碼可讀性的非常好的手段，而良好的程式碼可讀性，讓後期的改動和維護都非常容易，並且讓專案組人員有流動的時候，新人會更快地熟悉程式碼，工作更容易交接。

當然不少人會反對Code Review，因為很多時候專案開發時間很緊，加班才能勉強完成程式碼開發，不可能給Code Review留出時間；

有些公司雖然有嚴格的Code Review流程和要求，比如我們使用Fisheye工具，專案的每次提交的、每一行程式碼提交都必須做程式碼稽核，並且記錄到KPI考核裡，但是大多數時候都是流於形式。

如何做好Code Review

我說一說我們專案的一些方法，效果不一定是最好的，但是比【形式主義】要強很多。

不一定要每一行程式碼都Review到，我們是採用抽查的方式；（我始終覺得“威懾性”很重要）；

專案組的新人，Code Review儘量全部覆蓋，不一定是他水平不高，主要是看他的程式碼是否符合專案制定的規範；

我們更多的時候是採用集體Code Review，也就是在一個敏捷迭代結束的時候，不僅要做驗收，還要花半小時到一小時，抽查一些程式碼做Code Review，也就是把程式碼投影出來，大家一起看這些程式碼的邏輯和語法；

Code Review的水平也是需要培養的，先讓專案的技術負責人或程式碼水平高的同事先做Code Review，然後讓其他開發人員去學習他們Code Review的方法（從哪些角度Review、哪些是好程式碼、哪些是差程式碼）。

國內絕大部分公司，特別是小公司，即使有Code Revidw，應該也都是走走形式而已。頂對對剛招進來的年輕程式設計師會做下稍微仔細點的Review，否則一般如果程式能夠正常執行就不會花什麼時間去Review。

我之前在一家外企，那邊有非常嚴格的Code Review，而且Review我們的程式碼都是一些國外的同事，有時候我們寫的程式碼會被批的體無完膚，好處是我們寫的程式碼質量都到了很多的提升。

說實在，Code Review有時候是非常好的，不僅僅可能減少專案出現的問題，也能提高程式碼的質量，而且對自己和對方都能有一定的技術提升幫助。

但現在問題來了，我已經成為專案Leader，誰來Review我的程式碼？

在我從事開發工作五年的時間裡，換過幾家公司，每家公司都會要求開發過程中進行程式碼review，而且多數情況下的程式碼review都能發現很多問題，因此我覺得程式碼review是很有必要的。

為什麼要進行程式碼review？提前發現問題，舉幾個例子:程式碼搬運是我們在開發過程中為了提高效率經常會做的，但是很多開發人員，程式碼搬運後，對一些冗餘程式碼置之不理，導致程式碼可讀性差，無形中增加了二次開發的難度；很多開發人員只是機械的完成需求，很少進一步思考，導致功能只是表面符合需求，實際程式碼邏輯存在漏洞。提高責任心，程式碼review能夠讓開發在潛意識中為了避免領導的責備而提高責任心和程式碼質量，從源頭根本性的解決問題。提高團隊凝聚力，組織程式碼評審會議，能夠讓團隊成員瞭解自身和其他人的優點和缺點，互相學習、共同進步、提高凝聚力。如何做好程式碼review?規律性，最好每週定一個固定的時間，可以一週一次或者一週倆次。與績效掛鉤，獎懲制度是最好的約束力，可以對於程式碼質量細化出扣分點，根據每個人的最終得分情況關聯每月績效。會議總結，每次程式碼review發現的問題形成會議紀要，針對普遍性強的問題召開培訓，發揮成果的作用最大化。