系统级复用的成功要素

系统级的复用需要人、过程和技术决策之间的相互作用，而且这一切必须在真实环境的约束下进行。是否有成功要素能让复用与众不同吗？我相信有！这篇文章提供的 5 个成功要素会对此有帮助，它们是：捕捉领域差异，易于集成，深入研究设计，高效的团队工作和管理领域的复杂性。

捕捉领域差异

对于系统级复用来说，获取必要的领域变化是非常重要的。业务领域充满了变化，需要通过你的代码库进行定义和管理。如何应对产品线的变化是软件有效复用的核心问题。为了在你的领域内定义这些变化，你需要寻找相关的业务专家以及该领域的终端用户。贴近这些专家和用户，与他们一起工作，你才能更好的了解领域知识、各方面的趋势变化，以及这些变化是如何体现在用户故事中的。从客户的角度看，相对于他们的业务功能来说，这些变化是非常自然的。你不仅要花时间确保了解整体上的变化，同时还要认识到这些变化的子集真正意味着什么。

从务实的角度看软件复用，你会发现去定义某一问题领域的所有变化是不现实的。除非你能引入并把领域变化作为你的开发实践的一部分，否则你的迭代很难进行，工作软件也不会正常发布。从设计的视角来看有些问题能够帮助你。每次你看到用户故事时，你都应该问自己：

1. 会引入哪些领域实体？
2. 是否是第一次遇到这些领域实体？
3. 是否在一个以上的产品或应用系统中用到这个故事？
4. 在故事中业务领域的什么方面发生了变化？一些通用的变化往往会重现──经常使用某个或几个功能的那类用户，一个功能或一组功能的行为差异，有多少功能被绑定在一起作为业务标准，界面隐喻和主题，报表 / 图表功能。
5. 这些用户故事集或用户故事的某些方面是否常常一起出现？

易于集成

系统级复用很容易被忽视的一个方面就是可复用资产的集成，包括应用系统、流程和服务。大多数团队聚焦于构建大型可复用的资产库──服务，对象，框架和领域特定语言库。虽然这是必要的，但对于成功的系统级复用来说，这是远远不够的。一个重要的组成部分就是易于集成。什么意思呢？具体来说就是：

• 评估需求并做决定是否现存的资产能够完全满足需求（或是需要修改），或者需要开发新功能
• 通过集成可复用资产来应对风险（满足服务水平协议（SLAs），解决方案复杂性等）
• 通过有效接口（有 java 接口？还是 web 服务？）来共享信息。
• 提供样例代码和集成设计模式
• 提供全面的错误代码列表和错误处理建议──如果服务出现了特殊错误，用户该怎么办？是否存在需要用户特别注意的业务错误或数据校验错误？
• 确保客户并不缺少可复用资源──基于服务的复用能力是必不可少的，多个用户可以同时调用同一服务。
• 通过测试集成提供帮助（提供测试数据，单元测试代码，以及测试响应时间 / 吞吐量等实用功能）

你可以建立一个服务目录，并寄希望它可以达到很高的复用程度，但大多数情况下你会失望的。伸出手去帮助你的客户，帮助他们成功。让评估、集成和测试变得更加容易。不要着急，但要确保你的团队走在正确的路上，而不是你试图向他们“兜售”复用的价值。

理解设计

构建可复用资产时，并不是只有一条正确的路。你的业务目标、技术环境、迭代和发布计划对设计决策的时间和性质都会造成影响。重构现有代码满足业务目标，也是由上下文环境来驱动的。需要考虑的问题包括：

1. 什么产品功能通常会整合在一起？
2. 与其他那些相对全面的产品比较，是否能做出一些不同的特点？
3. 是否有可能在运行时和设计时改变产品特征？

所有的这些问题都会指导设计。例如，如果设计目标是支持运行时的可变性，你就需要支持在不改变代码或不重启应用的情况下动态增加新的参数。当你进行设计工作时，必须随时考虑相关领域的变化。

举个例子来说，一个小装饰品商店，需要在市场上推广商品。用户故事是根据小装饰品的类型生产不同的市场标签。可能的几个需要支持的变化是：标签信息改变的频率，文字数量，语言，数据格式，组成标签的静态信息和动态信息等。

由于领域的复杂度，一些特性会同时发生变化或单独发生变化。应该考虑这些变化及其对设计的影响：

1. 标签内容仅供静态内容──你可以用一个独立的基于配置文件的标签生成器。
2. 标签内容包括静态内容和动态内容──现在标签生成器需要两个子组件：静态内容生成器和动态内容生成器。
3. 标签内容包括静态内容和动态内容。静态内容是多语言的。──除了内容生成之外，你还需要一个国际化组件支持多语言。
4. 标签内容包括静态内容和动态内容。静态内容是多语言的。还需要根据国家设置不同的日期和货币格式──所有以上三个组件还需要增加本地化的日期格式和货币格式。

