软件配置管理模式

　　熟悉我的工作的读者或许会想，为什么搞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章）中给出的绝妙建议。这个貌似平凡的建议（开发者应在单一、稳定的码基上工作）正是我发现被许多组织：包括那些在实现过程中已经花费了数百万美元的大型的、成功的公司：在某种程度上忽略了的东西。这是常识，非常实用的常识，而这正是它的难得之处。同样，在"私用工作区"（第6章）和"私用系统构造"（第8章）中给出的建议，简直和使得现代的Java集成开发环境（例如VisualAge for Java和IBM的WebSphere Studio）如此有用和如此流行的两个关键思想一模一样。当有人问我（差不多每天有人问），为什么开发者应当选择这样的集成开发环境，而不是用传统的代码编辑程序和编译程序在命令行进行开发时，这些工具不仅允许而且积极鼓励这种开发风格的事实，是使我能够用简单的措词表达我的建议的关键因素。所以，我相信，你会像我一样发现本书有用，有启发。自从几年前，这些模式首次在程序模式语言（Pattern Languages of Programs，PLoP）会议上发表以来，我已经向人们介绍过本书的一些模式，而且我发现，它们对构筑坦诚的、有建设性的、关于如何以正确的方式实施SCM的论坛是无价之宝。这些模式已经在解决需要靠技巧与智谋来慎重处理的对顾客的承诺时，成为我劈开复杂的SCM问题的戈尔迪结的利剑：我希望，你也能很快开始挥舞这把利剑。：Kyle Brown《Enterprise Java Programming with IBM WebSphere》的作者

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