Code Review的重要性

轉自 http://coolshell.cn/articles/11432.html

（這篇文章緣由我的微網誌，我想多說一些，有些雜亂，想到哪寫到哪）

這兩天，在微網誌上表達了一下Code Review的重要性。因為翻看了阿裡内部的Review Board上的記錄，從上面發現Code Review做得好的是一些比較偏技術的團隊，而偏業務的技術團隊基本上沒有看到Code Review的記錄。當然，這并不能說沒有記錄他們就沒有做Code Review，于是，我就問了一下以前在業務團隊做過的同僚有沒有Code Review，他告訴我不但沒有Code Review，而且他認為Code Review沒用，因為：

1）工期壓得太緊，時間連coding都不夠，以上線為目的，

2）需求老變，代碼的生命周期太短。是以，寫好的代碼沒有任何意義，爛就爛吧，反正與績效無關。

我心裡非常不認同這樣的觀點，我覺得我是程式員，我是工程師，就像醫生一樣，不是把病人醫好就好了，還要對病人的長期健康負責。對于常見病，要很快地醫好病人很簡單，下猛藥，大量使用抗生素，好得飛快。但大家都知道，這明顯是“飲鸩止渴”、“竭澤而漁”的做法。醫生需要有責任心和醫德，我也覺得程式員工程師也要有相應的責任心和相應的修養。東西交給我我必需要負責，我覺得這種負責和修養不是”做出來“就了事了，而是要到“做漂亮”這個級别，這就是“山寨”和“工業”的差别。而隻以“做出來”為目的标準，我隻能以為，這樣的做法隻不過是“按部就班”的堆砌代碼罷了，和勞動密集型的“裝配生産線”和“砌磚頭”沒有什麼差别，在這種環境裡呆着還不如離開。

老實說，因為去年我在業務團隊的時候，我的團隊也沒有做Code Review，原因是多樣的。其中一個重要原因是，我剛來阿裡，是以，需要做的是在适應阿裡的文化，任何公司都有自己的風格和特點，任何公司的做法都有他的理由和成因，對于我這樣的一個初來者，首要的是要适應和觀察，不要對團隊做太多的改動，跟從、了解和信任是融入的關鍵。（注：在建北京團隊和不要專職的測試人員上我都受到了一些阻力），是以跟着團隊走沒有玩Code Review。幹了一年後，覺得我妥協了很多我以前所堅持的東西，覺得自己的标準在降低，想一想後背拔涼拔涼的，是以我決定堅持，而且還要堅持高标準。

對于Code Review很重要的這個觀點，在微網誌上抛出來後，被一些阿裡的工程師，架構師/專家，甚至資深架構師批評，我在和他們回複和讨論的過程中，居然發現有個“因為對方使用者的設定”我無法回複了（我被拉黑了，還有一些直接就是冷諷和罵人了，微網誌中我就直接删除了）。這些批評我的阿裡工程師/架構師的觀點總結一下如下：（順便說一下，阿裡内還是有很多團隊堅持做Code Review的）

1）到業務團隊體會一下，倒逼工期的項目有多少？訂好傳遞日期後再要求提前1個月的有多少？現在是做到已經不容易，更不談做得漂亮！。

2）Code Review是一種教條，意義不大，有測試，隻要不出錯，就可以了。

3）目标都是改進品質，有限的投入總希望能有最大的産出，不同沉湎改進品質的方式不一樣，業務應用開發忙的跟狗一樣，而且業務邏輯變化快，通用性差，codereviw的成本要比底層高。

4）現在的主要沖突是倒排出來的工期和不靠譜的程式員之間的沖突，我認為cr不是解決這個問題的銀彈。不從實際情況出發光打正義的嘴炮實在太過于自慰了 。

