代碼審查和不良編程習(xí)慣
有時候，做為一個程序員，我覺得我的職業(yè)生涯會被我開發(fā)軟件使用的開發(fā)工具和技術(shù)架構(gòu)明顯的分割成幾個階段。一部分是因為使用的編程語言——在大學(xué)時是Smalltalk，在Gog Creek公司是C#和Python，而另一方面是開發(fā)工具。我在Fog Creek公司里工作了8年，在那里，我們有一個非常固定的技術(shù)架構(gòu)：bug管理、客戶支持和文檔管理用FogBugz；開發(fā)管理用Trello；代碼審查用Kiln；版本控制用Mercurial；編碼用Vim和 Visual Studio ；持續(xù)集成用我們的內(nèi)部工具Mortar；隨著時間的流逝，這些工具在慢慢的變化，但變化從來都是緩慢逐步的，一個組件一個組件的。所以，我的工作流程和工作效率一直沒有巨大的變化。
大概一個月前，我加入了Knewton公司，整個技術(shù)架構(gòu)一下子完全變了。Visual Studio換成了IntelliJ；Mortar換成了Jenkins；Mercurial換成了Git；FogBugz換成了JIRA。
也 許你會覺得這會讓我頭大，還會有些不知所措，但事實上并不是這樣，這些工具的改變并沒有對我的工作流程產(chǎn)生多大的影響。我發(fā)現(xiàn)Git和Mercurial 驚人的相似，JIRA基本上是一個半成品的FogBugz，而IntelliJ算是和Visual Studio差不多吧。也許我需要從新學(xué)習(xí)一些快捷鍵和了解按鈕的位置，但事實上我的開發(fā)模式?jīng)]有實質(zhì)的變化。
但有一個例外：我不喜歡使用Gerrit做代碼審查。不喜歡它的原因并不是它的程序?qū)懙暮軤€；不喜歡的原因是它的流程會鼓勵一種不良編程習(xí)慣。
Knewton公司對代碼審查非常、非常的看重。這非常好，因為我也是這樣，而且我開發(fā)過整套關(guān)于代碼審查的工具。所以，我的意思絕對不是反對代碼審查。
而且，Gerrit的設(shè)計跟最初的 Kiln 原型的設(shè)計幾乎完全一致。代碼審查的實施有兩種基本的方式：pre-merge，是指在代碼進入主代碼庫之前進行代碼審查。和post-commit， 是指之后審查。新版本的Kiln對兩種方式都支持，但在2008年，當Tyler和我通過一個項目——也就是Kiln的前身——在Django Dash中取勝時，我們倆都認同pre-merge的工作流程。直接提交到主代碼庫是不允許的；你需要先創(chuàng)建一個審查區(qū)，把修改的代碼放進去，討論，然 后，等待批準，系統(tǒng)會自動合并這些代碼。這一種是我最欣賞的工作流程，所以Kiln一直支持這種方式(通過“Read and Branch”權(quán)限)，而巧的事，這也是Gerrit唯一支持的方式，按理說我應(yīng)該喜歡它才是。
我差一點就喜歡它了，但問題出在一個致命問題上：代碼審查的粒度。在Kiln中，審查是基于被修改的相關(guān)代碼。而在Gerrit里，審查是基于單次代碼修改提交。在Kiln中，一個單一審查會涉及很多次代碼提交，審查的批準和拒絕是整體的，而Gerrit里審查的是一次孤立的提交。
這 兩種方法模式在各自的陣營里都有大量的受歡迎的系統(tǒng)實現(xiàn)。GitHub和Bitbucket都和Kiln一樣都屬于“批量提交”審查陣營，而Review Board, Barkeep, 和 Phabricator 都加入了“單一提交”審查陣營。所以，情況并不是我所說的某一種方式、某一款軟件是對的，而其它都是錯的。但我還是要堅持說，批量審查的方式是對的，而其 余的都是錯的，因為單一提交審查系統(tǒng)在鼓勵一種不良編程習(xí)慣。
單一提交審查系統(tǒng)有兩個最根本的問題：
- 它在向你暗示各個修改提交之間沒有關(guān)聯(lián)。經(jīng) 常的，每當我實現(xiàn)一個新功能時，我都會有三個步驟：首先，重構(gòu)現(xiàn)有的代碼，讓代碼整潔，方便添加新功能；接下來，加入新功能；***，寫單元測試代碼。功能 越復(fù)雜，各個步驟里越有可能各自包含多個邏輯步驟。如果能將多個不同的提交放的一個代碼審查中進行，那你就可以簡單的將這些修改分組提交。但如果使用的是 單一提交審查系統(tǒng)，那就是在迫使我將所有修改全部完成后進行一次全量提交。這樣一來，重構(gòu)的代碼，新添加的代碼，都混在一起，讓人非常不爽，而且在審查過 程中需要我付出大量額外的精力來指出各部分代碼都是干嘛的。你也許會爭辯，說你可以把修改的代碼拆分提交，每一個提交對應(yīng)一次審查。但事實上這樣做會更 糟。***的情況下，你可以把測試程序和新功能代碼分開提交，可以把重構(gòu)代碼和后加代碼分開提交，但真正的問題是，眾多的單一修改審查系統(tǒng)都慫恿對某個提交 在孤立的狀態(tài)下進行批準，這完全會和你的愿望相反。于是，“一次提交一次審查”的折中就從“麻煩”變成了“危險”。的確不是一種改進。
- 它在慫恿你隱藏歷史記錄。 版本控制系統(tǒng)的最重要的功能就是告訴你代碼演變的歷史、是如何變成今天這個樣子的。我經(jīng)常會查看昨天代碼是什么樣的，上周二下午2點代碼是什么樣的，期間 發(fā)生了什么變化。很多時候是因為我發(fā)現(xiàn)代碼以前好用而現(xiàn)在不行，我想知道為什么。而更多時候，我是想知道為什么會對代碼做這樣的修改。關(guān)聯(lián)的上下文是什 么？動機是什么？如果你總是保持所有代碼一次提交——為了審查，那我就喪失了很多歷史信息：所有我能找到的就是一次完整軟件的一次提交，完全沒有開發(fā)過程 中的過程信息。
這就是我為什么對Gerrit極度失望的原因。并不是Gerrit是一個糟糕的軟件，而是他在鼓勵一種在使用版本控制時不良的開發(fā)習(xí)慣。這就是為什么所有工具中唯獨不喜歡它的原因，是唯一讓我對放棄Kiln感到失望的系統(tǒng)。
