為什么需要代碼審查

最近看了一些文章，發(fā)現(xiàn)敏捷開發(fā)的一些理念越來越多的團隊在實踐，也覺得敏捷不再像最早提出的時候那么虛，有很多體現(xiàn)這個理念的工具涌現(xiàn)。其中，“如何提高代碼質(zhì)量”的討論一直很多，敏捷開發(fā)中也有好多種提案，最廣為人知、但也最不靠譜的應(yīng)該就是結(jié)對編程了，只要沒被敏捷洗腦的人都清楚知道這個基本沒有實際可操作性，然而這個做法體現(xiàn)的觀點是多個人互相監(jiān)督可以把事情做的更好，這反而是完全沒有問題的。所以還有一種方式就是代碼審查了，把兩人同時寫代碼改成在不同的時間上一個人寫、另外一個人看。這個實際開發(fā)中是完全可以做到的，只是要留有審查的時間即可。

復(fù)查團隊成員的代碼自己一直也是無意識的在做，經(jīng)常去看git log，但是這個方式效率真的很低，也沒有嚴格的規(guī)定，所以做的也比較隨意。恰巧最近看到一個論調(diào)，“越牛逼的團隊，對于代碼審查的態(tài)度越嚴謹”，頓時引發(fā)共鳴，長久以來在心里一直有一種這樣去檢查代碼的方式是不行的感覺，但是一直也沒找到合適的方式，而這次再聯(lián)想到代碼審查感覺如獲至寶，怎么一直都把它給忘了呢？！

如果你對代碼審查能帶來什么好處有疑問的話，請仔細閱讀Phabricator官網(wǎng)的這篇文章。

代碼審查的方式

代碼審查主要有兩種方式：

1. pre-push：在提交合并代碼之前，先進行審查，通過和才能合并。這是一種非常嚴格的審查方式，可以確保每個發(fā)布的代碼都是已經(jīng)被審查過的。這種放到在github上維護的開源項目極其合適，代碼的所有者可以確保代碼是在自己的控制范圍。

2. post-push：代碼提交后，再審查之前的代碼。這是非常寬松的審查方式，審查的效果肯定是打折扣的，但是好處是可以忽略一些不必要的審查以節(jié)約時間。其實在國內(nèi)這種沒有太多工程師文化的地方，這種方式是比較好在早期推行的。

代碼審查的工具

這個事情在團隊中實行的話，是一定需要有個工具的，相關(guān)的工具有很多，審查方式也各有偏重。這里工具主要是解決了這幾個問題：

1. 有一個更為直觀的界面查看diff。

2. 可以基于工具進行簡單的標記和通知，直接把標記寫在代碼里更利于溝通。

3. 可以知道哪些提交時已經(jīng)被誰審查過了，方便審查的協(xié)作。

之前在sf寫過一篇問答可以參考。這里再例舉一些，供參考選擇。

1. Gerrit：google的產(chǎn)品，名氣很大，但是這個東西設(shè)計理念比較陳舊，據(jù)說也沒有什么維護了，不推薦。

2. github pull request：這個當(dāng)然很好，典型的pre-push方式，但是個人用也沒太多協(xié)同的事情，團隊用又覺得貴。其實感覺用bitbucket會經(jīng)濟實用些。

3. phabricator：facebook內(nèi)部使用并開源出來的工具，功能超級強大，但相對的就是非常復(fù)雜，界面設(shè)計非常歐美的風(fēng)格，運行速度也有點慢。東西還是很牛逼的，看你是不是喜歡了。

4. gitlab：如果是自己搭建的git server，這個是不錯的選擇，相當(dāng)于自己弄了個github，就是配置環(huán)境會比較多工作量。

5. upsource：JetBrains的產(chǎn)品，只有post-push的方式，但是從安裝、界面、到使用都是挺不錯的，唯一問題就是10個人以上要收費，而且還很貴。

我們從中的獲益

選用哪種方式，我覺得因團隊文化、項目背景、效果預(yù)期而定,我們最后暫時選用的是upsource，目標是先在團隊中把代碼審查施行起來。

目前來看效果還可以。有了工具之后大家互相做代碼審查也方便很多，心理抗拒性也沒那么強。其實只要進度不那么催，研發(fā)人員還是比較愿意去做這種事情的。審查過程中目前發(fā)現(xiàn)了一些代碼中的問題，但是現(xiàn)在還不多，我想只要能在出現(xiàn)bug之前能解決掉一些問題，就已經(jīng)有很大價值了。