翻译：Branch By Abstraction

teddylw1611616

偶然看到Paul Hammant在2007年4月26日写的一篇文章：http://paulhammant.com/blog/branch_by_abstraction.html。觉得还不错，就翻译了出来。虽然文章的内容并不复杂，翻译过程中仍深深觉得水平有限，好几处翻译得很不理想，请朋友们指正。

Branch By Abstraction

尽管不为人知，但我推行一种叫做Branch by Abstraction的源码控制方法的最佳实践好几个年头了。当对代码进行大规模的改动时，构建很可能失败，甚至得花费数周时间才能重新构建成功。而我说的这种做法能让你把大批开发者拴在同一个主干下工作，而不是产生许多“短期的特性分支”，因为这些分支会一而再、再而三地打断构建过程......

限制条件

需要指出设计单个主干而不是一组主干有一些限制条件，不过这些条件恰恰是敏捷开发所坚持的：

  * 应用程序被分解为多个组件
  * 每个组件在主干中占有一个目录（可能是多级的）
  * 每个目录里的源码是自包含的，可单独构建（可能也是多级的）（译注：这里的多级我理解为组件可以依赖于它的子组件）
  * 有一组很好的单元测试，这对于演示组件的用法非常重要
  * 应用了持续集成，特别是有数百个组件的时候，得把它们放入类似Maven的库中。CruiseControl有个很好的<httpfile/>指示字，与<include-projects/>指示字一起使用的话能完成超酷的CI效果：既能管理好分支又不需要专门的CI管理员（译注：我对CruiseControl没有深入了解，这一条全凭感觉翻译的）
  * 你能做好版本发布的计划与管理
  * 开发者从不愿轻易打断构建过程

主干可能类似下面这个样子：

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/

复制代码

回到问题...

假定，你的团队想把代码从Hibernate移植到iBatis上，而可能有数千个类依赖于Hibernate，该怎么办？架构师可能说这样的改动将让构建中断数周，所以最好新开一个分支。但是，让我们试试Branch by Abstraction（BBA）而不是传统的“Branch by Source Control”（这可是Stacy Curl说的 － 嘿嘿，我得叫他写篇更好的博文）。

实施Branch By Abstraction的步骤

找来负责移植的那帮开发者，然后：

   1. 在要改动的重点代码上增加一个抽象层
   2. 找到原来直接调用将被改动的代码的地方，把这些地方改为通过新的抽象层间接调用（将被改动的代码）
   3. 为抽象层按新的要求重新实现，并编写单元测试来测试新实现的核心功能
   4. 找到第2步骤中提到的那些代码，改为调用新的实现（也是通过新的抽象层间接调用）
   5. 废弃原有实现（如果你觉得代码足够稳定，也可以直接跳到下一步）
   6. 删除原有的实现代码（因为你没不需要回头了）
   7. 如果你觉得增加的那个抽象层不够优雅，就把它去掉

好处

    * 只有一小撮人受到改动的影响
    * 改动到哪个阶段，代码都很健康 － 因为调用这些组件的应用程序总是能照常运行
    * 进度是可管理的
    * 避免了炼狱般的分支合并操作
    * 引入抽象也有助于理解和规范代码 － 这本身就很有意义

当然，BBA不是包治百病的仙丹。它只是一种开发者和架构师都可以常用的实践，让架构师在考虑是否要引入长期的特性分支时少伤脑筋。架构师应该多试试BBA而不是新的特性分支 － 如果架构师在一开始就说新开一个分支是“唯一的途径”，就别想达到目标。（译注：这一段感觉翻译得很有问题，请大家指正）

一个朋友上周告诉我，他的一个客户有21个重要的代码分支，这些分支的合并顺序简直莫名其妙！我吸了一口冷气。当我猜测他们是用ClearCase做SCM时，朋友只是苦笑。无论是ClearCase的动态、静态还是UCM模型，在敏捷开发的实践中都没有立足之地。它象是一个自相矛盾的预言术，需要数十个管理员加数个黑带级合并大师才能玩弄；它只能产生更多分支并导致开发周期拖长、瀑布开发思维及高人才流动率。还有一个更糟的就是PVCS（谁手上还有它？）。如果想找个适合敏捷开发的好工具，应该看看Perforce（我一直最欣赏它的是IntelliJ能很好地与它配合）或Subversion。我想Subversion最快一年内就能超越Perforce了。

那么啥时候新开一个分支呢？

仅仅在发布新版本的时候。

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

复制代码

你可以在发布前新开分支，在这个分支上进行最后的锤炼使产品定型。这时你不能再授权给所有的开发者了，而只能给少数几个开发者，他们保证分支稳定并负责后续的合并（仅限于一、两个必要的合并）。当然，你得从主干分支出来 － 这样才能用CI验证主干总是稳定的。

与Stacy Curl一样，我希望Martin能写篇关于这项重要实践的文章。他的文笔可比我要好。


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