作者：曉月 授權本站轉載。

這篇帖子不是通篇介紹Code Review的方法論, 而是前大段記錄了我們團隊怎麼從沒有這個習慣到每天都進行review的過程, 後小段給出了我的一些建議. 希望能對諸位的團隊有所幫助. 

最初來到這個新組建的團隊是木有code review的. 頭說, 這個月你來搞吧.

當我第一次知道必須得搞review的時候, 其實我是拒絕的! 因為我覺得…呀…你不能叫我馬上搞立馬搞, 第一, 我要試一下, 我又不想說…團隊之前就沒有這個習慣. 我搞了以後, 那個耽誤每天的工作時間啊. 結果同事一定會罵我, 給他們增加額外的工作量. 我說先讓我嘗試嘗試. 現在呢…每天都在review!每天都在review呢…我還推廣到了其他團隊!來!來!來!大家試試看!

覺得困難, 開展不起來, 想拒絕的原因有很多:

• 團隊成員寫完需求就不管了, 沒有code review意識

• 技術氛圍不強

• 水平參差不齊

• 沒有合適的工具

• …

但是總的來說就是一條, 木有code review. 如果已經有了, 無論是真的在搞, 還是形式主義, 主持一下都是不難的.

從零到一, 從無到有總是困難的, 咱開始了若干次嘗試之路:

第一次嘗試

最初的版本是其他團隊的寫的, 到我們團隊接手的時候, 啥都木有. 什麼逗號等號左右不空格, 類名首字母小寫, 方法名首字母大寫; 依賴亂七八糟; 在view裡寫業務, 在view裡發網絡請求. 看到這樣的代碼我當時心裡是崩潰的.

我先嘗試一個人幫整個團隊review. 零散看了幾天, 問題代碼貼了幾十張ppt, 槽點太多, 看起來很感人. 後來自己放棄了.

結論

Code Review 一個人扛N個人的代碼是不可取的.

第二次嘗試

結對編程可以看做是一種敏捷化的Code Review. 直接結對會被頭劈死. 於是我想著踩用新的結對編程方式.

兩位程序員新成結對小組, 每人一台電腦, 坐在臨近的工位上, 兩人合作完成一組功能(可以是兩個或多個獨立的模塊)的設計, 代碼實現. 但對已某一個模塊來說設計和代碼是分開的, 一個人負責設計, 另一個人負責寫代碼, 對於其他模塊則反之.

當我在團隊裡尋找可以結對的伙伴的時候, 發現木有可以設計模塊, 項目進度又差不多, 可以結對的小伙伴.

結論

Code Review需要接地氣.

第三次嘗試

第三次嘗試, 我想用一個游戲的方法去開展review

• 每次的review主持輪流當, 由大伙推舉當前找得bug最少的同學來主持.

• 每輪開始的時候,先貼出代碼來, 由下面的同學說問題.(大伙這個時候關注下哪位同學次次都木有發現問題)

• 最後由主持的同學將所有的問題列出來.

• 進入下一輪

• 如果經常是下面的同學說的比主持人多,主持人第二天繼續.

• 主持的同學,每日最少准備6張問題ppt斷.

• 指出的問題由主持人來指定一個修改的同學修改.

• 第二天的主持人負責把當天得bug錄入jira, 並且負責跟蹤這些修復.

太理想化了, 根本開展不起來.

結論

不要自己覺得好就是好, Code Review是團隊的事情, 方案定了得拿出去溜溜.

第四次嘗試

無奈之下, 我去請教我的頭, 如何去開這個頭. 頭就給了兩個字: 強壓.

於是小伙伴們便在我的淫威之下開展了第一次的code review. 我用的是之前第一次整理出的ppt. 效果竟然好的意外. 小伙伴們互相吐槽被我指出來的渣渣代碼, 氣氛很是歡樂.

不過關鍵問題還是沒有一個統一的標准去改. 於是咱緊接著就安排了一場代碼規范的分享. 再接下來的一次review, 大貨吐槽的點就相對集中了.

結論

Code Review初期需要有標准. 讓小伙伴們如何去review.

第五次嘗試

由於之前的氛圍很好, 有小伙伴A提議拿出他負責的模塊來集體review. 有主動的, 當然不能拒絕. 後面幾天安排的都是review他的模塊了. 順帶還做了一次他的模塊的設計分享.

在有天的review中, 有個小伙伴B表示這樣現場重構不是他擅長的. 我們: 那你擅長啥? 小伙伴B: 我擅長xxx. 我: 那下周你來給大貨分享下吧. 小伙伴B: 好, 我准備一下.

結果小伙伴B深藏不漏, 連續分享了一整個系列.

結論

聞道有先後, 術業有專攻, 不要低估你的小伙伴們.

第六次嘗試

我被掛的任務是code review, 所以偶爾還是會看看小伙伴們代碼的. 有天突然發現有個小伙伴C, 在重構優化代碼了. 咱順勢和他說了一些編程方面的思想和技巧, 告訴他還可以這麼重構, 用查表發代替條件語句, 用多態代替提條件語句, 用runtime生成方法名, 用runtime 執行方法. 於是他也出來一個技術分享. 可惜的是關於編程思想的分享討論起來就木有那麼激烈了, 這個只能慢慢來了. 不過當咱吃完飯快8點回到公司的時候, 發現有兩個小伙伴DE在寫demo, 在討論之前C的技術分享.

結論

編程的思想需要慢慢悟, 不能一股腦的灌.

第七次嘗試

有次review, 我有事提前走了. 但是呢, 本是半個小時分享大伙覺得還不盡興, 又延長了二十分鐘. 之前有幾場分享, 也都不是我主持的. 後續的review我將嘗試進一步淡化我的主持. 讓我們的review可以自組織的進行下去.

結論

Code Review需要達到理想的狀態 - 不需要我也能自如地運轉, 不然最後就會輪為政治任務.

後記

隨著團隊的人數增多, 集體review這種方式也會做出調整, 我們會引入一些code review的方法論和工具. 萬事開頭難, 既然已經開了這個頭, 我相信後續的調整也不是什麼難事.

建議

如何做出從零開始code review呢, 我的建議是:

• tech leader 強壓所有人開始 code review, 這是最重要的一步

• 安排一次編碼規范的技術分享

• 前期經常回顧, 這次的code review開展的怎樣, 有哪些地方可以改善

• 對於積極的同學表示鼓勵, 支持現場重構代碼

• 每天不光可以review代碼, 也可以安排整場的技術分享