代码可重用性：值得吗？

Question

我们都编写可重用的类和代码。

我们考虑到可配置性，允许我们一次又一次地重复使用这个梦幻般的新课程。

我们告诉我们的老板，现在花费这个额外的时间将节省我们的时间和金钱。

但实际上，对于我们这些不编写第三方库的人，并花时间在一个应用程序上进行整体工作，你花费额外时间写一个类来重复使用多少次实际上被重用了在另一个项目？

您的图书馆中有多少个定制课程将在多个项目中使用？

Answer 1

我的常用经验法则是：

1. 如果您重复一次，请将其复制。
2. 如果你重复两遍，重构它。

Answer 2

好问题！
我认为“重复使用设计”是错误的方法。我发现我编写的代码工作，干净和漂亮是可重用的。实际重新使用的设计仅在第一次实际重用代码时发生！

事先花时间尝试重复使用可能会浪费时间，因为你永远不知道需要重复使用的东西。

话虽如此，在我的工作中，我们有一系列库（大型，500MB或更多）可以重复用于几乎每个项目 - 主要是特定于域的东西。

Answer 3

leppie写道：

  

我的常用经验法则是：

     

  
1. 如果您重复一次，请将其复制。
  
2. 如果你重复两次，重构它
  

我想补充一点，请确保在 两个 部分代码中添加注释，以指示在出现错误时重复。你不想把它固定在一个部分而不是另一个部分（BTDTGTT）。

罗布

Answer 4

我不是XP方法（或任何方法）的专家，但我认为YAGNI原则可以在这里应用。

当您 重复使用时，只需修改代码以便重复使用。

Answer 5

恕我直言，某些代码很可能经常被重用，并且为经常重用做好准备是有意义的。其他代码不是，并且可能不需要开发，除了解决当前问题。

当然，要注意区分是NP难的。 ：）

Answer 6

我喜欢LISP模型，您不断扩展语言。最终，您最终会使用针对您的问题域的特定于域的语言。并不是说我实际上是在编写任何lisp，而是在我最常使用的语言中 - 现在是Lua和C--我通常会将某些东西拉出来并重新使用它而不是克隆和修改。

对于C程序员来说，这种方法的典型例子是Dave Hanson的书C Interfaces and Implementations。戴夫在编写三四个编译器时考虑了他所有的可重用的想法，并将它们全部放在一本书中 - 这个软件是免费的。很棒的东西。现在，如果我编写C代码并且我想再次使用它，我会创建一个Hanson风格的界面。我做过这个术语的一些事情：二维数组，带阻塞的二维数组，二维位图，pbmplus文件的读者和编写器等等。有了这个基础设施，很容易编写我多年来一直想要的程序，即删除书页复印件扫描的黑边。

所以我同意任何人说当你想重复使用它时，把它拉出来 - 但不是之前。

Answer 7

可配置性和可重用性之间存在差异 - 前者在许多不同情况下非常有用，当环境发生变化或其他任何事情时 - 以我理解的方式配置事物，主要是分离代码的情况和数据 - 这真的是很好的做法。

如果您正在创建计划用作多个项目的库的内容，那么设计可重用性才非常有用。随着岁月的流逝，我逐渐意识到YAGNI的原理，现在我只是想为手头的任务编写干净而强大的代码。我的经验是，如果要重用某些东西，你就不太可能完全预测如何需要重用，所以最好只添加你现在需要的代码。这样，如果您将来需要重复使用它，您可以添加完全符合您需求的新内容，而不必破坏您过去编写的任何现有功能，试图预测您现在可能需要它。

您可能会发现，在执行此操作后，您有一个稳定且强大的库，并且不需要您更改它，因为它实际上完成了您需要的所有操作 - 对我而言，更容易实现以进化的方式发生而不是浪费太多时间来猜测未来。

Answer 8

我认为最好的方法是尝试设计具有良好接口的代码并在类之间分离责任，而不必过多担心重用。但至少如果你以这种方式设计，你就会打开重用的可能性。一个好的经验法则是问自己“如果我在3个月后回到这个代码，我会理解它吗？如果必须的话我可以扩展它吗？”

IMO是业界最糟糕的做法之一，当团队获得批准并开始编写自己的“可重用”框架时......

