构建软件的每个人都会告诉你，实现软件重用极具挑战性。大规模、系统级的重用更是如此。开发人员要在最后期限内满足需求、交付功能，同时还要优先保证重用 就非常难了。如果你是团队领导，这个处境只会变本加厉——你必须满足赞助商的需求，在预算内按时交付功能，还要管理开发团队。重用，重用什么？
我参与了几个项目，团队的生产率都非常高，我认识到软件重用是可行的。这并不是说勉强做到重用很容易、有方法可循。抑制重用的一个关键因素是，从组织的政 治、文化背景来说缺乏领导力和远见，而且没有与业务赞助商需要的内容相结合。有些重用的尝试以失败而告终，是因为他们太过雄心勃勃了，为了设计完美的内容 而花费大量精力去做大规模的先行设计。还有其它一些失败的原因，比如缺乏灵活的设计、规划不充分，或是资金问题。沟通效率和对现有可重用软件资产的了解也是一个关键因素。
本文将根据我从几个项目中总结的经验，介绍一些成功进行系统级重用的小提示。这些提示并非尽善尽美，我只是想让开发人员和团队领导能对各种策略（技术和非技术的）有所理解，从而成功地进行系统级重用。
提示 1——关注领域特定的软件资产
业务资产能让你的应用或产品线独树一帜，让你的组织与众不同，最终让你从竞争对手中脱颖而出。开发、发布、迭代改进领域相关软件资产的速度越快，你就越能迅速地满足不断变化的业务需求、让客户满意。如果你只关注于构建可重用的业务资产，那这不仅对业务交付有好处，同时还能在未来的项目中进行重用。
开发人员往往满怀热情地编写技术方案，专注于可重用组件和服务的构建，而解决的问题却在公司内部或开源社区有解决方案。既然你非要这么做，那你就必须尽量避免为已有的解决方案编写新的代码。这不正是软件重用吗？
提示 2——正确命名软件资产
无论你是给方法、类、组件、库命名，还是给服务命名，要想取个好名字，首先得想清楚软件的目的和功能。合适的名字可以帮助我们找到已有的可重用软件资产。另外，在重构已有软件资产、使其更容易被重用时，这一点也卓有成效。
当你发现doEverything()这样的方法或类似于SendDataToXYZSystemService的服务时，花点儿时间给它们重新命名。评 估应用的现有功能时，不好的名字常常会花费你更多的时间。如果名字太过愚蠢，你可能就识别不出已有的功能，而去创建一个重复的。
除了继续遵守一般的准则外，好名字还应该与问题领域联系在一起——基于业务功能给软件资产命名是个不错的主意。如果你要将更新的订单内容发布到另一个系统 去，那为什么不用PublishOrderUpdates替代SendDataToABCSystem这个名字呢？资产名称全都简单、清晰、准确时，你会 惊奇地发现这很有利于你重用这些资产。
提示 3——不确定它们是否可重用？那就晚点儿再动手
领域中真正有趣的问题是需要经过深思熟虑的，需要与项目利益相关者协作，还需要多次迭代和最终用户的反馈。这一要求对充分进行系统级重用来说是非常宝贵的。如果仅仅因为看起来可重用，那它实际上也许并不可重用……至少目前还不是。考虑一下这些问题：
- 功能在当前项目之外是否真正可重用？
- 将某些内容变为可重用的，是否会给现有的设计带来重大变化？
- 是否理解了功能相关的问题域？
- 随着时间的推移，这个功能会怎样演进？
当你对潜在可重用资产的疑问多于答案时，不要急着概括、增加抽象层次或产品差异性。相反，着眼于那些只针对当前迭代或发布的业务需求和实现。正是因为你可能不清楚未知的内容，所以将想法或功能标记为可重用备选项，但不一定非要使其可重用。
在《软件架构师应该知道的 97 件事》中，Kevlin Henney 在其中一条里提到了“通用之前先简单，重用之前先可用”这个概念。请记住，在项目的整个生命周期中，结合真实用户的反馈进一步理解领域只会对你有所帮助，而不会影响你的目标。
提示 4——迭代演进可重用的资产
当你认识到需要可重用的软件资产时，规划实现战略就很重要了。如果你用大爆炸的方式处理资产实现，那你创建的软件资产最终会脱离项目当前的需求；由于要增加设计、开发和测试的时间，显然还会拖延进度。无论哪种方式，你都要花费大量宝贵的资源。
相反，可以通过多次迭代来演进可重用的资产，从而减轻这些风险。举一个可重用资产的例子——给用户发通知。我们将该资产命名为Business Notifier。我们提出一个简单的计划——通过数次迭代来逐步实现该资产的一百个附属功能，而不是一下子就创建出来。
迭代 1：用电子邮件通知用户预定的业务事件
迭代 2：允许用户选择，只接收某些业务事件的通知
迭代 3：让用户自定义业务规则，继而生成业务事件
迭代 4：通过 Web 控制台或即时消息应用发送通知
迭代 5：能让用户邀请朋友一起接收通知
迭代 6：将通知和工作流结合起来，让支持人员进行审查
这显然只是个范例，在特定迭代中加入的功能往往要基于业务需求、优先级、实现的难易程度和其它因素。比如不再优先处理资产时，你可以减少投资，反之亦然。 不论构建为可重用资产的内容是什么，都要在多个迭代中规划其发展演进。这样，你就可以减少风险，保持对业务需求的灵活性，还能只创建那些你愿意投资的资 产。
提示 5——保持一致性要比遵循行业标准更为重要
跨应用创建可重用的软件组件和服务时，力争保持一致性要比符合标准更为重要。如果大量应用程序都使用了特定的可重用组件，那你就可以跟往常一样，将现有接 口作为适配器，让它在后台调用行业标准的 API。不过要注意，我并不是建议你盲目地为那些已经有成熟标准的内容创建新代码。
这与要重用的水平业务能力相关。比如说，你在多个应用程序中都需要处理信用卡付款的功能，而在此时又没有行业标准。创建应用可利用的支付 API 就很重要， 而不是等待标准奇迹般地出现。第二天，如果出现了一个标准，你可以修改现有的实现，这不会对你当前的应用有任何影响。好吧，也许我说得太过轻松了——你可 能需要细微的代码修改和回归测试。但最起码你的处境会比较好，不用修改代码库中的代码。
提示 6——进行代码审查
代码审查能最有效地保证可重用资产被 正确使用。大多数时候，为了赶紧发布产品，开发人员提交代码时并不了解其它地方已经实现了的功能。由于审查代码要花费时间、遵循规则，所以在小规模内这样 做的确是个好主意。关键之所在与其说是代码质量，还不如说是一致性。你可能期望能有一个快速的方法指出哪些资产可重用，将其与代码中的变化相结合。我在代 码审查时经常会找出新的可重用资产。随着时间的推移，你会看到多个代码片段和应用功能中存在的模式和重复的代码，这对起到增效作用很有帮助。
当你看到重构或创建可重用资产的机会时，不要把这些工作跟应用代码的剩余部分掺杂在一起。将它们从源码和版本控制中分离出来，作为一个独立的实体。和其它 内容一样，这也需要迭代地来完成，也不必在产品的最初版本中就有。随着资产演进、变得可重用，可以重构、把它们放到它们自己的仓库中，以便更好地管理。主 要问题是在它们可重用时把它们移出来。在主干代码之外对它们进行版本化和演进，以便更容易地在新项目中集成。
提示 7——没有自动化的回归测试套件，就不要发布可重用的软件资产
如果你要在可重用软件资产上押宝，把它推广到全世界，那你必须要有一套回归测试套件。为什么呢？没有回归测试，现有和潜在的消费者对资产就没有足够的信 心。重用的基础就是不用再次实现已有的内容，从而获得更好的质量——较少的错误、Bug、不对的需求实现。为了确保能兑现这一承诺，你必须得有完整的自动 化回归测试套件。这不仅有利于当前的消费者，对以后的任何消费者也是有用的。
你可以创建可重用的脚本，完成编译、执行、单元测试和回归测试的报告。无论你构建的是组件还是服务，甚至是业务流程，这都是适用的。下一步合乎逻辑的事情就是把这些脚本集成到持续集成套件中去。
提示 8——理解业务需求之后再去说服别人
大家总想说服开发人员或开发经理能同意重用软件资产。但如果你还没理解业务需求就一再地去劝说，成功的可能性并不大。不要试图去说服，而是倾听、体 会、真正理解需求。弄清楚业务需求，然后确定能被利用或开发的资产。为什么要这么做呢？因为当你真正去听的时候，你可能会发现现有的资产能完全满足需求，或者根本不能满足需求。也许可重用的服务还需要满足某个性能指标。或者利用现有的服务会增加进度风险。诸如此类。
关键是现有的资产要适用于眼前的问题。倾听，评估，如果合适就说服——一定要遵循这个顺序。
提示 9——尽可能与开发团队一起创建可重用的软件资产
提倡系统级重用失败的原因各种各样，其中包括技术和组织方面的原因。 开发团队是可重用资产的潜在用户，如果没有来自开发团队的支持，你的计划就不可能取得成功。我经常听到开发人员对开发经理说，不想重用，也不想开发可重用 的功能，因为他们觉得实现可重用资产与他们无关。如何解决这个问题呢？不要试图去说服他们，而是和他们共同创建可重用的资产。
如果有个需求是通过电子邮件发送通知，那就和原来的开发团队合作，让他们参与设计。更好的办法是让他们开发部分或全部的功能。如果他们和你联合创建了该资 产，他们就不会觉得这个资产是强迫他们使用的黑盒子了。他们会在组织里和他们的合作伙伴分享该资产，从而帮助你促进重用——你会对此感到惊讶的。
提示 10——从生产支持人员那里获取可重用资产的需求
将可重用资产投入生产环境之前需要做一件事，就是与生产支持人员沟通。让他们投入进来，分享你的设计，及早并经常获取他们的反馈。这不仅能让资产可被支持 （想象一个没有日志、辅助工具、记录关键指标功能的可重用资产），还能让你拥有一个有价值的的合作伙伴。生产支持人员很快就会信任你的资产和服务，并要求 多个项目都利用这个功能。卖出重用资产是一回事，合作伙伴表示支持又是另一回事。
结论
技术实践、协作和务实相结合，可以慢慢扩充你的可重用资产库。本文介绍的这些小提示都是我在日常工作中为了提高成功率而反复使用的。我非常想听听你在促进有效软件重用时总结出的经验，无论它们是否有效。
查看英文原文： Tips for Effective Software Reuse 。
感谢张龙对本文的审校。
给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
评论