有時(shí)候，做為一個(gè)程序員，我覺得我的職業(yè)生涯會(huì)被我開發(fā)軟件使用的開發(fā)工具和技術(shù)架構(gòu)明顯的分割成幾個(gè)階段。一部分是因?yàn)槭褂玫木幊陶Z言——在大學(xué)時(shí)是Smalltalk，在Gog Creek公司是C#和Python，而另一方面是開發(fā)工具。我在Fog Creek公司里工作了8年，在那里，我們有一個(gè)非常固定的技術(shù)架構(gòu)：bug管理、客戶支持和文檔管理用FogBugz；開發(fā)管理用Trello；代碼審查用Kiln；版本控制用Mercurial；編碼用Vim和 Visual Studio ；持續(xù)集成用我們的內(nèi)部工具M(jìn)ortar；隨著時(shí)間的流逝，這些工具在慢慢的變化，但變化從來都是緩慢逐步的，一個(gè)組件一個(gè)組件的。所以，我的工作流程和工作效率一直沒有巨大的變化。

　　大概一個(gè)月前，我加入了Knewton公司，整個(gè)技術(shù)架構(gòu)一下子完全變了。Visual Studio換成了IntelliJ；Mortar換成了Jenkins；Mercurial換成了Git；FogBugz換成了JIRA。

　　也許你會(huì)覺得這會(huì)讓我頭大，還會(huì)有些不知所措，但事實(shí)上并不是這樣，這些工具的改變并沒有對我的工作流程產(chǎn)生多大的影響。我發(fā)現(xiàn)Git和Mercurial驚人的相似，JIRA基本上是一個(gè)半成品的FogBugz，而IntelliJ算是和Visual Studio差不多吧。也許我需要從新學(xué)習(xí)一些快捷鍵和了解按鈕的位置，但事實(shí)上我的開發(fā)模式?jīng)]有實(shí)質(zhì)的變化。

　　但有一個(gè)例外：我不喜歡使用Gerrit做代碼審查。不喜歡它的原因并不是它的程序?qū)懙暮軤€；不喜歡的原因是它的流程會(huì)鼓勵(lì)一種不良編程習(xí)慣。

　　Knewton公司對代碼審查非常、非常的看重。這非常好，因?yàn)槲乙彩沁@樣，而且我開發(fā)過整套關(guān)于代碼審查的工具。所以，我的意思絕對不是反對代碼審查。

　　而且，Gerrit的設(shè)計(jì)跟最初的 Kiln 原型的設(shè)計(jì)幾乎完全一致。代碼審查的實(shí)施有兩種基本的方式：PRe-merge，是指在代碼進(jìn)入主代碼庫之前進(jìn)行代碼審查。和post-commit，是指之后審查。新版本的Kiln對兩種方式都支持，但在2008年，當(dāng)Tyler和我通過一個(gè)項(xiàng)目——也就是Kiln的前身——在Django Dash中取勝時(shí)，我們倆都認(rèn)同pre-merge的工作流程。直接提交到主代碼庫是不允許的；你需要先創(chuàng)建一個(gè)審查區(qū)，把修改的代碼放進(jìn)去，討論，然后，等待批準(zhǔn)，系統(tǒng)會(huì)自動(dòng)合并這些代碼。這一種是我最欣賞的工作流程，所以Kiln一直支持這種方式(通過“Read and Branch”權(quán)限)，而巧的事，這也是Gerrit唯一支持的方式，按理說我應(yīng)該喜歡它才是。

　　我差一點(diǎn)就喜歡它了，但問題出在一個(gè)致命問題上：代碼審查的粒度。在Kiln中，審查是基于被修改的相關(guān)代碼。而在Gerrit里，審查是基于單次代碼修改提交。在Kiln中，一個(gè)單一審查會(huì)涉及很多次代碼提交，審查的批準(zhǔn)和拒絕是整體的，而Gerrit里審查的是一次孤立的提交。

　　這兩種方法模式在各自的陣營里都有大量的受歡迎的系統(tǒng)實(shí)現(xiàn)。GitHub和Bitbucket都和Kiln一樣都屬于“批量提交”審查陣營，而Review Board, Barkeep, 和 Phabricator 都加入了“單一提交”審查陣營。所以，情況并不是我所說的某一種方式、某一款軟件是對的，而其它都是錯(cuò)的。但我還是要堅(jiān)持說，批量審查的方式是對的，而其余的都是錯(cuò)的，因?yàn)?strong>單一提交審查系統(tǒng)在鼓勵(lì)一種不良編程習(xí)慣。

　　單一提交審查系統(tǒng)有兩個(gè)最根本的問題：

1. 它在向你暗示各個(gè)修改提交之間沒有關(guān)聯(lián)。經(jīng)常的，每當(dāng)我實(shí)現(xiàn)一個(gè)新功能時(shí)，我都會(huì)有三個(gè)步驟：首先，重構(gòu)現(xiàn)有的代碼，讓代碼整潔，方便添加新功能；接下來，加入新功能；最后，寫單元測試代碼。功能越復(fù)雜，各個(gè)步驟里越有可能各自包含多個(gè)邏輯步驟。如果能將多個(gè)不同的提交放的一個(gè)代碼審查中進(jìn)行，那你就可以簡單的將這些修改分組提交。但如果使用的是單一提交審查系統(tǒng)，那就是在迫使我將所有修改全部完成后進(jìn)行一次全量提交。這樣一來，重構(gòu)的代碼，新添加的代碼，都混在一起，讓人非常不爽，而且在審查過程中需要我付出大量額外的精力來指出各部分代碼都是干嘛的。你也許會(huì)爭辯，說你可以把修改的代碼拆分提交，每一個(gè)提交對應(yīng)一次審查。但事實(shí)上這樣做會(huì)更糟。最好的情況下，你可以把測試程序和新功能代碼分開提交，可以把重構(gòu)代碼和后加代碼分開提交，但真正的問題是，眾多的單一修改審查系統(tǒng)都慫恿對某個(gè)提交在孤立的狀態(tài)下進(jìn)行批準(zhǔn)，這完全會(huì)和你的愿望相反。于是，“一次提交一次審查”的折中就從“麻煩”變成了“危險(xiǎn)”。的確不是一種改進(jìn)。
2. 它在慫恿你隱藏歷史記錄。版本控制系統(tǒng)的最重要的功能就是告訴你代碼演變的歷史、是如何變成今天這個(gè)樣子的。我經(jīng)常會(huì)查看昨天代碼是什么樣的，上周二下午2點(diǎn)代碼是什么樣的，期間發(fā)生了什么變化。很多時(shí)候是因?yàn)槲野l(fā)現(xiàn)代碼以前好用而現(xiàn)在不行，我想知道為什么。而更多時(shí)候，我是想知道為什么會(huì)對代碼做這樣的修改。關(guān)聯(lián)的上下文是什么？動(dòng)機(jī)是什么？如果你總是保持所有代碼一次提交——為了審查，那我就喪失了很多歷史信息：所有我能找到的就是一次完整軟件的一次提交，完全沒有開發(fā)過程中的過程信息。

　　這就是我為什么對Gerrit極度失望的原因。并不是Gerrit是一個(gè)糟糕的軟件，而是他在鼓勵(lì)一種在使用版本控制時(shí)不良的開發(fā)習(xí)慣。這就是為什么所有工具中唯獨(dú)不喜歡它的原因，是唯一讓我對放棄Kiln感到失望的系統(tǒng)。