從Code Review 談如何作技術

這兩天，在微博上表達了一下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）需求老是會變化的，不要抱怨需求變化太快。你應該抱怨的是爲何咱們沒有把握好方向？老變？這個事就像踢足球同樣，你要去的地方是球將要去的地方，而不是球如今的地方。你要知道球要去哪裏，你就知道球以前是怎麼動的，找到了運動軌跡後，你才知道球要去像何方。若是你都不知道球要去向何方，那你就是一隻無頭蒼蠅同樣，東一下西一下。

當你忙得跟牲口同樣，你應該停下來，問一下本身，本身成爲牲口的緣由，是否是就是由於本身作事時候像就牲口同樣思考？

其它

最後，我在給阿里今年新入職的畢業生的「技塑人生」的分享中，我給他們佈置了五、6個Homework，分享幾個給你們：

1）重構或寫一個模塊，把他作成真正的Elegant級別。

2）與你們分享一篇或幾篇技術文章 ，並收穫10-30個贊。

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

4）拒絕或簡化一個需求（須要項目中全部的Stakeholders都贊成）

部署這些做業的緣由，是我但願新入行的同窗們對本身的工做堅持高的標準，我知道大家會由於骨感的現實而妥協，可是我但願大家就算在現實中妥協了也要在心裏中堅持儘量高的標準，不要習慣成天然，最後被社會這個大染缸給潛移默化了。由於你至少要對本身負責。對本身負責就是，用腳投票，若是妥協得受不了了就離開吧。

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

謝謝聽我嘮叨。

（全文完）

（轉載本站文章請註明做者和出處 酷 殼 – CoolShell.cn ，請勿用於任何商業用途）

——===   訪問 酷殼404頁面尋找遺失兒童。 ===——