下次你开始一个项目时，会更多的了解在你的问题域内由于变化带来的驱动力。你的领域及其相关联的上下文环境会驱动软件资产的复用。你越多的了解这种驱动力，就会越容易决定什么软件资产需要复用以及如何进行复用。

高效的团队工作

与非常有趣而且高效的团队一起工作时，我终于相信复用带来的成功多于技术的光辉和优雅的设计。伟大的团队生产高质量的工作产品，相互理解，包括他们的优势和局限性，最重要的是能够把思想的碰撞与冲突转化为健康的有建设性的对话和创新、创造。

为什么团队工作和系统级复用有关呢？这是因为，在生产可复用资产的过程中会遇到各种问题，包括严格的期限和交付压力，与遗留系统和流程进行集成，与很多跨组织跨地域的部门和团队合作，同时还要发布高质量的产品，在这些情况下进行复用是非常艰难的。这是一种挑战，激励着技术领袖和专家去工作并达成目标。

系统级复用的基本概念是很好理解的，能够把这些达成复用的成功者区别出来的是，他们通过帮助那些水平相对较低的开发团队来实现业务领域复用的愿景，他们具备这样的能力。每件事都很重要，包括每个组件，服务和资产。

特定小组经常相互交流，交换思想，协作变得更加有效，大部分的风险被识别和缓解，这些保证了团队是成功的作为一个整体来工作。听起来是不是很像敏捷宣言？这并不是巧合！构建可复用的服务需要创造性的头脑风暴，解决冲突，设计整合，直到到达一个逻辑点，可以进行你的迭代开发。这可不是一件事──包括迭代，持续关注和聚焦执行。如果你的团队充满了创造力而且能够持续交付，那么系统级复用会自然的成为开发的副产品。

管理领域的复杂度

你的领域可能是复杂的，而且需要支持丰富的变化。考虑到你可能受到的限制，去捕捉全部的复杂性既不现实也不可行。此外，你的业务系统不可能支持相关问题领域的所有变化。幸运的是大部分的领域变化能以用户故事的形式来表述，而且你能从持续的迭代和发布中找到相关模式，更好的了解这些变化。决定管理复杂度的子集是一门艺术，在这一点上你需要不断的与团队的人进行合作。

我使用一套简单策略来寻找那些具有必要业务复杂度的领域。下面的列表并不全面，但是可以帮助你寻找感觉，看看哪些因素能驱动复杂度：

• 数据采集：系统可能有多重用户角色，以及各种数据，对这些用户和数据的验证以及执行的规则都是不同的
• 地理信息：基于地理的区域 / 国家 / 州的变化，包括不同的语言和日期 / 时间格式
• 合并产品特征（也叫捆绑）：支持不同产品偏好的变化（例如基本版支持 X、Y 和 Z 特征；专业版支持 X、Y 和 K 特征；精装版支持 A、X、Y 和 K）
• 授权：访问系统不同功能的变化，并执行不同的任务，以及相关用户群体和交易行为
• 交易行为：货币限制方面交易行为的变化，批准和验证规则，业务异常如何处理
• 渠道（也叫分销渠道或销售渠道）：产品的有效性，特征的有效性，安全，客户支持，频繁的各类市场交流，等等

下次你再去检查用户故事，可以把它放到你的领域策略中去验证。这是迭代中的常用模式么？如果是的话，你应该把它加入到你的系统级复用的规划中。如果在你的设计中并没有从开始就贯彻管理领域复杂度的理念，没关系，不要恐慌。并不需要在着手进行前期设计的时候就努力去管理所有的复杂度。你应该把认识和行动区分开。对相关领域认识的增加会帮助你把系统复用的成果与业务需求和迭代目标结合起来。以此作为重构的指导会帮助你在代码库方面做出明显的改进。

结论

本文阐述了一些成功要素，有助于达成系统级的复用。在没有对问题领域进行管理和有效理解的情况下，去设计可复用资产并作为能够满足业务需求的有用投资，其实是没有意义的。实现高效的团队工作，为客户提供简易的集成方式，这些都可以增加复用成功的可能性。

关于作者

本文作者是资深的软件专业人士，致力于构建可复用的数据服务和业务流程自动化组件。他开发过很多软件项目，项目类型从单用户系统到大型的、分布式、具备多种服务的多用户平台都有涉及。他是即将发布的一本关于 SOA 书籍的贡献作者，他还是敏捷技术的演讲者。他的关于系统软件复用的博客地址是 http://www.artofsoftwarereuse.com/

查看英文原文： Success Factors for Systematic Reuse

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