偶然看到Paul Hammant在2007年4月26日写的一篇文章：[url]http://paulhammant.com/blog/branch_by_abstraction.html[/url]。觉得还不错，就翻译了出来。虽然文章的内容并不复杂，翻译过程中仍深深觉得水平有限，好几处翻译得很不理想，请朋友们指正。
[size=x-large][b]
Branch By Abstraction[/b][/size]
尽管不为人知，但我推行一种叫做Branch by Abstraction的源码控制方法的最佳实践好几个年头了。当对代码进行大规模的改动时，构建很可能失败，甚至得花费数周时间才能重新构建成功。而我说的这种做法能让你把大批开发者拴在同一个主干下工作，而不是产生许多“短期的特性分支”，因为这些分支会一而再、再而三地打断构建过程......
[size=large][b]限制条件[/b][/size]
需要指出设计单个主干而不是一组主干有一些限制条件，不过这些条件恰恰是敏捷开发所坚持的：
* 应用程序被分解为多个组件
* 每个组件在主干中占有一个目录（可能是多级的）
* 每个目录里的源码是自包含的，可单独构建（可能也是多级的）（译注：这里的多级我理解为组件可以依赖于它的子组件）
* 有一组很好的单元测试，这对于演示组件的用法非常重要
* 应用了持续集成，特别是有数百个组件的时候，得把它们放入类似Maven的库中。CruiseControl有个很好的<httpfile/>指示字，与<include-projects/>指示字一起使用的话能完成超酷的CI效果：既能管理好分支又不需要专门的CI管理员（译注：我对CruiseControl没有深入了解，这一条全凭感觉翻译的）
* 你能做好版本发布的计划与管理
* 开发者从不愿轻易打断构建过程 :-)
主干可能类似下面这个样子：
[code]
<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/
[/code]
[size=large][b]回到问题...[/b][/size]
假定，你的团队想把代码从Hibernate移植到iBatis上，而可能有数千个类依赖于Hibernate，该怎么办？架构师可能说这样的改动将让构建中断数周，所以最好新开一个分支。但是，让我们试试Branch by Abstraction（BBA）而不是传统的“Branch by Source Control”（这可是Stacy Curl说的 － 嘿嘿，我得叫他写篇更好的博文）。
[b]实施Branch By Abstraction的步骤[/b]
找来负责移植的那帮开发者，然后：
1. 在要改动的重点代码上增加一个抽象层
2. 找到原来直接调用将被改动的代码的地方，把这些地方改为通过新的抽象层间接调用（将被改动的代码）
3. 为抽象层按新的要求重新实现，并编写单元测试来测试新实现的核心功能
4. 找到第2步骤中提到的那些代码，改为调用新的实现（也是通过新的抽象层间接调用）
5. 废弃原有实现（如果你觉得代码足够稳定，也可以直接跳到下一步）
6. 删除原有的实现代码（因为你没不需要回头了）
7. 如果你觉得增加的那个抽象层不够优雅，就把它去掉
[b]好处[/b]
* 只有一小撮人受到改动的影响
* 改动到哪个阶段，代码都很健康 － 因为调用这些组件的应用程序总是能照常运行
* 进度是可管理的
* 避免了炼狱般的分支合并操作
* 引入抽象也有助于理解和规范代码 － 这本身就很有意义
当然，BBA不是包治百病的仙丹。它只是一种开发者和架构师都可以常用的实践，让架构师在考虑是否要引入长期的特性分支时少伤脑筋。架构师应该多试试BBA而不是新的特性分支 － 如果架构师在一开始就说新开一个分支是“唯一的途径”，就别想达到目标。（译注：这一段感觉翻译得很有问题，请大家指正）
一个朋友上周告诉我，他的一个客户有21个重要的代码分支，这些分支的合并顺序简直莫名其妙！我吸了一口冷气。当我猜测他们是用ClearCase做SCM时，朋友只是苦笑。无论是ClearCase的动态、静态还是UCM模型，在敏捷开发的实践中都没有立足之地。它象是一个自相矛盾的预言术，需要数十个管理员加数个黑带级合并大师才能玩弄；它只能产生更多分支并导致开发周期拖长、瀑布开发思维及高人才流动率。还有一个更糟的就是PVCS（谁手上还有它？）。如果想找个适合敏捷开发的好工具，应该看看Perforce（我一直最欣赏它的是IntelliJ能很好地与它配合）或Subversion。我想Subversion最快一年内就能超越Perforce了。
[size=large][b]那么啥时候新开一个分支呢？[/b][/size]
仅仅在发布新版本的时候。
[code]
<root>
trunk/
releases/
rel-1.0/
rel-1.1/
rel-1.2.x/
[/code]
你可以在发布前新开分支，在这个分支上进行最后的锤炼使产品定型。这时你不能再授权给所有的开发者了，而只能给少数几个开发者，他们保证分支稳定并负责后续的合并（仅限于一、两个必要的合并）。当然，你得从主干分支出来 － 这样才能用CI验证主干总是稳定的。
与Stacy Curl一样，我希望Martin能写篇关于这项重要实践的文章。他的文笔可比我要好。
[size=x-large][b]
Branch By Abstraction[/b][/size]
尽管不为人知，但我推行一种叫做Branch by Abstraction的源码控制方法的最佳实践好几个年头了。当对代码进行大规模的改动时，构建很可能失败，甚至得花费数周时间才能重新构建成功。而我说的这种做法能让你把大批开发者拴在同一个主干下工作，而不是产生许多“短期的特性分支”，因为这些分支会一而再、再而三地打断构建过程......
[size=large][b]限制条件[/b][/size]
需要指出设计单个主干而不是一组主干有一些限制条件，不过这些条件恰恰是敏捷开发所坚持的：
* 应用程序被分解为多个组件
* 每个组件在主干中占有一个目录（可能是多级的）
* 每个目录里的源码是自包含的，可单独构建（可能也是多级的）（译注：这里的多级我理解为组件可以依赖于它的子组件）
* 有一组很好的单元测试，这对于演示组件的用法非常重要
* 应用了持续集成，特别是有数百个组件的时候，得把它们放入类似Maven的库中。CruiseControl有个很好的<httpfile/>指示字，与<include-projects/>指示字一起使用的话能完成超酷的CI效果：既能管理好分支又不需要专门的CI管理员（译注：我对CruiseControl没有深入了解，这一条全凭感觉翻译的）
* 你能做好版本发布的计划与管理
* 开发者从不愿轻易打断构建过程 :-)
主干可能类似下面这个样子：
[code]
<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/
[/code]
[size=large][b]回到问题...[/b][/size]
假定，你的团队想把代码从Hibernate移植到iBatis上，而可能有数千个类依赖于Hibernate，该怎么办？架构师可能说这样的改动将让构建中断数周，所以最好新开一个分支。但是，让我们试试Branch by Abstraction（BBA）而不是传统的“Branch by Source Control”（这可是Stacy Curl说的 － 嘿嘿，我得叫他写篇更好的博文）。
[b]实施Branch By Abstraction的步骤[/b]
找来负责移植的那帮开发者，然后：
1. 在要改动的重点代码上增加一个抽象层
2. 找到原来直接调用将被改动的代码的地方，把这些地方改为通过新的抽象层间接调用（将被改动的代码）
3. 为抽象层按新的要求重新实现，并编写单元测试来测试新实现的核心功能
4. 找到第2步骤中提到的那些代码，改为调用新的实现（也是通过新的抽象层间接调用）
5. 废弃原有实现（如果你觉得代码足够稳定，也可以直接跳到下一步）
6. 删除原有的实现代码（因为你没不需要回头了）
7. 如果你觉得增加的那个抽象层不够优雅，就把它去掉
[b]好处[/b]
* 只有一小撮人受到改动的影响
* 改动到哪个阶段，代码都很健康 － 因为调用这些组件的应用程序总是能照常运行
* 进度是可管理的
* 避免了炼狱般的分支合并操作
* 引入抽象也有助于理解和规范代码 － 这本身就很有意义
当然，BBA不是包治百病的仙丹。它只是一种开发者和架构师都可以常用的实践，让架构师在考虑是否要引入长期的特性分支时少伤脑筋。架构师应该多试试BBA而不是新的特性分支 － 如果架构师在一开始就说新开一个分支是“唯一的途径”，就别想达到目标。（译注：这一段感觉翻译得很有问题，请大家指正）
一个朋友上周告诉我，他的一个客户有21个重要的代码分支，这些分支的合并顺序简直莫名其妙！我吸了一口冷气。当我猜测他们是用ClearCase做SCM时，朋友只是苦笑。无论是ClearCase的动态、静态还是UCM模型，在敏捷开发的实践中都没有立足之地。它象是一个自相矛盾的预言术，需要数十个管理员加数个黑带级合并大师才能玩弄；它只能产生更多分支并导致开发周期拖长、瀑布开发思维及高人才流动率。还有一个更糟的就是PVCS（谁手上还有它？）。如果想找个适合敏捷开发的好工具，应该看看Perforce（我一直最欣赏它的是IntelliJ能很好地与它配合）或Subversion。我想Subversion最快一年内就能超越Perforce了。
[size=large][b]那么啥时候新开一个分支呢？[/b][/size]
仅仅在发布新版本的时候。
[code]
<root>
trunk/
releases/
rel-1.0/
rel-1.1/
rel-1.2.x/
[/code]
你可以在发布前新开分支，在这个分支上进行最后的锤炼使产品定型。这时你不能再授权给所有的开发者了，而只能给少数几个开发者，他们保证分支稳定并负责后续的合并（仅限于一、两个必要的合并）。当然，你得从主干分支出来 － 这样才能用CI验证主干总是稳定的。
与Stacy Curl一样，我希望Martin能写篇关于这项重要实践的文章。他的文笔可比我要好。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
