【发布时间】：2010-09-13 19:53:00
【问题描述】：
几年前，有人告诉我一项关于代码重用的研究。显然，发现平均而言，程序员在搜索要重用的代码时有 7 分钟的窗口。如果他们在该窗口中找不到适合他们需要的代码，他们就会编写自己的代码。
这是在需要仔细管理代码以供重用以确保您可以在窗口中找到所需内容的背景下提出的。
您（个人和组织）如何管理您的资源以使其更易于重复使用？ 您是否专门维护重用库？如果是这样，你如何索引它以最大化你的命中率？
【问题讨论】：
标签： code-reuse
【发布时间】：2010-09-13 19:53:00
【问题描述】：
一个复杂的问题：
代码的某些部分可以概括为库或 API。我们有一个公共图书馆，它会及时更新常见问题的解决方案。通常：验证、缓存、数据访问类、日志记录等......
某些部分是特定于应用程序的。它们不能轻易概括。我们将它们转换为 HowTos 并进行内部演示。代码也可以通过使用易于浏览的 SCM（在我们的例子中为 SVN）来回收。
我们还有一些工具可以生成一方面无法回收的代码，另一方面它总是相似的（想想调用存储过程）。
结对编程也是传播现有解决方案知识的有用方式。我们会在可能或适当的时候使用它。
最后一个技巧是补习。每个编码员都有一个导师可以参考。由于导师很少，他们之间有很多分享，这些知识可以自上而下的方式传播。
【讨论】：
无情地重构并希望最好。
更新（4 年后，希望更明智）
- 就像 S.Lott 的评论所说：注意命名。将这个词传播给团队中的所有“提交者”。好的名称可以让内容易于搜索，从而减少重复。
- 拥有一种做事的方式，并保持其可访问性和可搜索性。
- 为普通 (L.C.D.) 程序员编写代码。不要在简单就足够的地方变得聪明。 （这包括设计模式的鞋拔强迫症和相关疾病）
- 尽早采用一套通用的约定、样式、指南、标准等。确保团队的认同和合规性。 （这意味着每个人都使用制表符（或空格）！）。选择什么并不重要 - 目标是代码应该看起来一致
- 有一个看门人（受团队尊重），他会密切关注所有签到的红旗。
- 编写代码测试优先/由外而内。这通常可以确保您的代码可供多个客户端使用。 （参见 GOOS 关于上下文独立性的项目符号）
【讨论】：
-
重构内容的好名字。不是它来自哪里，它曾经做什么，也不是它目前在哪里使用，而是它到底是什么。
尝试使用TDD 如果您还不是我的初始回复。
我认为使用 TDD 是保持低代码耦合的好方法，还有其他好处。虽然这本质上不会阻止相同的行为被实施两次，但当您确定可以删除重复的区域时，它会变得容易得多。
另一个好处是，TDD 有一个步骤可以将重复（重构）作为循环的一部分。
此外，测试是代码文档的一部分，因此更容易识别重复行为。
【讨论】：
拥有一个受到积极支持的框架。
了解现有代码库/让其他开发人员了解代码库。如果您的团队/公司足够大，请找一个了解代码库的人，并且可以寻求指导。
文档，文档，文档。未记录的代码无法重复使用，因为它需要很长时间才能理解其内部工作原理。
拥有良好的接口。简单的类型、简单的结构或类。越复杂的东西，在其他项目中使用的越少。
优化和调试可重用代码。第 n 次在其他人的代码中遇到错误的开发人员将开始重新编写已经存在的代码。
【讨论】：
组织是关键。如果命名空间和智能感知可用，则可以缩小范围并最终找到正确的功能。如果他们没有找到他们真正想要的东西，他们可能会找到一些接近或相关的东西。将代码拼凑在一个庞大的组中很容易找到，但人们永远不会足够快地找到他们想要的方法。
一致性也很重要，无论是命名还是位置。如果您决定在项目期间的某个时间点更改您的样式，请返回并更改所有内容以适应该样式。这很容易成为一个非常漫长而无聊的过程，但总比尝试使用不一致的库要好。
【讨论】：
分析整个应用程序并从较重的代码部分开始重构。 （80% 的时间花在 20% 最常用的代码上）
使用能够识别内存泄漏、重复调用、 冗长的调用、未释放的内存、未释放的资源等。
按照规则，新代码总是使用最佳实践。
【讨论】：
您（个人和组织）如何管理您的资源以使 更容易重复使用？您是否专门维护重用库？和 如果是这样，你如何索引它以最大化你的命中率？
我没有，而且我在这里有一个公认的有争议的观点，但我发现最大化代码重用的想法适得其反（我将“最大化”解释为优先考虑它高于所有其他事情，而不是认为它具有两个优点和考虑到平衡的缺点）。相反，我更愿意让团队中大量的冗余工作滑到有利于更好地解耦和隔离每个开发人员的模块。首先，在大家开始左右不同意我之前，我想我们可以在一些事情上达成一致：
- 重用有缺陷的代码会让您花费数小时调试其他人的代码是不可取的。
- 重用代码以平衡如此广泛的不同需求，以至于它几乎不能满足您自己的需求，并且需要您跳过很多圈子才能最终获得一个笨拙且效率低下的解决方案。
- 如果您本可以在半小时内自行实施解决方案，那么重用不断需要更改设计并经历需要每 6 个月重写一次代码的弃用代码是不可取的将来不需要更改设计，因为它只满足您的精确需求。
- 与以惯用和熟悉的方式使用更多语言和标准库的代码库相比，即使这需要稍微多一点的代码，代码库也不受欢迎。
- 由于双方都想对同一设计进行不兼容的更改，同时又发生争执和争吵，以及进行会导致彼此实现出现错误的更改，因此开发人员互相争吵是不可取的。
- 将大量依赖项扔给尚未证明自己的不成熟设计（没有全面的测试覆盖范围，没有时间对设计进行真正的隔音并确保它有效满足用户端需求而不需要进一步的设计更改）是不可取的.
- 必须包含/导入/链接大量库和类/函数以及最复杂的构建脚本来编写简单的东西是不可取的。
- 最重要的是，以一种在短期和长期都比不重用代码花费更多时间的方式重用代码是不可取的。
希望我们至少能在这些观点上达成一致。我从过度热情的同事那里发现最大化代码重用的问题是它经常导致上述一个或多个问题。根本问题并不是对代码重用的热情，而是优先考虑代码重用而不是测试覆盖率、隔音设计、确保在我们疯狂地重用它们之前足够成熟等等。
如果我们重用的所有代码都运行良好、具有全面的测试覆盖率、被证明能够以比不重用更高效的方式满足所有使用它的需求，并且无需经过任何设计，那么自然而然多年的变化，我会对代码重用感到欣喜若狂。但我的经验经常发现，在代码重用可能成为维护问题而非解决方案的情况下，事情远未达到理想状态。
您（个人和组织）如何管理您的资源以使 更容易重复使用？您是否专门维护重用库？和 如果是这样，你如何索引它以最大化你的命中率？
因此，我再次不寻求在团队内部编写的专有代码中“最大化”代码重用。我试图确保团队不会在多余的工作上花费大量时间，但是如果物理学家和渲染人员都实现了他们自己的轴对齐边界框类，例如它甚至不一定是多余的，因为物理学家可能使用对他的目的更有效的最小/最大表示，而渲染开发人员可能使用中心/半尺寸表示。我确实尝试确保我们尽可能多地重用标准库，因为这是一种实际上可以保证可靠、经过严格测试并且不需要进一步的设计更改的代码重用（其他团队正在花费大量时间）他们的时间来确保这一点）。
相反，我将重点转移到测试上。如果您问我它是否以使用户真正满意的方式完美地工作，具有全面的测试覆盖率并且不需要无休止的更改，那么在这里复制一些代码的模块完全没问题。当我们使用可能复制我们内部代码库中的某些代码的第三方库时，我们始终接受这种重复。当冗余不会导致冗余维护工作时，这不是问题。
所以我建议稍微放松一下最大化代码重用的想法。但是，如果您想尽可能轻松地重用真正可靠、经过良好测试、非平凡的代码，那么我发现组织非常单一用途的库会更有帮助，比如“数学”库、 “图像”处理库等——而不是试图将它们全部融合成“核心”或“通用”之类的东西。后一种类型往往会诱使开发人员投入各种不拘一格的实用功能，这些实用功能对使用它们的团队几乎没有好处，而且大多数情况下它往往会变得混乱，开始变得难以找到任何感兴趣的东西。
【讨论】：