您使用哪些技术来最大化代码重用？

Question

几年前，我被告知有关代码重用的研究。显然，它发现，平均而言，程序员在搜索要重用的代码时有7分钟的窗口。如果他们没有在该窗口中找到适合他们需求的代码，他们将自行编写代码。

这是在需要仔细管理您的代码以供重用以确保您可以在窗口内找到所需内容的情况下提出的。

您（个人和组织）如何管理您的源以便重用？ 您是否专门维护重用库？如果是这样，你如何索引它来最大化你的命中率？

Answer 1

一个复杂的问题：

• 的代码的某些部分可以被概括为库或API。我们有一个共同的图书馆，能够及时解决常见问题。通常：验证，缓存，数据访问类，日志记录等等。

• 某些部分是特定于应用程序的。它们不能一概而论。我们将它们转换成HowTos并提供内部演示。代码也可以通过使用易于浏览的SCM（在我们的例子中是SVN）进行回收。

• 我们也有一些工具可以生成单手无法回收的代码，另一方面它们总是相似的（想想调用存储过程）。

• 配对编程也是传播现有解决方案知识的有用方法。我们在可能或适当的情况下使用。

• 最后一个技巧是学费。每个编码器都有一个辅导员来参考。由于导师很少，他们之间有很多共享，这些知识可以自上而下地分散开来。

Answer 2

无情地重构并希望最好。

更新（4年后，希望更聪明）

• 像美国洛特的评论说：注意命名。将这个词传播给团队中的所有'提交者'。良好的名字可以让事物进行搜索，从而减少重复。
• 有办法做一些事情，并保持它的可访问性和可搜索性。
• 为平均（L.C.D.）程序员编写代码..不要聪明，只要简单就足够了。 （包括设计模式鞋蹄强迫症和相关障碍）
• 早期采用一套常规，风格，指南，标准等。确保团队内的买入和合规。 （这意味着每个人都使用标签（或空格）！）。选择什么并不重要 - 目标是代码看起来应该一致
• 有一个看门人（由团队尊重），他们会对所有红旗标志进行检查。
• 写代码test-first/outside-in。这通常可以确保您的代码可供多个客户端使用。（关于上下文无关，请参阅GOOS的子弹）

Answer 3

尝试使用TDD如果您还不是我的初始repsonse。

我认为TDD的使用是一个很好的方式来保持代码耦合低，除其他好处。虽然这固然不会阻止相同的行为被执行两次，但当您确定可以删除重复的区域时，它会更容易。

另一个好处是，TDD作为循环的一部分有一个消除重复（重构）的步骤。

此外，测试形成了您的代码文档的一部分，从而更容易识别重复的行为。

Answer 4

• 有一个积极支持的框架。

• 了解现有的代码库/使其他开发人员知道代码库。如果你的团队/公司足够大，有人知道代码库，可以要求指导。

• 文档，文档，文档。未记录的代码无用于重用，因为它理解其内部运作需要太长的时间。

• 有良好的接口。简单的类型，简单的结构或类。更复杂的是，它将在另一个项目中使用得越少。

• 优化和调试可重用代码。在第n次遇到其他人代码错误的开发人员将开始重新编写已有的代码。

Answer 5

组织是关键。如果名称空间和智能感知可用，则可以缩小正确的功能并最终找到。如果他们没有找到他们想要的东西，他们可能会发现一些相近或相关的东西。在一个庞大群体中混合使用的代码很容易找到，但人们永远不会快速找到他们想要的方法。

一致性对命名和位置都很重要。如果您决定在项目中的某个时候改变自己的风格，请返回并更改所有内容以适应该风格。它可能很容易是一个漫长而无聊的过程，但它比尝试使用不一致的库更好。

Answer 6

剖析整个应用程序，并从较重的代码部分开始重构。

使用分析工具具有能力来识别内存泄漏，千呼万唤， 冗长的电话，unfreed内存，未予处置资源等（80％的时间上的最常用的代码20％花在）,.

通过规则，新代码总是使用最佳实践。

Answer 7

你（个人和组织）如何管理你的源代码使得 更容易重用？你是否专门维护重用库？如果是这样，你如何索引它来最大化你的命中率？

