基于模式的工程：使用模式成功交付解决方案

《基于模式的工程：使用模式成功交付解决方案》一书是Lee Ackerman 和Celso Gonzalez 的著作，该书专注于如何改善识别、创造、管理和使用模式方面的工作，从而使用更少资源更快地交付更好的软件。

InfoQ 对 Lee 和 Celso 进行了关于此书的采访，其中谈到了如何使用模式、模型驱动开发以及如何重用模式等。我们还为读者提供了 Pearson/Addison-Wesley Professional 公司出版的这本书的节选（第九章——PBE 模式简介和指南）。想要获得关于此书更多信息，包括下载PBE 实践以及自动化模式的实例（子系统门户 Subsystem Fa??ade），建议访问 patternsbasedengineering.net 。

InfoQ：你们正在倡导基于模式的工程。对于我们作为软件开发者所做的工作，工程是正确的说法吗？

理想状况下，是那样的。当创建解决方案的时候，我们会对所创建的东西进行思考和分析。我们经过了系统地学习，并且受到了很多训练，期望能够量化我们的选择所造成的影响。但是拥有这样的方法并不意味着前方的路就一片光明。我们每个人都需要找到合适等级的程序，那对于我们所工作的项目和团队都是必要的。

InfoQ：记录模式的格式怎样才“正确”（例如，Full Alexander，设计模式四人组）仍然是有争议的问题。你对模式的描述只是最起码的要求。我们应该对记录模式文档给予多少关注呢？你认为哪种模式文档的模型最有用呢？

