讓代碼審查扮演更好的角色
代碼審查(Code Review)是很多大公司里面都有的一個流程。它指的是一個人編碼，另有幾個人負責審查，并提出修改意見。代碼審查在大多數(shù)情況下對公司整體的工程質量是有提高的，但是如果使用不當?shù)脑挘芸赡芊吹箷档凸こ藤|量。代碼審查究竟在一個組織里面是有正面效應或者是負面效應取決于很多因素，而我認為其中最重要的是代碼審查在開發(fā)過程中扮演的角色。
首先，我們先看看在代碼審查中所需要找出的問題類型。它們可以是：
- 語法及代碼風格問題：一般有靜態(tài)檢查工具可以解決，但難免有疏漏。
- 效率問題：需要有一定經(jīng)驗的人來辨別低效的部分。
- 命名問題：這其實是一個很經(jīng)常出現(xiàn)也很重要的問題。對于一個人來講說得通的命名不見得對于團隊而言說得通，所以很多時候較難的命名要由團隊通過代碼審查協(xié)同解決。
- 設計問題：小到接口的設計，大到服務間通信的協(xié)議，都屬于設計問題，根據(jù)情況可以由小部分人或者整個團隊解決。設計問題是代碼審查中最常見的問題。
對于前三種問題，相對來講都很好解決。其中相對棘手的莫過效率問題，但實際上基本上知道效率問題的人都知道優(yōu)化方案。然而，如果一個審查的人突然提出一個很合理的設計問題，需要你重新修改源代碼，你會發(fā)現(xiàn)你需要花大量地時間重新編寫。
例如，在編寫一個JavaScript庫packageA的時候，你提交了代碼審查。有人可能會提醒你：packageA是用于桌面端網(wǎng)站的庫，相對應的還有一個移動端的庫packageB。為了保持工程上的一致性，建議把packageA改成盒packageB一樣的API。一致性一直以來是一個讓人無法反駁的設計追求，所以你只好把辛辛苦苦自己設計好的API全部重改…
所以，若你的代碼里面被提出存在設計問題，消耗的工程時間會增加。而工程時間對公司來講就是金錢。
造成存在需要大改的設計問題的原因其實無非三個：
- 設計能力不足
- 對開發(fā)的系統(tǒng)不熟悉，缺乏上下文(Context)
- 過晚提交代碼審查
前兩個原因都很直白，但是第三個原因有點匪夷所思。什么叫做過晚提交代碼審查?
我想是代碼審查英文單詞中的”Review”給予人的誤導，很多人是在代碼幾乎完成或者已經(jīng)完成后才提交代碼審查的。就好像在做一盤菜，做到***一步的時候才想起來要嘗一小口看看味道對不對，結果發(fā)現(xiàn)沒加鹽。
在***一步進行代碼審查，還會因為審查者一下子接收太多信息，而造成他可能無法發(fā)現(xiàn)一些應該發(fā)現(xiàn)的問題。
顯然“審查”扮演的角色在這里出現(xiàn)了問題，它不應該是傳統(tǒng)意義上的到***一步進行把關，而應該是貫穿整個編碼過程的一個輔助過程。用比較老式的軟件工程“土話”說，它應該是一個Umbrella Activity(雨傘活動)，全程保護編碼過程的質量。
現(xiàn)在，我的代碼審查流程是這樣的：首先完成一個基本的設計，加上基本的注釋，達到一個完成度——最可能出現(xiàn)大設計問題的完成度。接著 commit，并推入到代碼審查中，邀請其他人來審查。這基本上就是對他們說，“看，這是我寫的，很簡單，可能爛得跟一坨屎一樣，麻煩你們幫我看看有沒有什么大問題”。
稍微有點開發(fā)經(jīng)驗的人，都可以大概估計出自己手頭的工作進行到哪一步可能出現(xiàn)大的設計問題。例如，當你在設計一個新的模塊，那么可能出現(xiàn)大的設計問題的時候可能就是設計API的時候。再緊接著，下一個可能出現(xiàn)大的設計問題的就是類之間的抽象關系，等等。
我甚至還會自己給自己的代碼進行審查。這并不是在做驗算，而是在通過代碼審查告訴團隊自己的疑問，提出自己的想法，這樣大家就能更好地與你溝通。相信我，把有疑問、猶豫不決的地方提出來;有自己獨特想法的地方，也要指出來，因為你的獨特想法有時候對團隊來講就是不好的想法。
每當遇到心里覺得可能出現(xiàn)大的設計問題的時候，盡量利用代碼審查，讓團隊和你一起解決。對于工程經(jīng)驗少的人來說(比如我)，更應該多做一點這樣的事。一開始這樣做可能反倒會開銷更多人的時間，但是過一陣子之后，你就更有把握做好的設計決策。換句話說，發(fā)生大設計問題的概率就會降低。因為你總能在和別人溝通的時候學到新東西。
然而，如果每次都在編碼完成之后再進行代碼審查，雖說***經(jīng)過代碼審查可能也會產(chǎn)出高質量的代碼，可你將花大部分時間在煩悶上，而花很少的時間真正體會他人提出的意見的真正價值。
長此以往，整個工程團隊的工程時間可以得到顯著的下降。首先是因為每個人的經(jīng)驗都能通過代碼審查增長得更快，因此總體工程效率會提高;第二是因為全程保護的代碼審查很好地解決(或緩解)各種層面的設計問題，讓工程無論從短期還是長期來講，需要花費的工程時間降低，并且技術債務(technical debt)也會減少。
幸運的是，雖說這里提到的是比較宏觀的流程問題，卻是一件落實到每個工程師自身的事情。也就是說，代碼審查如何執(zhí)行最終還是歸結于編碼的工程師個人。整個流程的轉換無需有新的工具加入，也不需要有很多復雜的文檔。所需要的只不過是對團隊的一次培訓——這篇文章或許就是一個不錯的素材。
