讓代碼審查成爲你的團隊習慣

在 「遠程工做經驗談 - 如何適應及如何管理」 一文中，我在規則這章節提到了代碼審查，收到很多朋友的提問和反饋，故在本文中拓展開來聊聊。

在 Wikipedia 上，對代碼審查的定義是

代碼審查（英語：Code Review）是指對計算機源代碼系統化地審查，經常使用軟件同行評審的方式進行，其目的是在找出及修正在軟件開發初期未發現的錯誤，提高軟件質量及開發者的技術。代碼審查常以不一樣的形式進行，例如結對編程、非正式的看過整個代碼，或是正式的軟件檢查[1]。

能夠看出，代碼審查主要是爲了軟件質量和我的開發修養。巧合的是，但凡我接觸過的靠譜的團隊，無一不是在團隊中推行嚴格的代碼審查制度。這個就像是一種習慣，直接融入在團隊血液之中。

爲何咱們要求代碼審查

人們習慣用本身能衡量的東西來判斷一件事情，因此對於代碼審查而言，咱們能看到的是它須要花掉一些人的一些額外的時間，那些本應該用來繼續作開發的時間。這也正是代碼審查在團隊推行遇到的最大阻力。

在咱們 Pragmatic.ly 的實踐中，代碼審查給咱們帶來的三點好處。

1. 代碼審查保證軟件質量。咱們團隊沒有專門的 QA 人員，測試通常由完成功能的程序員完成，思考不夠周全，有時也達不到徹底的測試覆蓋率，咱們在作代碼審查時已經不少次發現過當事者沒考慮過到的設計細節和一些實現上的 bug。它已成爲咱們團隊找 bug 的一大手段，對於軟件質量保證有很大貢獻。在有些嚴格的團隊如 Facebook，每個修改若是沒有被 3 個不一樣的成員審查經過，代碼都不能作發佈。
2. 代碼審查促進團隊成長。經過代碼審查，每一個人能夠學習到其餘人好的的思惟方式和編碼方式，也會提出作的很差的地方和改進意見，是整個團隊在代碼級別的另外一種溝通和思考。我發現過了一段時間後，團隊的成長是喜人的。對於專門花時間去作培訓，成本低多了，XD
3. 代碼審查避免單點故障。每一行代碼，團隊裏至少有兩我的以上是瞭解的。因此萬一出了問題，即便代碼編寫者不在，咱們仍然有其餘人能馬上去修正。經理不再擔憂出現蟲子了。並且，視團隊狀況，最好嘗試交叉審查，不要總是 A 審查 B，B 審查 A，換着審查效果更好。

若是你的團隊尚未作代碼審查，我很建議去嘗試幾個迭代週期，而後作個過程回顧，看看是否適合於團隊，我相信結果確定不會讓大家失望，:)

代碼審查應該是羣體行爲

這個是我在不少團隊看到的問題。有些團隊雖然在作代碼審查，可是主要仍是爲了保證軟件質量，沒有最好的發揮代碼審查的威力。我聽過過不少次「他們經驗比較淺，可能沒法對別人的代碼作審查」。不，不是這樣子的。代碼審查應該是羣體行爲，與經驗無關。俗話說，三個臭皮匠，頂個諸葛亮。即便是經驗欠缺的團隊，若是能羣策羣力，也能交付出頂級質量的軟件。這裏先不論代碼審查對團隊的成長，單單是每一次修改都讓其餘人審查的行爲，就能提升初級程序員的信心、對產品的參與度和責任心。反之，有些人會一直呆在舒服區，反正有人幫忙作審查提意見。

Do it and get surprised!

咱們團隊如何作代碼審查

我在 Intridea 和 Pragmatic.ly 作項目管理時都作代碼審查，主要嘗試過兩種方式，最經常使用的是 Github 倡導的 Pull Request，還有就是結對編程。

Pull Request

這是咱們最經常使用的方式，咱們用 Pragmatic.ly 作項目管理，用 BitBucket 作代碼版本控制系統。每一個任務都會基於線上版本開一個新的分支，當任務完成後，提交推送到 BitBucket 的時候，會自動的關聯這個提交到 Pragmatic.ly 中，也建立了一個 Pull Request。當有 Pull Request 出現時，咱們的原則是誰有空誰審查，並不指派到人。整個審查過程，提意見，作修改，直到被經過，等待上線。具體例子能夠見下圖，

值得一提的是，咱們在作代碼審查的時候會關注下面一些問題。

1. 基本功能工做不，要實際跑起來看。
2. 代碼實現清晰易讀嗎
3. 有沒有沒有考慮到的點，特別是對其餘部分代碼會否形成影響
4. 是否是最好的實現，有沒有重構的空間
5. 測試代碼一樣須要審查

若是你對 Pull Request 方式感興趣，推薦一個我很是喜歡的 Talk，來自 Zach Holman 的 「How Github Uses Github To Build Github」。Zach Holman 也是咱們今年 RubyConf China 的邀請嘉賓，歡迎廣大 Ruby 愛好者來京交流，XD

結對編程

由於咱們是一直在遠程工做，因此對於結對編程實踐並很少。在有限的幾回裏，咱們是用一個共享的 VPS + TMux 結對，也有時用 GoToMeeting 這樣的在線會議系統作結對編程。結對編程等同於實時代碼審查，有限的幾回結對編程體驗都不錯，開發效率提高颼颼的，也是很好的互相學習的機會，可是太累了，同時由於遠程的緣故受網絡條件制約太多.... Kevin 曾在 Teahour 裏分享過他們在 HashRocket 的結對編程經驗分享，歎爲觀止，有興趣的能夠聽聽這一期。若是大家團隊在一塊兒辦公，推薦嘗試一下結對編程，不過嚴格的每一個任務都作結對編程不推薦。

建議

以上就是咱們團隊在代碼審查上的經驗和思考，但願對你有幫助。讓代碼審查融入團隊的血液，成爲大家的工做習慣，絕對會是大家在團隊管理上作出的最正確的決定之一，去嘗試吧！若是對於代碼審查實踐或者團隊管理上面有任何想交流的，歡迎隨時聯繫我，任何我列出的聯繫方式均可以。

最後，上篇博客最後一段頗有用，收穫了很多關注者，因此故伎重演，XD。若是你讀到這裏了，那麼你應該在微博上加我爲好友。我也會在 Pragmatic.ly 微博帳號發佈更多關於團隊協做、團隊管理方面的思考。謝謝！