软件重用_有效重用软件的技巧

最新推荐文章于 2021-01-28 19:18:58 发布

cunfu6353

最新推荐文章于 2021-01-28 19:18:58 发布

阅读量1.1k

点赞数 2

文章标签：大数据 python 人工智能 java 编程语言

原文链接：https://www.infoq.com/articles/vijay-narayanan-software-reuse/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

版权

软件重用

任何花时间在组织中构建软件的人都会告诉您，实现软件重用是极具挑战性的。在组织中，大规模，系统的重用甚至更加困难。作为一个有最后期限并具有交付功能的开发人员，将重用作为优先事项是一项挑战。如果您是团队负责人，那么这种情况只会变得更糟-现在您必须满足赞助商的需求，按时并在预算范围内交付功能，并管理开发团队。重用，什么重用？

经过几个项目并成为非常有生产力的团队的一员，我开始意识到软件重用是一个可行的想法。这并不是说很容易，有几种方法可以破坏软件重用。缺乏领导才能和努力使努力在组织的政治和文化背景下运作以及与业务发起人试图达到的目标不一致是关键因素。有些工作失败了，因为它们过于雄心勃勃，需要花费大量的前期设计工作来尝试设计未来完美的东西。还有一些失败的原因是缺乏设计灵活性，规划不足和资金问题。通信效率和对现有可重用软件资产的意识也是一个关键因素。

本文的目的是根据我在各种项目中的经验，介绍一些成功进行系统重用的技巧。这绝不是详尽无遗的，但我的目的是让开发人员和团队领导者理解为使系统重用而成功所必须采取的各种策略-技术策略和非技术策略。

提示1-专注于特定于域的软件资产

商业资产使您的应用程序或产品系列与众不同，使您的组织与众不同，并最终使您从竞争中脱颖而出。您可以更快地开发，发布和迭代地改善与域相关的软件资产，从而更快地满足不断变化的业务需求并使客户满意。如果您仅专注于构建可重复使用的业务资产，则可能与您的业务可交付成果相关并且可用于将来的项目。

开发人员常常热衷于创建技术杰作，着重于为公司内部或开放源代码社区中有解决方案的问题构建可重用的组件和服务。现在，如果必须的话，您必须-但要避免避免生成已经存在解决方案的新代码。那不是什么软件可以重用吗？

技巧2：适当命名软件资产

无论您是要命名方法，类，组件，库还是服务，都请稍等片刻，以真正考虑软件的用途和功能来分配名称。在尝试挖掘要重用的现有软件资产时，合适的名称将为您提供帮助。此外，当您尝试将现有软件资产重构为更可重用时，这项工作将会硕果累累。

每当您遇到诸如doEverything（）之类的方法或服务SendDataToXYZSystemService时，请花一分钟时间适当地重命名它们。不好的名字经常会引起您大量的研究工作，以供您评估应用程序中存在的功能。如果名称过于晦涩，则您可能无法识别已经存在的功能，并建立了重复的功能。

好名显然与您的问题域相关，但一般准则仍然有效-根据业务功能或能力来命名软件资产是一个好主意。如果要将订单更新发布到另一个系统，为什么不调用资产PublishOrderUpdates而不是SendDataToABCSystem？当您以一种简单，清晰且准确的方式命名资产时，您会惊讶于它多久可以帮助您重用它。

提示＃3不确定某些东西可重用吗？延迟承诺

您所在领域中真正有趣的问题将需要大量的思考，与项目涉众的协作，多次迭代以及真正的最终用户反馈。这是使系统重用得以蓬勃发展的主要房地产。但是，仅仅因为某些东西看起来可重用，它可能……至少现在还不是。考虑以下问题：

一项功能真的可以在近期项目之外重用吗？
使某些东西可重复使用会给现有设计带来重大变化吗？
是否了解该功能的相关问题域？
随着时间的流逝，此功能将如何发展？

当您对潜在的可重用资产的疑问多于答案时，请避免泛化的冲动，增加抽象层或产品可变性。相反，请专注于即时业务需求，并满足您的即时迭代或发布需求。将想法或功能标记为可重用的候选对象，但不一定要使它可重复使用，而正是因为您可能不知道所不知道的东西。

Kevlin Henney在“每个软件架构师应该知道的97件事”一书中提到了这个概念，要求“在通用性之前先简单，在重用之前先使用”。请记住，在项目生命周期中额外的域清晰度以及真实的用户反馈将不会损害您的事业。

提示＃4逐步发展可重复使用的资产

当您认识到需要可重用的软件资产时，规划实现策略的关键。如果您要实现资产实现大爆炸，那么最终可能会创建与项目的即时需求无关的软件资产，并且由于增加的设计，开发和测试时间而增加了显着的进度风险。无论哪种方式，您都将花费大量宝贵的资源。

而是通过在多次迭代中发展可重用资产来减轻这些风险。以可重用资产为例，该资产将通知发送给您的用户。让我们将资产命名为Business Notifier 。与其尝试构建该资产可以拥有的100个风吹草动，不如我们想出了一个简单的计划，可以在多次迭代中对其进行改进。

迭代1-通过电子邮件通知预定义的业务事件
迭代2-允许用户从业务事件中选择通知
迭代3-让用户定义自定义业务规则以生成业务事件
迭代4-在Web控制台或即时消息传递应用程序上发送通知
迭代5-允许用户在接收通知时包括他们的朋友。
迭代6-将通知与工作流集成在一起，以供支持人员查看

