Code Review 的巔峰

Code Review

張大胖工作快一年了，這一年看了不少書，尤其是編程實踐方面，例如單元測試、重構、持續集成等等， 和公司的開發現狀一對比， 就發現很多軟體開發實踐不夠規範，比如說Code Review完全就沒有。

張大胖是那種遇到問題不逃避，不推脫，反而迎難而上的人，他心想既然現在公司沒有這個流程，我可以提議，甚至推動把Code Review這件事情給建立起來。

他在中午吃飯時「勾搭」了一下部門經理，把想法彙報了一下，成功取得了經理的支持和授權：推動Code Review流程的建立。

張大胖先收集了很多資料發給大家，用於宣傳Code Review的好處 ， 他製作了一個精美的PPT，召集會議給大家預熱講解。

隨後他便結合公司的源碼管理工具， 建立了強制Code Review的制度，沒有經過Code Review的代碼，不允許進入代碼庫。 至少有兩個人Review過代碼才算通過。

CheckStyle 和連坐

張大胖滿心期待這樣的流程能夠發現Bug ，提高代碼質量，可是試運行了一周以後，靜悄悄的，大家通過Code Review糾結的儘是一些代碼風格的問題：縮進不夠了，空格太少，一行的字元太多了等等， 這對於提高代碼質量並沒有很大的幫助，還浪費了不少時間。

張大胖思考了一陣，決定引入工具來自動化地做這些瑣碎的事情，比如Checkstyle，用工具把這些代碼風格問題消滅在程序員的本地代碼中， 不改正Checkstyle發現的問題，連代碼評審這一步都走不到。

這下子大家必須得動動腦子去Review代碼了吧！張大胖想。

但人都是懶惰的，想改變習慣是很難的。 又過了一周，那幾個資深的骨幹說：哎呀，太忙了，自己的代碼還寫不完，怎麼可能Review別人的代碼？

Code Review的效果自然也好不到哪裡去。 這時候一直在觀察的部門經理對張大胖做出了強有力的支持，他宣布了一項制度：連坐。 即代碼的質量由寫代碼的人和Review代碼的人共同負責。

Check List

張大胖心想這個制度肯定會傷害一些人，但是也應該會調到大家的積極性，將來等到大家習慣養成了，就可以廢除這個連坐了。

果不其然，Review代碼發現的有效問題開始增多。只是大家的喜好不同，關注的重點不同，老李關注可讀性，老王習慣看各種異常處理和次要分支條件，老方喜歡看類的設計是否合理， 大周最關心代碼對別的模塊的影響，還有性能問題......

張大胖是個有心人，他把這些問題總結，分析了一下，形成了一份Code Review Check List，列舉出來Code Review應該關注的點， 請各位資深大牛審查，補充以後便正式頒布實施。

大家都挺認可這份CheckList， 積極性也提高了，張大胖想，這下可以消停一陣了。

代碼量控制

沒想到新問題很快就出現了，有些人不喜歡「小步快跑」，總是在工作了一周以後，達到階段性目標以後才願意提交代碼Review， 這就帶來了兩個問題： 一個是Reviewer 一下子面對大量的代碼，看不過來，很容易喪失信心，於是草草掃過了事。 第二個是如果發現了嚴重問題，再讓作者返工，也是很難的。

張大胖趕緊和大家商量，不要一下子提交這麼多代碼，而是要小步快跑，控制每次Review代碼的數量。 大家同意每次Review的代碼要控制在200至400行以內。 讓Reviewer有意願去做真正的Review，而不是流於形式。

另外對於特別複雜、特別重要的模塊，要專門把相關人等「糾集」到一起，在會議室中一行一行做嚴格的代碼評審。

經過這麼一番折騰，大家終於養成了習慣，原來的「連坐」機制也廢除了，改成了獎勵機制，給與那些在代碼評審中發現重要Bug的人以精神和物質的獎勵。

張大胖發現，其實Code Review改變了人的思想意識，原來為了快速完成功能，大家寫代碼的時候都沒有思考太多，現在不一樣了，一想到自己的代碼馬上就要被別人審視， 就像開源軟體一樣，寫得小心翼翼了。還會對照著CheckList好好想想，盡自己最大努力寫好代碼，看起來在開發上花費的時間唱了，但是Bug大量減少了。慢慢地，自己的水平也提高了。

結對編程： Code Review的巔峰

一天晚上上網瀏覽時，張大胖發現了一個有趣的東西：極限編程。

這個極限編程是敏捷軟體開發領域的一個「奇葩」， 它的宗旨就是：如果一個軟體開發的實踐很好，我們就把它做到極致！

所以既然測試是好的，我們就先寫測試，再寫代碼 ，這就是TDD。

既然Code Review這麼好，那我們就在一個程序員寫代碼的時候，安排另外一個人時時刻刻去Review代碼，定期讓這兩個人的角色互換， 這就是結對編程。

看到這裡，張大胖激動地一下子跳了起來： 卧草，這才是Code Review的巔峰啊！

第二天上午，張大胖興沖衝去找經理，希望在部門實施結對編程， 可這一次經理並沒有像上次那樣全力支持，只是答應他小範圍嘗試。

張大胖找了和自己水平差不多的小李和自己結對編程，嘗試共同完成一個需求。張大胖一會兒當Driver， 主要控制鍵盤寫代碼；一會兒當Navigator，關注宏觀目標，思考問題，並且Review。

一天時間下來，他倆的共同感受就是：真TMD累！

小李開玩笑地說：「下次你給我安排個女生一起『結對編程』吧， 男女搭配，幹活不累！」

原來「單幹」的時候遇到問題了，總是想休息一下，拿起手機看看新聞，刷刷朋友圈，時間很快就過去了。雖說一天工作9個多小時，但是真正高效率的編程時間可能還不到4個小時。 現在可好，旁邊一直有個人盯著，精神時刻處於高度緊張之中，不是在寫代碼，就是在思考怎麼解決問題。

寫出代碼質量確實不錯，Code Review時以及測試階段幾乎沒有發現問題。

向經理彙報時，張大胖做了如下的總結：

1. 心態得開放，願意「暴露」自己，並且接受別人的建議

對很多程序員來講，並不願意暴露自己編程的思路和技術水平，這也算是程序員的小隱私了。結對編程就得要求思維的透明化，別人得充分了解你的思路，從而能了解你的水平。 尤其是自己寫每一行代碼都被人盯著，隨時接受「審判」 ， 如果沒有開發的心態，是做不到的。

2. 當Driver在寫代碼時，不能頻繁地被打斷。

張大胖有幾次在專心致志地寫一個複雜的功能時，小李老是提示他變數名命名不合適，其實他自己也知道，只是還沒改，這讓他很不爽。

3. 不能太霸道

小李有一段時間一直霸佔著鍵盤不放，自己說了好幾次他才戀戀不捨地把鍵盤遞過來。

4. 兩個人的水平應該差不太多。

如果差得太多，就變成了一個人教另外一個人編程了。

經理聽了以後說道：「結對編程看起來很美，執行起來還是有難度的，很多人不願意在寫代碼的時候被別人盯著，不願意"暴露"自己。它的見效周期也比較長，管理層不願意看到兩個人干一份活兒， 我們還是先放下吧。」

雖然心有不甘，但是張大胖承認經理說得很對，暫時放棄吧。

年終的時候，張大胖由於對Code Review這個制度的建設而獲得了公司的獎勵，他總結了一些成功的經驗：

1. 領導的支持

2. 民主的決策

3. 能用工具完成的，就別讓人再麻煩了。

4. CheckList很有用

5. 每次review適量的代碼

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！