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適量的代碼
【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】