我們可以看到，上面觀點其實和Code Review沒有太多關系，其實是在抱怨另外的問題。這些觀點其實是技術團隊和業務團隊的沖突，但不知道為什麼強加給了我的“Code Review很重要”的這個觀點，然後這些觀點反過來沖擊“Code Reivew”，并說“Code Review無用”。這種讨論問題的方式在很常見，你說A，我說B，本來A、B是兩件事，但就是要混為一談，然後似是而非的用B來證明你的A觀點是錯的。（也許，這些工程師/架構師心存怨氣，需要一個發洩的通道）

我覺得，很多時候，人思考問題思考不清楚，很大一部分原因是因為把很多問題混為一談，連我自己有些時候都會這樣。引以為戒。

即然被混為一談，那我就來拆分一下，也是下面這三個問題：

• Code Review有沒有用的問題。
• Code Review做不起來的問題。
• 業務變化快，速度快的問題，技術疲于跟命。

Code Review

你Google一下Code Reivew這個關鍵詞，你就會發現Code Review的好處基本上是不存在争議的，有很多很多的文章和博文都在說Code Review的重要性，怎麼做會更好，而且很多公司在面試過程中會加入“Code Review”的問題。打開Wikipedia的詞條你會看到這樣的描述——

卡珀斯·瓊斯（Capers Jones）分析了超過12,000個軟體開發項目，其中使用正式代碼審查的項目，發現潛在缺陷率約在60-65%之間，若是非正式的代碼審查，發現潛在缺陷率不到50%。大部份的測試，發現的潛在缺陷率會在30%左右。

對于一些關鍵的軟體（例如安全關鍵系統的嵌入式軟體），一般的代碼審查速度約是一小時150行程式碼，一小時審查數百行程式碼的審查速度太快，可能無法找到程式中的問題。代碼審查一般可以找到及移除約65%的錯誤，最高可以到85%。

也有研究針對代碼審查找到的缺陷類型進行分析。代碼審查找到的缺陷中，有75%是和計算機安全隐患有關。對于産品生命周期很長的軟體公司而言，代碼審查是很有效的工具。

Code Review的好處我覺得不用多說了，主要是讓你的代碼可以更好的組織起來，有更易讀，有更高的維護性，同時可以達到知識共享，找到bug隻是其中的副産品。這個東西已經不新鮮了，你上網可以找到很多文章，我就不多說了。就像你寫程式要判斷錯誤一樣，Code Review也是最基本的常識性的東西。

我從2002年開始就浸泡在嚴格的Code Review中，我的個人成長和Code Review有很大的關系，如果我的成長過程中沒有經曆過Code Review這個事，我完全不敢想像。

我個人認為代碼有這幾種級别：1）可編譯，2）可運作，3）可測試，4）可讀，5）可維護，6）可重用。通過自動化測試的代碼隻能達到第3）級，而通過Code Review的代碼少會在第4）級甚至更高。關于Code Review，你可以參看本站的《Code Review中的幾個提示》

可見，Code Review直接關系到了你的工程能力！

Code Review 的問題

有下面幾個情況會讓你的Code Review沒有效果。

首當其沖的是——“人員能力不足”，我經曆過這樣的情況，Code Review的過程中，大家大眼瞪小眼，沒有什麼好的想法，不知道什麼是好的代碼，什麼是不好的代碼。導緻Code Review大多數都在代碼風格上。今天，我告訴你，代碼風格這種事，是每個程式員自查的事情，不應該浪費大家的時間。對此，我有兩個建議：1）你團隊的人招錯了，該換血了。2）讓你團隊的人花時候閱讀一下《代碼大全》這本書（當然，還要讀很多基礎知識的書）。

次當其沖的是——“結果更重要”，也就是說，做出來更重要，做漂亮不重要。因為我的KPI和年終獎based on how many works I’ve done！而不是How perfect they are ! 這讓我想到那些天天在用Spring MVC 做CRUD網頁的工程師，我承認，他們很熟練。大量的重複勞動。其實，仔細想一下好多東西是可以架構化，模闆化，或是自動生成的。是以，為了堆出這麼多網頁就停地去堆，做的東西是很多，但是沒有任何成長。急功近利，也許，你做得多，拿到了不錯的年終獎，但是你失去的也多，失去了成為一個卓越工程師的機會。你本來可以讓你的月薪在1-2年後翻1-2倍的，但一年後你隻拿到了為數不多的年終獎。