Answer 9

一旦达到技术实用程度的水平，我在现实世界中看到的实际重用率很低。

如果你仔细想想，原因很清楚。假设widget_bodger应用程序包含您需要的90％的功能，而不是将缺少的功能添加到应用程序中。

或者说该商家在widget_bodger中羡慕一个非常酷的“嘟嘟”功能，并希望将其整合到gernerate_executive_expenses应用程序中。你可能会认为是麻烦，但是你深入研究代码并发现GEE应用程序是公司中最古老的应用程序之一，用C语言编写，必须在高可用性硬件上运行，唯一可以恢复的是基本算法。

Answer 10

通常“可重用”代码是抽象和模块化的代码，对我而言，主要的好处不是可重用性，而是提高了可测试性。因为当你隔离和模块化代码时，它通常变得更容易测试。重复使用是一种方便但经常未使用的副作用。

另一方面，Juval Lowry提倡基于接口的编程，因为他认为接口是可重用性的唯一组成部分。其他任何东西都隐含了功能（难以重复使用），而接口只定义了一个隐式可重用的契约。

Answer 11

对于什么使代码可重用，存在非常不同的意见。我要说你花时间把代码清楚并且考虑周全（即职责分离）。

这样做的另一个好处是更好的可重用性。主要好处是使代码更易于理解，更改和调试。

包装起来。不要做复杂的配置方案，扩展点和事件，只是为了使它可重用。尝试找到正确的移动部件，以便根据新的需求编写代码。

Answer 12

如果您确定不再需要它，请不要打扰。即使您认为可能派上用场，也不会。当你真的需要它时重构它......

然而，不能使其可重复使用并不是不使其透明的借口。每当我尽可能透明地编写代码时，它总是可以重复使用99％......

Answer 13

SOA失败或尚未解除的原因之一是，重用服务很困难：要么太具体而且不能在别处使用，要么太通用（通常非常复杂的）并不符合不同客户的需求。

这不是“代码重用”，而是“服务重用”，但有一些常见的概念。

Answer 14

我的2c是代码重用的道德需要是公司的事情，而不仅仅是项目的事情。这意味着当你开始一个新项目时，主要关注的是“我可以从哪个其他项目中窃取代码以尽快完成这项工作？”。

这会与“什么是最好的 - 或最潮流的 - 工作的语言/工具”这个问题相冲突？

采用这种方法的公司最终会拥有一个工程师库，可以轻松地从一个项目切换到另一个项目，因为语言，框架和内部代码库都是一致的。

缺点是转换为“新”语言或框架在政治上更加困难，即使它需要在某个时刻发生。

Answer 15

我同意你的意见，因为编码没有任何意义，使得课程在当前应用程序之外易于使用。大多数如果我们不这样做，在商业环境中没有必要。如果其他应用程序在以后需要此功能，则可以在第二个项目中提取和共享代码，管理层可能会同意这一观点。

但是，最好在当前应用程序的约束下使代码可重用。重构您的代码，以避免在您当前的工作范围内重复。通过这种方式，您可以更轻松地在以后使用它。没有那么多的代码可以重用和改变，更改是更常见的。

Answer 16

重用的另一个好处是，您可以轻松跟踪oode基础中发生的事情。如果您有一百万行代码，则可能需要数小时才能找到应用程序以某种方式运行的所有位置。使用现代IDE，您只需单击“查找引用”，您就可以在几秒钟内找到使用组件/方法的所有位置。当您想要添加新功能，修复错误或只想了解系统的工作方式时，这非常有用。

Answer 17

我们有一些，但我们有更多的是具有您想要的功能但以自己的方式完成的项目，因此通常最终会从旧项目中蚕食功能并在新项目中重新实现它们。我认为这仍然很重要 - 您仍然可以获得以前编写代码的好处，并且您仍然可以节省时间。

此外，我发现这是你第二次尝试使用它在可重用性方面显而易见的功能，如果你试图通过推测性地概括一些东西，你几乎总是弄错它并且必须改变它下次。

Answer 18

像其他海报一样，如果您要复制代码然后重复使用，一旦开始调试复制的代码，您会很高兴这样做。