软件重用的价值毋庸置疑，在《用敏捷方法进行软件重用》一文中曾指出：软件重用长期以来一直被极力宣扬为可以大量节省时间，也许另一个项目中的人可以重用你的代码，而不用重新开发。但实现软件重用***挑战性，大规模、系统级的重用更是如此。
开发人员要在***期限内满足需求、交付功能，同时还要优先保证重用 就非常难了。如果你是团队领导，这个处境只会变本加厉——你必须满足赞助商的需求，在预算内按时交付功能，还要管理开发团队。重用，重用什么？
#T#笔者参与了几个项目，团队的生产率都非常高，我认识到软件重用是可行的。这并不是说勉强做到重用很容易、有方法可循。抑制重用的一个关键因素是，从组织的政 治、文化背景来说缺乏领导力和远见，而且没有与业务赞助商需要的内容相结合。有些重用的尝试以失败而告终，是因为他们太过雄心勃勃了，为了设计***的内容 而花费大量精力去做大规模的先行设计。还有其它一些失败的原因，比如缺乏灵活的设计、规划不充分，或是资金问题。沟通效率和对现有可重用软件资产的了解也是一个关键因素。
本文将根据我从几个项目中总结的经验，介绍一些成功进行系统级重用的小提示。这些提示并非尽善尽美，我只是想让开发人员和团队领导能对各种策略（技术和非技术的）有所理解，从而成功地进行系统级重用。
提示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——从生产支持人员那里获取可重用资产的需求
将可重用资产投入生产环境之前需要做一件事，就是与生产支持人员沟通。让他们投入进来，分享你的设计，及早并经常获取他们的反馈。这不仅能让资产可被支持 （想象一个没有日志、辅助工具、记录关键指标功能的可重用资产），还能让你拥有一个有价值的的合作伙伴。生产支持人员很快就会信任你的资产和服务，并要求 多个项目都利用这个功能。卖出重用资产是一回事，合作伙伴表示支持又是另一回事。