显然，这只是一个示例，您放入特定迭代中的功能是基于业务需求，优先级，易于实现和其他考虑因素。例如，您可以减少不再优先的资产投资，反之亦然。无论您要构建什么作为可重复使用的资产计划，要解决的都是它在多个迭代中的演进。您将减少风险，对业务需求和需求保持灵活，并仅构建要投资的资产。

提示5：保持一致性比遵循行业标准更为重要

在构建软件组件和服务以在应用程序之间重用时，争取一致性而不是遵守标准更为重要。如果您的大部分应用程序都使用特定的可重用组件，则始终可以将现有接口视为适配器，从而在后台调用行业标准API。但是请注意，我并不是建议您盲目构建已经存在成熟标准的新代码。

这与要重用的横向业务功能特别相关。例如，假设您需要能够从多个应用程序处理信用卡付款，并且在需要此功能时还没有行业标准。重要的是，让您的应用程序使用付款API，而不是等待标准神奇地出现。第二天，如果以及何时出现标准，您可以更改现有实现，而不会影响现有应用程序。好的，也许我过于简化了-您可能需要进行少量代码更改和回归测试。但最重要的是，您将处于一个更好的位置，而不必在整个代码库中更改代码。

提示＃6行为守则审查

代码审查是确保适当使用可重复使用资产的最有效方法之一。通常，在急于将产品推向市场的时候，开发人员可能会放入代码，而无法实现其他地方已经存在的功能。因为审查代码需要时间和纪律，所以最好一小段地进行。关键是一致性而不是大量的代码。您可能需要一种快速的方法来引用存在的可重用资产，并将其与代码更改结合使用。我经常发现自己在进行代码审查的同时也发现了新的可重用资产的想法。随着时间的流逝，您将开始看到跨代码段和应用程序功能的模式和重复，这将有助于实现协同作用。

当您发现重构或创建可重用资产的机会时，请将其与其余应用程序代码分开。在物理上分离源代码并将其作为独立实体进行版本控制。与其他所有操作一样，这需要迭代完成，并且对于产品的初始发行版不是必须的。随着资产的发展和可重复使用，可以将它们重构到自己的存储库中，以便您更好地管理资产。关键是当它们确实可重用时，请将其移出。对它们进行版本控制，并在主要代码之外进行开发，以便更轻松地集成到较新的项目中。

提示＃7切勿在没有一套自动化回归测试的情况下发布可重用的软件资产

如果您要押注可重用的软件资产，然后将其宣传给全世界，则需要对其进行一套回归测试。为什么？如果没有回归测试，当前和潜在的消费者将不会对该资产有足够的信心。重用的根本基础是无需产生已经存在的东西，从而获得更高的质量-减少错误，错误，不正确的需求实现机会。为了确保您能够兑现这一诺言，一整套全面的自动化回归测试必不可少。它不仅对您的直接用户有帮助，而且对以后的每个人都有帮助。

您可以创建可重用的脚本来编译，执行和报告所有单元测试和回归测试。无论您正在构建组件或服务，甚至是业务流程，这都适用。接下来要做的逻辑就是将这些脚本与一个持续集成套件集成在一起。

提示＃8在尝试说服之前了解业务需求

通常诱使开发人员或开发经理说服他们同意重用软件资产。但是，如果您一再说服而又不了解需要，那么业务需求就不太可能取得成果。与其说服您，不如说服他们去倾听，换位思考并真正理解其要求。弄清楚这部分，然后确定可以利用或开发资产。为什么？因为当您真正聆听时，您可能会发现现有资产确实完全满足了需求，或者根本无法满足需求。也许您的可重用服务需要满足一定的性能指标。或者，如果利用现有服务，则会增加计划风险。随你。

关键是您现有资产与当前问题的相关性。 倾听，评估和说服（如果适用）。 按此顺序 。

提示＃9尽可能频繁地共同创建可重复使用的软件资产

系统重用计划失败的原因有多种，包括技术和组织原因。如果没有来自开发组的可重复使用资产的潜在用户，则您的计划将无法成功。我经常听到开发人员和开发经理不想重用或开发可重用功能，因为他们不认为可重用资产的实现不包含这些功能。如何处理这个因素？与其尝试说服，不如共同创造可重复使用的资产。

如果您需要构建电子邮件警报通知需求，请与原始开发团队合作，并让他们参与设计。最好是让他们开发部分或全部功能。如果他们与您共同创建了资产，则他们不会将资产视为被迫使用的黑匣子。您会对此感到惊讶-他们将通过与组织中的合作伙伴共享来帮助您促进重用。

提示＃10从生产支持中获取可重复使用资产的要求

将可重复使用的资产投入生产之前，您应该做的一件事就是与生产支持人员讨论。征求他们的意见，分享您的设计，并尽早获得他们的反馈。这不仅将使您的资产可支持（想象一个无需记录或检测或无需报告关键指标的可重用资产），还将使您成为有价值的合作伙伴。生产支持将很快学会信任您的资产，服务，并要求多个项目利用该功能。出售重复使用对您来说是一回事，而对您的合作伙伴来说，提供语音支持则是另一回事。