翻譯：Branch By Abstraction

teddylw1611616

偶然看到Paul Hammant在2007年4月26日寫(xiě)的一篇文章：http://paulhammant.com/blog/branch_by_abstraction.html。覺(jué)得還不錯(cuò)，就翻譯了出來(lái)。雖然文章的內(nèi)容并不復(fù)雜，翻譯過(guò)程中仍深深覺(jué)得水平有限，好幾處翻譯得很不理想，請(qǐng)朋友們指正。

Branch By Abstraction

盡管不為人知，但我推行一種叫做Branch by Abstraction的源碼控制方法的最佳實(shí)踐好幾個(gè)年頭了。當(dāng)對(duì)代碼進(jìn)行大規(guī)模的改動(dòng)時(shí)，構(gòu)建很可能失敗，甚至得花費(fèi)數(shù)周時(shí)間才能重新構(gòu)建成功。而我說(shuō)的這種做法能讓你把大批開(kāi)發(fā)者拴在同一個(gè)主干下工作，而不是產(chǎn)生許多“短期的特性分支”，因?yàn)檫@些分支會(huì)一而再、再而三地打斷構(gòu)建過(guò)程......

限制條件

需要指出設(shè)計(jì)單個(gè)主干而不是一組主干有一些限制條件，不過(guò)這些條件恰恰是敏捷開(kāi)發(fā)所堅(jiān)持的：

  * 應(yīng)用程序被分解為多個(gè)組件
  * 每個(gè)組件在主干中占有一個(gè)目錄（可能是多級(jí)的）
  * 每個(gè)目錄里的源碼是自包含的，可單獨(dú)構(gòu)建（可能也是多級(jí)的）（譯注：這里的多級(jí)我理解為組件可以依賴于它的子組件）
  * 有一組很好的單元測(cè)試，這對(duì)于演示組件的用法非常重要
  * 應(yīng)用了持續(xù)集成，特別是有數(shù)百個(gè)組件的時(shí)候，得把它們放入類似Maven的庫(kù)中。CruiseControl有個(gè)很好的<httpfile/>指示字，與<include-projects/>指示字一起使用的話能完成超酷的CI效果：既能管理好分支又不需要專門的CI管理員（譯注：我對(duì)CruiseControl沒(méi)有深入了解，這一條全憑感覺(jué)翻譯的）
  * 你能做好版本發(fā)布的計(jì)劃與管理
  * 開(kāi)發(fā)者從不愿輕易打斷構(gòu)建過(guò)程

主干可能類似下面這個(gè)樣子：

1.   <root>
   
2.     trunk/
   
3.       foo-components/
   
4.         foo-api/
   
5.         foo-beans/
   
6.         foo-impl/
   
7.           build.xml
   
8.           src/
   
9.             java/
   
10.             test/
    
11.           cruisecontrol-config-snippet.xml
    
12.         remote-foo/
    
13.       bar-services/
    
14.         bar/
    
15.           build.xml
    
16.           src/
    
17.             java/
    
18.             test/
    
19.           cruisecontrol-config-snippet.xml
    
20.         bar-web-service/

復(fù)制代碼

回到問(wèn)題...

假定，你的團(tuán)隊(duì)想把代碼從Hibernate移植到iBatis上，而可能有數(shù)千個(gè)類依賴于Hibernate，該怎么辦？架構(gòu)師可能說(shuō)這樣的改動(dòng)將讓構(gòu)建中斷數(shù)周，所以最好新開(kāi)一個(gè)分支。但是，讓我們?cè)囋嘊ranch by Abstraction（BBA）而不是傳統(tǒng)的“Branch by Source Control”（這可是Stacy Curl說(shuō)的 － 嘿嘿，我得叫他寫(xiě)篇更好的博文）。

實(shí)施Branch By Abstraction的步驟

