Code Review 的巔峰
Code Review
張大胖工作快一年了，這一年看了不少書，尤其是編程實踐方面，例如單元測試、重構(gòu)、持續(xù)集成等等， 和公司的開發(fā)現(xiàn)狀一對比， 就發(fā)現(xiàn)很多軟件開發(fā)實踐不夠規(guī)范，比如說Code Review完全就沒有。
張大胖是那種遇到問題不逃避，不推脫，反而迎難而上的人，他心想既然現(xiàn)在公司沒有這個流程，我可以提議，甚至推動把Code Review這件事情給建立起來。
他在中午吃飯時“勾搭”了一下部門經(jīng)理，把想法匯報了一下，成功取得了經(jīng)理的支持和授權(quán)：推動Code Review流程的建立。
張大胖先收集了很多資料發(fā)給大家，用于宣傳Code Review的好處 ， 他制作了一個精美的PPT，召集會議給大家預(yù)熱講解。
隨后他便結(jié)合公司的源碼管理工具， 建立了強制Code Review的制度，沒有經(jīng)過Code Review的代碼，不允許進入代碼庫。 至少有兩個人Review過代碼才算通過。
CheckStyle 和連坐
張大胖滿心期待這樣的流程能夠發(fā)現(xiàn)Bug ，提高代碼質(zhì)量，可是試運行了一周以后，靜悄悄的，大家通過Code Review糾結(jié)的盡是一些代碼風(fēng)格的問題：縮進不夠了，空格太少，一行的字符太多了等等， 這對于提高代碼質(zhì)量并沒有很大的幫助，還浪費了不少時間。
張大胖思考了一陣，決定引入工具來自動化地做這些瑣碎的事情，比如Checkstyle，用工具把這些代碼風(fēng)格問題消滅在程序員的本地代碼中， 不改正Checkstyle發(fā)現(xiàn)的問題，連代碼評審這一步都走不到。
這下子大家必須得動動腦子去Review代碼了吧！張大胖想。
但人都是懶惰的，想改變習(xí)慣是很難的。 又過了一周，那幾個資深的骨干說：哎呀，太忙了，自己的代碼還寫不完，怎么可能Review別人的代碼？
Code Review的效果自然也好不到哪里去。 這時候一直在觀察的部門經(jīng)理對張大胖做出了強有力的支持，他宣布了一項制度：連坐。 即代碼的質(zhì)量由寫代碼的人和Review代碼的人共同負責(zé)。
Check List
張大胖心想這個制度肯定會傷害一些人，但是也應(yīng)該會調(diào)到大家的積極性，將來等到大家習(xí)慣養(yǎng)成了，就可以廢除這個連坐了。
果不其然，Review代碼發(fā)現(xiàn)的有效問題開始增多。只是大家的喜好不同，關(guān)注的重點不同，老李關(guān)注可讀性，老王習(xí)慣看各種異常處理和次要分支條件，老方喜歡看類的設(shè)計是否合理， 大周最關(guān)心代碼對別的模塊的影響，還有性能問題......
張大胖是個有心人，他把這些問題總結(jié)，分析了一下，形成了一份Code Review Check List，列舉出來Code Review應(yīng)該關(guān)注的點， 請各位資深大牛審查，補充以后便正式頒布實施。
大家都挺認可這份CheckList， 積極性也提高了，張大胖想，這下可以消停一陣了。
代碼量控制
沒想到新問題很快就出現(xiàn)了，有些人不喜歡“小步快跑”，總是在工作了一周以后，達到階段性目標以后才愿意提交代碼Review， 這就帶來了兩個問題： 一個是Reviewer 一下子面對大量的代碼，看不過來，很容易喪失信心，于是草草掃過了事。 第二個是如果發(fā)現(xiàn)了嚴重問題，再讓作者返工，也是很難的。
張大胖趕緊和大家商量，不要一下子提交這么多代碼，而是要小步快跑，控制每次Review代碼的數(shù)量。 大家同意每次Review的代碼要控制在200至400行以內(nèi)。 讓Reviewer有意愿去做真正的Review，而不是流于形式。
另外對于特別復(fù)雜、特別重要的模塊，要專門把相關(guān)人等“糾集”到一起，在會議室中一行一行做嚴格的代碼評審。
經(jīng)過這么一番折騰，大家終于養(yǎng)成了習(xí)慣，原來的“連坐”機制也廢除了，改成了獎勵機制，給與那些在代碼評審中發(fā)現(xiàn)重要Bug的人以精神和物質(zhì)的獎勵。
張大胖發(fā)現(xiàn)，其實Code Review改變了人的思想意識，原來為了快速完成功能，大家寫代碼的時候都沒有思考太多，現(xiàn)在不一樣了，一想到自己的代碼馬上就要被別人審視， 就像開源軟件一樣，寫得小心翼翼了。還會對照著CheckList好好想想，盡自己最大努力寫好代碼，看起來在開發(fā)上花費的時間唱了，但是Bug大量減少了。慢慢地，自己的水平也提高了。
結(jié)對編程： Code Review的巔峰
一天晚上上網(wǎng)瀏覽時，張大胖發(fā)現(xiàn)了一個有趣的東西：極限編程。
這個極限編程是敏捷軟件開發(fā)領(lǐng)域的一個“奇葩”， 它的宗旨就是：如果一個軟件開發(fā)的實踐很好，我們就把它做到極致！
所以既然測試是好的，我們就先寫測試，再寫代碼 ，這就是TDD。
既然Code Review這么好，那我們就在一個程序員寫代碼的時候，安排另外一個人時時刻刻去Review代碼，定期讓這兩個人的角色互換， 這就是結(jié)對編程。
看到這里，張大胖激動地一下子跳了起來： 臥草，這才是Code Review的巔峰?。?/p>
第二天上午，張大胖興沖沖去找經(jīng)理，希望在部門實施結(jié)對編程， 可這一次經(jīng)理并沒有像上次那樣全力支持，只是答應(yīng)他小范圍嘗試。
張大胖找了和自己水平差不多的小李和自己結(jié)對編程，嘗試共同完成一個需求。張大胖一會兒當(dāng)Driver， 主要控制鍵盤寫代碼；一會兒當(dāng)Navigator，關(guān)注宏觀目標，思考問題，并且Review。
一天時間下來，他倆的共同感受就是：真TMD累！
小李開玩笑地說：“下次你給我安排個女生一起‘結(jié)對編程’吧， 男女搭配，干活不累！”
原來“單干”的時候遇到問題了，總是想休息一下，拿起手機看看新聞，刷刷朋友圈，時間很快就過去了。雖說一天工作9個多小時，但是真正高效率的編程時間可能還不到4個小時。 現(xiàn)在可好，旁邊一直有個人盯著，精神時刻處于高度緊張之中，不是在寫代碼，就是在思考怎么解決問題。
寫出代碼質(zhì)量確實不錯，Code Review時以及測試階段幾乎沒有發(fā)現(xiàn)問題。
向經(jīng)理匯報時，張大胖做了如下的總結(jié)：
1. 心態(tài)得開放，愿意“暴露”自己，并且接受別人的建議
對很多程序員來講，并不愿意暴露自己編程的思路和技術(shù)水平，這也算是程序員的小隱私了。結(jié)對編程就得要求思維的透明化，別人得充分了解你的思路，從而能了解你的水平。 尤其是自己寫每一行代碼都被人盯著，隨時接受“審判” ， 如果沒有開發(fā)的心態(tài)，是做不到的。
2. 當(dāng)Driver在寫代碼時，不能頻繁地被打斷。
張大胖有幾次在專心致志地寫一個復(fù)雜的功能時，小李老是提示他變量名命名不合適，其實他自己也知道，只是還沒改，這讓他很不爽。
3. 不能太霸道
小李有一段時間一直霸占著鍵盤不放，自己說了好幾次他才戀戀不舍地把鍵盤遞過來。
4. 兩個人的水平應(yīng)該差不太多。
如果差得太多，就變成了一個人教另外一個人編程了。
經(jīng)理聽了以后說道：“結(jié)對編程看起來很美，執(zhí)行起來還是有難度的，很多人不愿意在寫代碼的時候被別人盯著，不愿意'暴露'自己。它的見效周期也比較長，管理層不愿意看到兩個人干一份活兒， 我們還是先放下吧。”
雖然心有不甘，但是張大胖承認經(jīng)理說得很對，暫時放棄吧。
年終的時候，張大胖由于對Code Review這個制度的建設(shè)而獲得了公司的獎勵，他總結(jié)了一些成功的經(jīng)驗：
1. 領(lǐng)導(dǎo)的支持
2. 民主的決策
3. 能用工具完成的，就別讓人再麻煩了。
4. CheckList很有用
5. 每次review適量的代碼
【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號coderising獲取授權(quán)】