我们都非常倾向于实用主义，并且希望在书中、我们用于描述模式的方法以及我们创建的模式中都体现出了这一点。不管我们讨论的是关于代码风格（应该在哪里放置“{”？）、应该使用哪种文本编辑器（vi 还是 emacs？）、那个操作系统更好（Mac OS、Windows 还是 Linux？）， 看起来我们这个行业总是喜欢拥有属于自己的热点讨论。然而，这些讨论经常会把我们的注意力从需要做的重要的问题上引开。

当前在业界，我们还在纠结于通过使用模式所能够达到的表面效果。我们也会努力创建新的模式，而更多的还是在使用现有的模式。此外，在使用模式的时候还没有深入地使用自动化方法。我们喜欢把注意力和工作放在那些更大的问题上，而不是陷入语义方面。是的，我们需要花费时间来编写文档（以及自动化模式），然而，主要的关注点应该在于确保我们能够抓住模式的本质，并为使用模式的人们提供支持。

没有一种系统的规模能够适用所有模式的模板。所以，不管我们选择了什么样的模板，都应该专注于为目标受众来编写，并且要与他们多多沟通。

InfoQ：你们的书并不是关于模式的，而是关于把模式作为一种资产来发现和使用的过程。你所描述的过程会展现它自己的模式吗？是否有某种 PBE 的元模式？如果存在的话，这种模式的价值何在？

在书中我们用了大量的篇幅来讨论一组模式和使用指南，它们都支持基于模式的工程。在 PBE 模式的情况下，它们其实都是元模式——即用来使用模式的模式。 PBE 模式和使用指南为我们识别、设计、创建、打包和使用模式提供了支持。

在我们编写 PBE 模式的时候，还借鉴了其它相关的元模式，像 Meszaros 和 Doble 创建的 Patterns 模式语言。我们希望，也期望这组元模式能够日渐强大。

InfoQ：模式之所以为模式，一条标准就是它能够在多种情境下重复出现。在你们的书中，似乎认为模式可以基于单独一个项目的经验来发现、编写文档并且重用。这明显是种矛盾，你们可否谈一下这个问题呢？

我们认为这并非是一种矛盾。当我们查看一个项目的时候，经常会有对于项目来说独特的情况，但在该项目中多次出现。经过进一步分析，我们可能就会发现针对这种情况最好的实践方法，并且需要在其它项目中继续应用。随着时间的推移，我们会继续寻找可以应用这种模式的情况。随着我们经历更多项目也可能是更多公司，可能就需要对这些模式进行修改和更新。一方面，那很好，如果可应用的范围变得更加广泛，那么我们会发现它可以在整个 IT 业界使用。然而，识别一种模式，然后在项目、组织或者业界来使用它，也具有很大的意义。

此外，每个项目团队自身都有很多历史经验。虽然我们可能会在同一个项目中创建并使用模式，但我们也很可能会在过去碰到过类似的情况，并认为这种模式出现的可能性很大。所以那会在很多情况下都会发生。

InfoQ：模式这个概念已经应用到软件开发的多个不同方面中，你也提到了很多，比方说，编码模式也就是设计模式（GoF）、架构模式、分析模式（Fowler）等等。而这个概念还被应用到团队结构、社会模式、业务模式等等。那么在 PBE 中，这些“非软件工程”的模式扮演的是什么角色呢？

我们明确地让这本书专注于软件开发领域，也就是管理范围的方式。正因为如此，我们想要把这个问题稍作修改：“PBE 在非软件工程情况下扮演的是什么角色？” 我们的期望是，它能够起到很重要的作用，因为模式的应用范围非常广泛。想要在其它领域中应用模式，它的价值就在于它是有体系的、遵守规则的，并且期望量化使用模式的价值和影响。在这样做的时候，我们需要拥有对识别、设计、构建、打包和使用这些模式的支持。

这样说来，那些模式可以与 PBE 模式一起组合使用。我要再一次说明的是，我们使用 PBE 的关注点就在于它是有体系的、遵守规则的，并且能够量化我们使用模式所做的工作。使用的模式可以是 GoF 的设计模式、架构模式、分析模式，或者来自于其它领域的模式。例如，在书中的案例研究中，开发团队遵循的是 Coplien 等人创建的“Conway 原则”模式。敏捷软件开发的组织模式。

InfoQ：你提到，简单的库或者模式的简单罗列并没有相互联系、相互支持的模式那么有用——Alexander 把它叫做模式语言，在你的书中有模式语言吗？

现在我们已经提供了 PBE 模式的列表（以及相关的指南）。在描述模式的时候，我们已经为模式之间的关系编写了文档。对 PBE 实践的使用提供了额外的指引，那和与其他模式的模式关系、执行的任务以及工作流计时（workflow timing）相关。

然而，当跳出元模式的列表之外来查看，并且识别、组织和传播专注于元模式的模式语言的时候，我们发现这个领域需要以后继续研究才能够成熟。

InfoQ：PBE 是模型驱动开发（MDD）的典型示例，这主要是因为它使用了工程学隐喻作为哲学基础。贯穿本书你提到了让 PBE 自动化和使用模式的可能性。你在何种程度上对 MDD 的核心意图进行了分享呢——是创建正式的模型，并且以数学的方式把模型转换为正确可执行的代码吗？

实际上我是从 MDD 的简单定义开始的，在那里我们专注于使用模型来进行抽象——在特定的时间点隐藏不必要的细节。自动化会带了很高的生产力——但是在执行 MDD 的时候那并非是必须的。我们会使用笔和纸、白板，或者简单的软件应用，这些就让我们可以建模。

当使用 PBE 的时候，我们建议并支持使用模式说明以及模式实现。模式说明是正式的、编写出来的文档，就像我们在 GoF 以及其他书中看到的一样。模式实现是在工具中对模式的代码实现和自动化。我们可以使用多种方式和多种工具来完成，只要它们支持创建这样的自动化操作。

创建和使用模式实现的工具正趋于成熟。到目前为止，我们看到的印象最深刻的就是对 Java Emitter 模板的使用（你可以在 Eclipse 中看到）。这个工具简化了我们深入分析样本的工作——那些引用的解决方案可以作为自动操作的基础。在分析样本的时候，JET 简化了创建模式的过程，并且让所有人都能够学习使用。让我们采用模式实现的重要因素在于，它易于使用，并且可以提高交付的速度。

我们也要注意不要存在不合理的期望，希望只需要做一些建模工作，拥有几个模式，然后就可以生成完整的解决方案。现在，这样的想法会导致在模式开发和建模工作中付出过多的投资。最好能够构建一个模式库，使用复合模式，并识别出生成代码的角色，再与用户合作，那样在生成代码之后可以对其进行改善。

InfoQ：在第十七章中提到，PBE 的最基本的好处就在于通过重用来提高效率。重用是面向对象开发做出的郑重承诺。但那并没有成功。为什么基于模式的重用成功的机会更高呢？

对于重用没有成功的想法，我们纠结了很久。我们同意，重用的想法是空头支票，并且过度简化了。然而，我们需要记住，通过使用面向对象的概念和相关的想法（例如：框架、库、组件等等），已经做到了很大程度的重用。

模式不仅仅有助于让我们分享和使用最佳实践，而且会让我们顺利进入下一步，获得粗粒度的解决方案。在进入到下一步的时候，它不会给出很大的组件，而是提供了易于改变的内容，让我们可以在应用到具体环境中时对模式进行自定义。

了解了这一点之后，我们就会看到，模式和面向对象的重用之间最大的区别就在于，模式是对设计的重用，而不是对代码的重用。由于它抽象的层次更高，所以通常模式比代码更易于重用。

最后也是相当重要的就是，我们还需要关注如何使用模式。当前已经有上千种可供重用的模式。然而，在需要的时候我们还是需要付出很大努力才能够找到合适的模式。随着我们寻找模式（根据需求、关系、工作流程）的能力的提高，我们会看到随之而来的重用和投资回报率的提高。

InfoQ：你着重强调对于采用了 PBE 的企业，会获得潜在的经济收益。我们是否可能做出精确的经济上的判断，如“在项目 Y 中使用模式 X 会为公司节省 Q 小时和 R 美元”？或者更一般地，PBE 是否能够被整合到软件经济模型中，就像 Denne 和 Cleland-Huang 在他们的书（《Software by Numbers》）中首次提到的那样？

想要回答这个问题，我们需要强调两点关键的问题。首先，在开发解决方案的时候，我们需要对模式说明和实现对项目的影响负责。这包括使用已经存在的模式，以及那些我们准备构建然后在项目中使用的模式。在很多情况下，都不会对模式和它们的影响进行讨论。很多项目都使用模式——在解决方案的各个层次都会使用，但是他们只认为选择所产生的影响是技术解决方案的一部分。我们需要提升这种讨论的级别。

接下来我们要注意的是，决定我们想要在计算上投入多少。我们需要做到多精确？ 我们能够做到多精确？ 我们需要为计算投入多少时间和工作量？ 我们有多少数据需要在计算中使用？ 准确（或者貌似准确）而不精确是没有价值的。

很多人无法理解遵循敏捷、迭代和递增的方法的影响和重要性。我们可以首先对期望的影响做出估计，但是随着我们不断迭代，在我们的情境中对于影响的模式就会产生数据，我们可以使用这些真实的数据来更新和改进我们的计算。这对于我们在每次迭代的过程中持续寻找使用模式的机会尤其重要。

InfoQ：Alexander 认为模式语言（以及模式）是我们想要真正实践“建筑的永恒之路（Timeless Way of Building）”的必经之路。Kent Beck 在谈及极限编程的时候也说过，在真正实现敏捷之前，必须要超越 XP 的最佳实践。你在书中所展现的 PBE 也只是第一步，需要先照猫画虎，然后调整，最终才能够超越吗？

我们认为，拥有一小组核心的观点非常重要，我们可以很容易记住这些观点并加以执行，然后再提供额外的指引和实践，我们可以使用它们并自定义，从而满足组织的需求。为此目的，在 PBE 中我们提供了三种结构：一组核心价值、一种开发实践以及一组模式和指南。

PBE 的核心价值包括以下内容：

1. 模式在组合时能够得到最好的应用，而不是单独使用的时候
2. 总是要识别并构建新的模式
3. 模式可以在同一个项目中构建和使用
4. 让你的模式具有生命力
5. 关注于创造能够使用的模式
6. PBE 能够适合多种不同的开发过程

然后，我们可以使用 PBE 模式和指引以及相关的 PBE 实践来构建这个基础。我们已经提到了模式和指南，所以我们想花点儿时间来讨论一下 PBE 实践。带有实践的想法是，它是一种开发过程组件。在这个组件中，我们详细描述了与 PBE 相关角色、任务、工作产品、可交付物以及工作流程。我们可以把这个组件整合到其它实践中，像 Scrum 实践或者 XP 实践，并创建能够满足特定项目要求的开发过程。我们已经使用 Eclipse 过程框架设计器（Eclipse Process Framework Composer）创建了这个时间，并使用 Creative Commons 注册了内容的许可。目标是要让人们可以很容易地下载、查看其中的内容，然后对其进行自定义。在自定义工作的末尾，你可以把内容作为一组 HTML 页面发布，这样整个团队都能够访问和参考。

关于书的作者

Lee Ackerman 是在 IBM 工作的一位卓越的 IT 专家， Celso Gonzalez是 IBM Rational 开发团队高级开发人员，他们共同编写了《基于模式的工程：使用模式成功交付解决方案》一书。他们在交付软件解决方案方面都有超过 25 的经验，并且撰写过大量文章，还编写了 IBM 在与模式、MDD 和软件架构和开发相关的红皮书。

节选来自于《基于模式的工程：使用模式成功交付解决方案》一书，该书由 Lee Ackerman 和 Celso Gonzalez 所著，Pearson/Addison-Wesley Professional 在 2010 年 7 月出版（Copyright 2011 Pearson Education, Inc.）。想要了解更多信息请访问此链接。

查看英文原文： Patterns-Based Engineering: Successfully Delivering Solutions via Patterns

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。