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