找來(lái)負(fù)責(zé)移植的那幫開(kāi)發(fā)者，然后：

   1. 在要改動(dòng)的重點(diǎn)代碼上增加一個(gè)抽象層
   2. 找到原來(lái)直接調(diào)用將被改動(dòng)的代碼的地方，把這些地方改為通過(guò)新的抽象層間接調(diào)用（將被改動(dòng)的代碼）
   3. 為抽象層按新的要求重新實(shí)現(xiàn)，并編寫(xiě)單元測(cè)試來(lái)測(cè)試新實(shí)現(xiàn)的核心功能
   4. 找到第2步驟中提到的那些代碼，改為調(diào)用新的實(shí)現(xiàn)（也是通過(guò)新的抽象層間接調(diào)用）
   5. 廢棄原有實(shí)現(xiàn)（如果你覺(jué)得代碼足夠穩(wěn)定，也可以直接跳到下一步）
   6. 刪除原有的實(shí)現(xiàn)代碼（因?yàn)槟銢](méi)不需要回頭了）
   7. 如果你覺(jué)得增加的那個(gè)抽象層不夠優(yōu)雅，就把它去掉

好處

    * 只有一小撮人受到改動(dòng)的影響
    * 改動(dòng)到哪個(gè)階段，代碼都很健康 － 因?yàn)檎{(diào)用這些組件的應(yīng)用程序總是能照常運(yùn)行
    * 進(jìn)度是可管理的
    * 避免了煉獄般的分支合并操作
    * 引入抽象也有助于理解和規(guī)范代碼 － 這本身就很有意義

當(dāng)然，BBA不是包治百病的仙丹。它只是一種開(kāi)發(fā)者和架構(gòu)師都可以常用的實(shí)踐，讓架構(gòu)師在考慮是否要引入長(zhǎng)期的特性分支時(shí)少傷腦筋。架構(gòu)師應(yīng)該多試試BBA而不是新的特性分支 － 如果架構(gòu)師在一開(kāi)始就說(shuō)新開(kāi)一個(gè)分支是“唯一的途徑”，就別想達(dá)到目標(biāo)。（譯注：這一段感覺(jué)翻譯得很有問(wèn)題，請(qǐng)大家指正）

一個(gè)朋友上周告訴我，他的一個(gè)客戶有21個(gè)重要的代碼分支，這些分支的合并順序簡(jiǎn)直莫名其妙！我吸了一口冷氣。當(dāng)我猜測(cè)他們是用ClearCase做SCM時(shí)，朋友只是苦笑。無(wú)論是ClearCase的動(dòng)態(tài)、靜態(tài)還是UCM模型，在敏捷開(kāi)發(fā)的實(shí)踐中都沒(méi)有立足之地。它象是一個(gè)自相矛盾的預(yù)言術(shù)，需要數(shù)十個(gè)管理員加數(shù)個(gè)黑帶級(jí)合并大師才能玩弄；它只能產(chǎn)生更多分支并導(dǎo)致開(kāi)發(fā)周期拖長(zhǎng)、瀑布開(kāi)發(fā)思維及高人才流動(dòng)率。還有一個(gè)更糟的就是PVCS（誰(shuí)手上還有它？）。如果想找個(gè)適合敏捷開(kāi)發(fā)的好工具，應(yīng)該看看Perforce（我一直最欣賞它的是IntelliJ能很好地與它配合）或Subversion。我想Subversion最快一年內(nèi)就能超越Perforce了。

那么啥時(shí)候新開(kāi)一個(gè)分支呢？

僅僅在發(fā)布新版本的時(shí)候。

1.   <root>
   
2.     trunk/
   
3.     releases/
   
4.       rel-1.0/
   
5.       rel-1.1/
   
6.       rel-1.2.x/

復(fù)制代碼

你可以在發(fā)布前新開(kāi)分支，在這個(gè)分支上進(jìn)行最后的錘煉使產(chǎn)品定型。這時(shí)你不能再授權(quán)給所有的開(kāi)發(fā)者了，而只能給少數(shù)幾個(gè)開(kāi)發(fā)者，他們保證分支穩(wěn)定并負(fù)責(zé)后續(xù)的合并（僅限于一、兩個(gè)必要的合并）。當(dāng)然，你得從主干分支出來(lái) － 這樣才能用CI驗(yàn)證主干總是穩(wěn)定的。

與Stacy Curl一樣，我希望Martin能寫(xiě)篇關(guān)于這項(xiàng)重要實(shí)踐的文章。他的文筆可比我要好。


原文http://www.javaeye.com/topic/215215