建站
咨詢
售后
建站咨詢
新聞中心
有時(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è)組件的。所以，我的工作流程和工作效率一直沒有巨大的變化。
成都創(chuàng)新互聯(lián)自2013年起，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目網(wǎng)站設(shè)計(jì)、網(wǎng)站制作網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢想脫穎而出為使命，1280元鎮(zhèn)遠(yuǎn)做網(wǎng)站,已為上家服務(wù),為鎮(zhèn)遠(yuǎn)各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:18980820575
大概一個(gè)月前，我加入了Knewton公司，整個(gè)技術(shù)架構(gòu)一下子完全變了。Visual Studio換成了IntelliJ；Mortar換成了Jenkins；Mercurial換成了Git；FogBugz換成了JIRA。
也 許你會(huì)覺得這會(huì)讓我頭大，還會(huì)有些不知所措，但事實(shí)上并不是這樣，這些工具的改變并沒有對(duì)我的工作流程產(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公司對(duì)代碼審查非常、非常的看重。這非常好，因?yàn)槲乙彩沁@樣，而且我開發(fā)過整套關(guān)于代碼審查的工具。所以，我的意思絕對(duì)不是反對(duì)代碼審查。
而且，Gerrit的設(shè)計(jì)跟最初的 Kiln 原型的設(shè)計(jì)幾乎完全一致。代碼審查的實(shí)施有兩種基本的方式：pre-merge，是指在代碼進(jìn)入主代碼庫之前進(jìn)行代碼審查。和post-commit， 是指之后審查。新版本的Kiln對(duì)兩種方式都支持，但在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 都加入了“單一提交”審查陣營。所以，情況并不是我所說的某一種方式、某一款軟件是對(duì)的，而其它都是錯(cuò)的。但我還是要堅(jiān)持說，批量審查的方式是對(duì)的，而其 余的都是錯(cuò)的，因?yàn)?strong>單一提交審查系統(tǒng)在鼓勵(lì)一種不良編程習(xí)慣。
單一提交審查系統(tǒng)有兩個(gè)最根本的問題：
- 它在向你暗示各個(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è)提交對(duì)應(yīng)一次審查。但事實(shí)上這樣做會(huì)更 糟。***的情況下，你可以把測試程序和新功能代碼分開提交，可以把重構(gòu)代碼和后加代碼分開提交，但真正的問題是，眾多的單一修改審查系統(tǒng)都慫恿對(duì)某個(gè)提交 在孤立的狀態(tài)下進(jìn)行批準(zhǔn)，這完全會(huì)和你的愿望相反。于是，“一次提交一次審查”的折中就從“麻煩”變成了“危險(xiǎn)”。的確不是一種改進(jìn)。
- 它在慫恿你隱藏歷史記錄。 版本控制系統(tǒng)的最重要的功能就是告訴你代碼演變的歷史、是如何變成今天這個(gè)樣子的。我經(jīng)常會(huì)查看昨天代碼是什么樣的，上周二下午2點(diǎn)代碼是什么樣的，期間 發(fā)生了什么變化。很多時(shí)候是因?yàn)槲野l(fā)現(xiàn)代碼以前好用而現(xiàn)在不行，我想知道為什么。而更多時(shí)候，我是想知道為什么會(huì)對(duì)代碼做這樣的修改。關(guān)聯(lián)的上下文是什 么？動(dòng)機(jī)是什么？如果你總是保持所有代碼一次提交——為了審查，那我就喪失了很多歷史信息：所有我能找到的就是一次完整軟件的一次提交，完全沒有開發(fā)過程 中的過程信息。
這就是我為什么對(duì)Gerrit極度失望的原因。并不是Gerrit是一個(gè)糟糕的軟件，而是他在鼓勵(lì)一種在使用版本控制時(shí)不良的開發(fā)習(xí)慣。這就是為什么所有工具中唯獨(dú)不喜歡它的原因，是唯一讓我對(duì)放棄Kiln感到失望的系統(tǒng)。
文章標(biāo)題：代碼審查和不良編程習(xí)慣
鏈接分享：http://m.5511xx.com/article/cdgegjo.html