然後是——“人員的态度問題”，一方面就是懶，不想精益求精，隻要幹完活交差了事。對此，你更要大力開展Code Review了，讓這種人寫出來的代碼曝光在更多人面前，讓他為品質不好的代碼蒙羞。另一方面，有人會覺得那是别人的子產品，我不懂，也沒時間 去懂，不懂他的業務怎麼做Code Review? 我隻想說，如果你的團隊裡這樣的“各個自掃門前雪”的事越多，那麼這個團隊也就越沒主動性，沒有主動性也就越不可能是個好團隊，做的東西也不可能好。而對于個人來說，也就越不可能有成長。

接下來是——“需求變化的問題”，有人認識，需求變得快，代碼的生存周期比較短，不需要好的代碼，反正過兩天這些代碼就會被廢棄了。如果是一次性的東西，的确品質不需要太高，反正用了就扔。但是，我覺得多多少少要Review一下這個一次性的爛代碼不會影響那些長期在用的代碼吧，如果你的項目全部都是臨時代碼，那麼你團隊是不是也是一個臨時團隊？關于如果應對需求變化，你可以看看本站的《需求變化與IoC》《Unix的設計思想來應對多變的需求》的文章 ，從這些文章中，我相信你可以看到對于需求變化的代碼品質需要的更高。

最後是——“時間不夠問題”，如果是業務逼得緊，讓你疲于奔命，那麼這不是Code Review好不好問題，這是需求管理和項目管理的問題以及别的非技術的問題。下面我會說。

不管怎麼樣，上述Code Review的問題不應該成為“Code Review無意義”的理由或借口，這就好像“因噎廢食”一樣。幹什麼事都會有困難和問題的，有的人就這樣退縮了，但有的人看得到利大于弊，還是去堅持，人與人的不同正在這個地方。這就是為什麼運動會受傷，但還是會人去運動，而有人因為怕受傷就退縮了一樣。

被業務逼得太緊

被業務逼得太緊，需求亂變，這其實和Code Review沒有多大關系了。對此，我想先講一個我的故事。

我去年在阿裡的聚石塔，剛去的時候，聚石塔正在做一個很大的重構——對架構的大調整。是以壓了很多業務需求，等這個項目花了2-3個月做完了後，一下子湧入了30-50個需求，還規定一個月完成，搞得團隊疲于奔命。在累了兩周後，我仔細分析了一下這些需求，發現很多需求是在重複做阿裡雲已經做過的東西，還有一些需求是因為聚石塔這個平台不規範沒有标準所産生的問題。于是，我做了這麼三件事：

1）重新定義聚石塔這個産品主要目标和範圍，确定哪些該做，哪些不該做。

2）為聚石塔制定标準 ，讓阿裡雲的API都長得基本一樣，并制訂雲資源的接入标準。

3）推動重構阿裡雲的Portal系統，不再實作阿裡雲已經做過的東西，與阿裡雲緊密結合。

這些事情推動起來并不容易，聚石塔的業務方一開始也不了解，我和産品一起做業務方的工作，而阿裡雲也被我逼得很慘（在這裡一并感謝，尤其阿裡雲的同學，老實說，和阿裡雲跨團隊合作中是我這麼多年來感覺最好的一次，相當贊）。通過這個事，聚石塔需求一下就有質的下降了。搞得還有幾個工程師來和我說，你這麼搞，聚石塔就沒事可幹了。姑且不說工程師對聚石塔的了解是怎麼樣的。 我隻想說，我大量地減少了需求，盡最大可能聯合了該聯合的人，而不是自己閉門造車，并讓産品的目标和方向更明确了。做了這些事情後，大家不但不用加班，而且還有時間充電去學技術，并為聚石塔思考未來的方向和發展。去年公司996的時候，我的團隊還在965（搞得跟異教徒似的），而且還有很多時間去專研新的東西。

