基于模式的工程：使用模式成功交付解决方案
《基于模式的工程：使用模式成功交付解决方案》一书是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的核心价值包括以下内容：
- 模式在组合时能够得到最好的应用，而不是单独使用的时候
- 总是要识别并构建新的模式
- 模式可以在同一个项目中构建和使用
- 让你的模式具有生命力
- 关注于创造能够使用的模式
- 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