您使用什么技术来最大化代码重用？

Question

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

这是在需要仔细管理代码以便重复使用以确保您可以在窗口中找到所需内容的背景下提供的。

您（个人和组织）如何管理您的来源以便更轻松地重复使用？ 您是否专门维护重用库？如果是这样，您如何对其进行索引以最大化您的命中率？

Answer 1

一个复杂的问题：

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

• 某些部分是特定于应用程序的。它们不容易概括。我们在HowTos中转换它们并进行内部演示。代码也通过使用易于浏览的SCM（在我们的案例中为SVN）进行回收。

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

• 结对编程也是传播现有解决方案知识的有用方法。我们在可能或适当的时候使用它。

• 最后一种技巧是学费。每个编码员都有一个导师可以参考。由于导师很少，他们之间有很多共享，这种知识可以自上而下的方式传播。

Answer 2

无情地重构并希望最好。

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

• 像S.Lott的评论所说：注意命名。将这个词传播给团队中的所有“提交者”。好名称使事物可以搜索，从而减少重复。
• 有一种做某事的方法，并使其易于访问和搜索。
• 为普通（L.C.D.）程序员编写代码。在简单就行的情况下，不要聪明。 （包括设计模式的鞋子强迫和相关疾病）
• 尽早采用一套通用的约定，风格，指南，标准等。确保买入，从而确保团队内部的合规性。 （这意味着每个人都使用标签（或空格）！）。您选择的内容无关紧要 - 目标是代码应该看起来一致
• 有一个看门人（受到团队的尊重），他们会检查所有签到的红旗。
• 编写代码test-first / outside-in。这通常可确保您的代码可供多个客户端使用。 （参见GOOS关于上下文独立性的子弹）

Answer 3

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

• 了解现有代码库/让其他开发人员了解代码库。如果您的团队/公司足够大，请找一个知道代码库的人，并可以向他们寻求指导。

• 文件，文件，文件。未记录的代码对于重用是没有用的，因为它需要花费太长时间才能理解其内部工作原理。

• 拥有良好的界面。简单的类型，简单的结构或类。事情越复杂，在另一个项目中使用的就越少。

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

Answer 4

如果您不是我最初的回复，请尝试使用TDD。

我认为使用TDD是保持代码耦合度低的好方法，还有其他好处。虽然这本身并不能防止相同的行为被实施两次，但是当您确定可以删除重复的区域时，它会更加容易。

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

此外，测试构成了代码文档的一部分，因此可以更轻松地识别重复行为。

Answer 5

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

在命名和位置方面，一致性也很重要。如果您决定在项目期间的某个时刻更改样式，请返回并更改所有内容以适合该样式。它很容易成为一个非常漫长而枯燥的过程，但它比尝试使用不一致的库更好。

Answer 6

对整个应用程序进行概要分析，并从较重的代码部分开始重构。 （80％的时间花费在20％最常用的代码上）

使用能够识别内存泄漏，重复呼叫， 冗长的电话，不同意的记忆，不受干扰的资源等。

按规则，新代码始终使用最佳实践。

Answer 7

  

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

我没有，我在这里有一个公认的有争议的意见，但我发现最大化代码重用的想法适得其反（我解释＆＃34;最大化＆＃34;优先考虑它优先于其他所有其他事情而不是将其视为兼顾利弊得到平衡。我更愿意让团队中的大量冗余工作倾向于更好地分离和隔离每个开发人员的模块。首先，在每个人开始左右不同意我之前，我认为我们可以就某些事情达成一致：

1. 重复使用错误的代码会花费数小时调试其他人的代码是不可取的。
2. 重用代码来平衡各种各样的不同需求，它几乎不能满足你自己的需求，并要求你跳出很多圈子，最终得到一个尴尬和低效的解决方案是不可取的。
3. 重复使用经常需要进行设计更改的代码，并且要求您每6个月使用一次代码重新编写代码，这是不可取的，如果您可以在半小时内自行实施解决方案，那么就不需要＃＆＃ 39;未来需要进行设计变更，因为它只能满足您的确切需求。
4. 一个充满外星人代码的代码库比那些以惯用和熟悉的方式使用更多语言和标准库的代码是不可取的，即使这需要更多的代码。
5. 开发人员踩到彼此的脚趾，因为他们都希望对同一设计进行不兼容的更改，同时争吵和争论以及在彼此的实现中导致错误的更改是不可取的。
6. 将一大堆依赖项投射到尚未证明自己的不成熟设计上（没有彻底的测试覆盖率，没有时间真正隔离设计并确保它有效地满足用户端需求而不需要进一步的设计更改）是不可取的
7. 使用最复杂的构建脚本包含/导入/链接一大堆库和类/函数来编写简单的东西是不可取的。
8. 最重要的是，重复使用代码的方式在短期和长期都要花费更多时间，而不是重复使用代码。

希望我们至少能就这些问题达成一致。我发现最大限度地利用过度热心的同事重复使用代码的问题是，它经常会导致上述一个或多个问题。直接代码重用的热情并不是根本问题，但是优先级偏向于代码重用而不是测试覆盖，隔音设计，确保事情在我们像疯了一样重用它们之前已经足够成熟，等等

当然，如果我们重复使用的所有代码工作得非常漂亮，具有全面的测试覆盖率，那么它被证明可以满足使用它的所有方面的需求，而这些方式的效率远高于不重复使用它，并且不需要经历多年来任何设计变更，我都会对代码重用感到欣喜若狂。但是我的经验常常发现，在代码重用可能成为维护问题而不是解决方案的方式上，远远没有达到理想状态。

  

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

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

相反，我把重点放在测试上。一个模块在这里重复一点点代码，如果你问我是否能够以令用户真正高兴的方式工作，有完整的测试覆盖率，并且无法保证无休止的变化，那就完全没问题了。当我们使用第三方库时，我们会一直接受这种重复，这些库可能会复制我们内部代码库中的一些代码。当冗余不会导致冗余维护工作时，这不是问题。

所以我建议尽量放松最大化代码重用的想法。但是如果你想尽可能简单地重用真正可靠，经过良好测试的非平凡代码，那么我发现组织非常有用的库更有帮助，比如＆＃34;数学＆＃34;图书馆，＆＃34;图像＆＃34;处理库等 - 而不是试图将它们融合成类似于＆＃34;核心＆＃34;或＆＃34;普通＆＃34;。后一种类型倾向于引诱开发人员投入各种折衷的效用函数，这些函数几乎不利于使用它们的团队，并且大多数情况下它会变得很混乱，因为它开始变得难以找到任何感兴趣的东西。