說這個故事，我不是為了得瑟，而是因為有些人在微網誌上抨擊我是一個道貌岸然的隻會談概念講道理的裝逼犯。是以，我告訴大家我在聚石塔是怎麼做的，我公開寫在這裡，你也可以向相關的同學去求證我說的是不是真的。也向你證明，我可能是個裝逼犯，但絕不是隻會談概念講道理的裝逼犯。

被業務方逼得緊不要抱怨，你沒有時間被逼得像牲口一樣工作，這個時候，你需要的是暫停一下想一想，為什麼會像牲口一樣？而這正是讓你變得聰明的機會。

我為你總結一下，

1）你有沒有去Review業務部門給你的這麼多的需求，哪些是合理的，哪些是不合理的。在Amazon，開發工程師都會被教育拿到需求後一定要問——“為什麼要做？業務影響度有多大？有多少使用者受益？”，回答不清這個問題，沒有資料的支援，就不做。是以，産品經理要做很多資料挖拙和使用者調研的工作，而不是拍拍腦袋，聽極少數的使用者抱怨就要開需求了。

2）産品經理也要管理和教育的。你要告訴你的産品經理：“你是一個好的産品經理，因為你不但對使用者把握得很好，也會對軟體工藝把握得很好。你不但會開出外在的功能性需求，也同樣會開出内在的讓軟體系統更完善的非功能性需求。你不是在遷就使用者，而是引導使用者。你不會無限制地加功能，而是把握産品靈魂控制并簡化功能。你會為自己要做的和不做東西的感到同樣的自豪。”你要告訴你的産品經理：“做一個半成品不如做好半年産品”（更多這樣的觀點請參看《Rework摘錄和感想》）

3）做事情是要講效率的。Amazon裡喜歡使用一種叫T-Shirt Size Estimation的評估方法來優先做投入小産出大的“Happy Case”。關于什麼是效率，什麼是T-Shirt Size Estimation，你可以看看《加班與效率》一文 。

4）需求總是會變化的，不要抱怨需求變化太快。你應該抱怨的是為什麼我們沒有把握好方向？老變？這個事就像踢足球一樣，你要去的地方是球将要去的地方，而不是球現在的地方。你要知道球要去哪裡，你就知道球之前是怎麼動的，找到了運動軌迹後，你才知道球要去像何方。如果你都不知道球要去向何方，那你就是一隻無頭蒼蠅一樣，東一下西一下。

當你忙得跟牲口一樣，你應該停下來，問一下自己，自己成為牲口的原因，是不是就是因為自己做事時候像就牲口一樣思考？

其它

最後，我在給阿裡今年新入職的畢業生的“技塑人生”的分享中，我給他們布置了5、6個Homework，分享幾個給大家：

1）重構或寫一個子產品，把他做成真正的Elegant級别。

2）與大家分享一篇或幾篇技術文章 ，并收獲10-30個贊。

3）降低現有至少20%的重複工作或維護工作

4）拒絕或簡化一個需求（需要項目中所有的Stakeholders都同意）

部署這些作業的原因，是我希望新入行的同學們對自己的工作堅持高的标準，我知道你們會因為骨感的現實而妥協，但是我希望你們就算在現實中妥協了也要在内心中堅持盡可能高的标準，不要習慣成自然，最後被社會這個大染缸給潛移默化了。因為你至少要對自己負責。對自己負責就是，用腳投票，如果妥協得受不了了就離開吧。

芝蘭生于空谷，不以無人而不芳！君子修身養道，不以窮困而改志！

謝謝聽我唠叨。

（全文完）