软件配置管理模式

　　BtephenP.Berczuk自1989年以来一直从事面向对象软件应用开发，经常参加地域上分散的小组开发，从1994年首届会议起，一直是“软件模式”社区的活跃成员，很早就对组织、软件体系结构和设计模式之间的关系做过许多研究。他获得了斯坦福大学运筹学硕士学位和麻省理工学院电气工程学士学位。

熟悉我的工作的读者或许会想，为什么搞J2EE软件体系结构的专家竟会为论述软件配置管理（Software Configuration Management，SCM）的书作序。毕竟，这两门学科不能再分开了，难道不是吗？J2EE体系结构似乎高高在上，而SCM也许被视为在软件开发中地位低下。实际上，没有什么比这更背离事实真相了。多年来，我常常发现，那些在J2EE应用体系结构上遇到问题的顾客，通常在SCM上也遇到了严重的问题。这种离奇的巧合，有两层原因。首先，许多人通常很难迅速适应变化：例如放弃一套不再适用于像J2EE这样的新环境的体系结构实践，或者放弃在一种环境行之有效，但未必在所有的环境都行之有效的软件开发过程。这样，他们就会以为，如果他们的SCM过程对前一个项目行之有效，就一定对当前的项目也行之有效：而不顾设计与构造这两个项目所使用的技术、时间框架（timescale）与方法也许完全不同的事实。其次，人们往往想靠一小组简单的规则支配他们的全部行动。然而，采取过于简单的方法通常会在抽象与现实交会的地方遇到问题。无论问题是理解为什么特定的J2EE构造（例如Entity EJB）在一种情况下行之有效，而在另一种情况下却不行；还是理解为什么让开发者有自己的，能在其中进行开发与集成的私用工作区是重要的（毕竟，你迟早得把他们的代码加以集成），问题都是一样的。在这两种情况下，简单的规则（使用Entity Bean；使用构造脚本）的确是好建议，但它必须在经验的熔炉中经受锻炼，因为在未经锻炼之前，它太脆弱，无法应用。通过最近20年关于混沌和复杂性理论的研究，数学家与科学家们开始发现，虽然根据太少的和过于简单的规则构造的系统通常迟钝而单调，但只要增加很少几个规则，便常常可以得到惊人的复杂与美妙的系统。这些系统即使受到外力的严重扰乱，仍能自行重组，使总体构架保持完整。你手里的这本书就提供一组具有这种柔韧性的SCM规则。Steve和Brad提出了把SCM作为模式系统对待的成熟建议。正如他们早些时候有力地揭示的，模式系统的实力不在于各个模式本身，而在于模式之间的关系网。作者开发出模式的连锁网络，覆盖了最常见的SCM实践。然而，更重要的是，他们说明，SCM面临的问题不是任何一个模式可以独自完全解决的：你需要仔细地考虑各个SCM实践与其他实践的联系，以免作茧自缚。例如，你也许想提前看一下他们在第一个模式："主线"（第4章）中给出的绝妙建议...