翻译：Branch By Abstraction

偶然看到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没有深入了解，这一条全凭感觉翻译的）
  * 你能做好版本发布的计划与管理
  * 开发者从不愿轻易打断构建过程 :-)

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

  <root>
    trunk/
      foo-components/
        foo-api/
        foo-beans/
        foo-impl/
          build.xml
          src/
            java/
            test/
          cruisecontrol-config-snippet.xml
        remote-foo/
      bar-services/
        bar/
          build.xml
          src/
            java/
            test/
          cruisecontrol-config-snippet.xml
        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了。

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

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

  <root>
    trunk/
    releases/
      rel-1.0/
      rel-1.1/
      rel-1.2.x/

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

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

恩，不过这个BBA好像在实践上还是有些问题，如果那个Abstract设计的不是很好，总是变动的话，大家都很被动，或者Abstract开始不能很好工作的话，那么很多测试都会跑不过

没有人讨论吗?总觉那些乱七八糟的讨论的挺多的，这个怎么就不见人了，还是这个大家觉得都是真理，或者觉得太肤浅不用讨论了。

你提到的这一点与其说与BBA有关，还不如说应该检讨一下团队/架构师在设计方面的问题本身。如果在这种情况下无法设计出很好（或者不错）的抽象层，我想可以合理假定整个系统都未必设计得很好（或不错）。那么团队首先需要改进的不是配置管理，而是团队/架构师的基本技术能力

作者说了，BBA并非万试万灵的，并非真理。我个人觉得，这种做法说不上困难，也不必说它肤浅，关键在于对自己的团队有没有用。如果它能给大家一点启发，能让大家把事情做得更优雅一点，少点麻烦，就不错了！

恩，我只是说，这些都需要建立在这个基础之上的，需要满足一些条件之后，做这个BBA可能会更好一些。

所以代码要依赖于接口，不要依赖于具体类，这样所有代码都可以BBA了。