构建软件的每个人都会告诉你，实现软件重用极具挑战性。大规模、系统级的重用更是如此。开发人员要在最后期限内满足需求、交付功能，同时还要优先保证重用就非常难了。如果你是团队领导，这个处境只会变本加厉——你必须满足赞助商的需求，在预算内按时交付功能，还要管理开发团队。重用，重用什么？
我参与了几个项目，团队的生产率都非常高，我认识到软件重用是可行的。这并不是说勉强做到重用很容易、有方法可循。抑制重用的一个关键因素是，从组织的政治、文化背景来说缺乏领导力和远见，而且没有与业务赞助商需要的内容相结合。有些重用的尝试以失败而告终，是因为他们太过雄心勃勃了，为了设计完美的内容而花费大量精力去做大规模的先行设计。还有其它一些失败的原因，比如缺乏灵活的设计、规划不充分，或是资金问题。沟通效率和对现有可重用软件资产的了解也是一个关键因素。
本文将根据我从几个项目中总结的经验，介绍一些成功进行系统级重用的小提示。这些提示并非尽善尽美，我只是想让开发人员和团队领导能对各种策略（技术和非技术的）有所理解，从而成功地进行系统级重用。
提示1——关注领域特定的软件资产
业务资产能让你的应用或产品线独树一帜，让你的组织与众不同，最终让你从竞争对手中脱颖而出。开发、发布、迭代改进领域相关软件资产的速度越快，你就越能迅速地满足不断变化的业务需求、让客户满意。如果你只关注于构建可重用的业务资产，那这不仅对业务交付有好处，同时还能在未来的项目中进行重用。
开发人员往往满怀热情地编写技术方案，专注于可重用组件和服务的构建，而解决的问题却在公司内部或开源社区有解决方案。既然你非要这么做，那你就必须尽量避免为已有的解决方案编写新的代码。这不正是软件重用吗？
提示2——正确命名软件资产
无论你是给方法、类、组件、库命名，还是给服务命名，要想取个好名字，首先得想清楚软件的目的和功能。合适的名字可以帮助我们找到已有的可重用软件资产。另外，在重构已有软件资产、使其更容易被重用时，这一点也卓有成效。
当你发现doEverything()这样的方法或类似于SendDataToXYZSystemService的服务时，花点儿时间给它们重新命名。评 估应用的现有功能时，不好的名字常常会花费你更多的时间。如果名字太过愚蠢，你可能就识别不出已有的功能，而去创建一个重复的。
除了继续遵守一般的准则外，好名字还应该与问题领域联系在一起——基于业务功能给软件资产命名是个不错的主意。如果你要将更新的订单内容发布到另一个系统 去，那为什么不用PublishOrderUpdates替代SendDataToABCSystem这个名字呢？资产名称全都简单、清晰、准确时，你会 惊奇地发现这很有利于你重用这些资产。
提示3——不确定它们是否可重用？那就晚点儿再动手
领域中真正有趣的问题是需要经过深思熟虑的，需要与项目利益相关者协作，还需要多次迭代和最终用户的反馈。这一要求对充分进行系统级重用来说是非常宝贵的。如果仅仅因为看起来可重用，那它实际上也许并不可重用……至少目前还不是。考虑一下这些问题：
* 功能在当前项目之外是否真正可重用？
* 将某些内容变为可重用的，是否会给现有的设计带来重大变化？
* 是否理解了功能相关的问题域？
* 随着时间的推移，这个功能会怎样演进？
当你对潜在可重用资产的疑问多于答案时，不要急着概括、增加抽象层次或产品差异性。相反，着眼于那些只针对当前迭代或发布的业务需求和实现。正是因为你可能不清楚未知的内容，所以将想法或功能标记为可重用备选项，但不一定非要使其可重用。
在《软件架构师应该知道的97件事》中，Kevlin Henney在其中一条里提到了“通用之前先简单，重用之前先可用”这个概念。请记住，在项目的整个生命周期中，结合真实用户的反馈进一步理解领域只会对你有所帮助，而不会影响你的目标。