我不和我在这里有一个公认有争议的观点，但我觉得最大化代码重用适得其反（我解释“最大化”作为优先考虑它上面所有其他的事情，而不是将其视为的想法有利弊平衡考虑）。我宁愿让团队中的大量冗余工作顺利进行，以便更好地解耦和隔离每个开发人员的模块。首先大家才开始跟我不同意左右，我认为我们可以在一些事情上意见不一致：

1. 重用bug的代码，将有你花了几个小时的调试别人的代码是不可取的。
2. 重复使用代码来平衡如此广泛的不同需求，以至于它几乎不能满足您的需求，并要求您跳过很多环节以最终获得尴尬和低效的解决方案，这是不可取的。
3. 重复使用不断需要设计更改的代码，并且需要每隔6个月重新编写一次代码才能重写代码，这是不受欢迎的，如果您可以在半小时内自行实施解决方案，由于它只能满足您的确切需求，因此未来需要进行设计更改。
4. 一个用外表代码填充的代码库是不可取的，它比使用更多的语言和标准库的惯用和熟悉的方法，即使这需要更多的代码。
5. 开发人员将彼此的脚趾踩在一起，因为他们都希望在同一设计中做出不兼容的变化，同时争吵和争论，以及在彼此的实现中引起错误的变化是不可取的。
6. 将一大堆依赖项投入到尚未经过验证的未成熟设计（没有全面的测试覆盖率，没有时间真正隔音设计并确保其有效满足用户端需求而无需进一步设计更改）是不可取的。
7. 必须使用最复杂的构建脚本来包含/导入/链接一大堆库和类/函数才能写出简单的内容，这是不可取的。
8. 最重要的是，重复使用代码的方式在短期和长期运行中花费的时间远远多于不重复使用的情况，这是不可取的。

希望我们至少可以就这些观点达成一致。我发现通过过度热心的同事最大化代码重用的问题是，它经常会导致上述一个或多个问题。代码重用不是直接的热情，而是重要的问题，但优先级偏向于代码重用，而不是测试覆盖率，隔音设计，确保事情足够成熟，然后才能像疯了一样重用它们等等。

当然，如果我们重复使用的所有代码都能够很好地工作，并且具有全面的测试覆盖率，它被证明可以满足所有使用它的需求，这种方式的效率远高于不重用它的效率，而且不需要经过任何多年的设计变更，我会对代码重用感到欣喜若狂。但是我的经验经常发现，在代码重用被认为成为维护问题而不是解决方案的情况下，这种理想远远不能满足这种理想。

你（个人和组织）如何管理你的源代码使得 更容易重用？你是否专门维护重用库？如果是这样，你如何索引它来最大化你的命中率？

因此，我不打算在团队内部编写的专有代码中“最大化”代码重用。我试图确保团队不会花费大量的时间在冗余的工作上，但是如果物理学家和渲染人员都实现他们自己的轴对齐的边界框类，例如，我会让事情滑动很多。这并不一定是多余的，因为物理学家可以使用对他的目的更有效的最小/最大表示，而渲染开发人员可以使用中心/半尺寸表示。我尽量确保尽可能多地重用标准库，因为这是代码重用的一种，实际上可以保证实现稳定，超级测试，并且不需要进一步的设计更改（其他团队正在花费一定的时间的时间来确保这一点）。

相反，我把重点放在测试上。一个模块复制一些代码在这里和那里是完全没问题的，如果你问我是否能够让用户真正开心，有完整的测试覆盖范围，并且不保证无尽的变化。当我们使用第三方库时，我们总是接受这种重复，这些第三方库可能会复制我们在内部代码库中也有的一些代码。当冗余不会导致冗余维护时，这不是问题。

因此，我建议只放宽一点点最大化代码重用的想法。但是，如果您想尽可能简单地重用真正可靠，经过充分测试的非重要代码，那么我发现它更有助于组织非常单一用途的库，如“数学”库， “图像”处理库等 - 而不是试图将它们全部融合到“核心”或“普通”之类的东西中。后一种类型倾向于诱使开发者投入各种折衷的效用函数，这些函数几乎不会让团队使用它们，而且大多数情况下它往往变得杂乱无章，以至于难以找到任何有趣的东西。