代码重用滥用的代价

奇怪的是，当我正在睡觉或试图进入某种僵尸状态时，我常常觉得在那种状态下的想法是最好的，并且可能解决世界上所有的问题。 但是后来我醒了，试图回忆那些想法并意识到……不，只是拉屎。

但是我想昨天晚上，我受到Udi Dahan不久前读过的博客的启发，在脑海中激起一些有价值的东西，并且思考了一段时间。 09促使我现在考虑一下…）。 综上所述，“代码重用”是许多最近的体系结构样式，软件方法论和“ #bestPractices”的目标。 如果我们仅能“重用”代码，就可以节省开发软件的“成本”，从而可以更快地交付。

实际上，这是胡说八道。

乌迪·达汉（Udi Dahan）曾在很久以前的博客文章中出色地解释了“使用”和“重用”之间的区别 。 他的观点是，“使用”代码属于通用类型：框架，通用实用程序库等。“重用”是特定于领域的：业务逻辑。 此外，交付软件的真正成本在于编写代码以外的事情。 他说

有时我们需要花时间来了解系统应该做什么。 将其乘以需要用户理解系统应该做什么的时间即可：-)然后将该代码与所有其他代码，数据库，配置，Web服务等进行集成。调试。 部署中。 调试。 重新调试。 会议。 等等。

是的 并且他开始了解对“重用”类型的代码的依赖如何昂贵：

可以预料的。 如果将代码全部写在一处，那么就没有依赖关系。 通过重用代码，您已经创建了一个依赖项。 您重复使用的次数越多，依赖项就越多。 依赖关系越多，调试就越多。

是的 使用代码，确保可以。 代码“重用”应该引起人们的注意，并且应该有所回缩。 让我更进一步。

一旦进入微服务世界，每个服务都应拥有其目的，代码，逻辑，实体等（例如思维，自治组件， 有界上下文 ），我们就必须思考“如何减少依赖”而不是“如何减少依赖”。我们分享我编写的所有废话代码。”

我看到的一件事是人们试图使他们的业务逻辑更加“通用”。 哦，那么使用/重用就可以了，对吧？ 这是巨大的错误！ 不要这样！ 业务逻辑应该以非常特定的方式对业务流程进行建模。 如果您试图“通用化”所有内容，那么您现在就会变得模棱两可，丧失了表达/意图，最终导致技术债务急剧增加 ！！！ 更不用说，使事情变得更通用的原因是可重用……因此，现在您已经将此废话散布到了代码/服务/组件/体系结构中。 现在，您的变更成本上升了。 我们试图做的一件事就是减少滑稽动作的改变成本 ！

更不用说，编写通用代码实际上非常困难。 如果您通过编写框架或一些通用代码来启动新项目，那么您做错了，只需要停止即可 。

翻译自: https://www.javacodegeeks.com/2015/03/the-cost-of-code-reuse-abuse.html