几年前,我被告知有关代码重用的研究。显然,它发现,平均而言,程序员在搜索要重用的代码时有7分钟的窗口。如果他们没有在该窗口中找到适合他们需求的代码,他们将自行编写代码。您使用哪些技术来最大化代码重用?
这是在需要仔细管理您的代码以供重用以确保您可以在窗口内找到所需内容的情况下提出的。
您(个人和组织)如何管理您的源以便重用? 您是否专门维护重用库?如果是这样,你如何索引它来最大化你的命中率?
几年前,我被告知有关代码重用的研究。显然,它发现,平均而言,程序员在搜索要重用的代码时有7分钟的窗口。如果他们没有在该窗口中找到适合他们需求的代码,他们将自行编写代码。您使用哪些技术来最大化代码重用?
这是在需要仔细管理您的代码以供重用以确保您可以在窗口内找到所需内容的情况下提出的。
您(个人和组织)如何管理您的源以便重用? 您是否专门维护重用库?如果是这样,你如何索引它来最大化你的命中率?
一个复杂的问题:
的代码的某些部分可以被概括为库或API。我们有一个共同的图书馆,能够及时解决常见问题。通常:验证,缓存,数据访问类,日志记录等等。
某些部分是特定于应用程序的。它们不能一概而论。我们将它们转换成HowTos并提供内部演示。代码也可以通过使用易于浏览的SCM(在我们的例子中是SVN)进行回收。
我们也有一些工具可以生成单手无法回收的代码,另一方面它们总是相似的(想想调用存储过程)。
配对编程也是传播现有解决方案知识的有用方法。我们在可能或适当的情况下使用。
最后一个技巧是学费。每个编码器都有一个辅导员来参考。由于导师很少,他们之间有很多共享,这些知识可以自上而下地分散开来。
无情地重构并希望最好。
更新(4年后,希望更聪明)
尝试使用TDD如果您还不是我的初始repsonse。
我认为TDD的使用是一个很好的方式来保持代码耦合低,除其他好处。虽然这固然不会阻止相同的行为被执行两次,但当您确定可以删除重复的区域时,它会更容易。
另一个好处是,TDD作为循环的一部分有一个消除重复(重构)的步骤。
此外,测试形成了您的代码文档的一部分,从而更容易识别重复的行为。
有一个积极支持的框架。
了解现有的代码库/使其他开发人员知道代码库。如果你的团队/公司足够大,有人知道代码库,可以要求指导。
文档,文档,文档。未记录的代码无用于重用,因为它理解其内部运作需要太长的时间。
有良好的接口。简单的类型,简单的结构或类。更复杂的是,它将在另一个项目中使用得越少。
优化和调试可重用代码。在第n次遇到其他人代码错误的开发人员将开始重新编写已有的代码。
组织是关键。如果名称空间和智能感知可用,则可以缩小正确的功能并最终找到。如果他们没有找到他们想要的东西,他们可能会发现一些相近或相关的东西。在一个庞大群体中混合使用的代码很容易找到,但人们永远不会快速找到他们想要的方法。
一致性对命名和位置都很重要。如果您决定在项目中的某个时候改变自己的风格,请返回并更改所有内容以适应该风格。它可能很容易是一个漫长而无聊的过程,但它比尝试使用不一致的库更好。
剖析整个应用程序,并从较重的代码部分开始重构。
使用分析工具具有能力来识别内存泄漏,千呼万唤, 冗长的电话,unfreed内存,未予处置资源等(80%的时间上的最常用的代码20%花在),.
通过规则,新代码总是使用最佳实践。
你(个人和组织)如何管理你的源代码使得 更容易重用?你是否专门维护重用库?如果是这样,你如何索引它来最大化你的命中率?
我不和我在这里有一个公认有争议的观点,但我觉得最大化代码重用适得其反(我解释“最大化”作为优先考虑它上面所有其他的事情,而不是将其视为的想法有利弊平衡考虑)。我宁愿让团队中的大量冗余工作顺利进行,以便更好地解耦和隔离每个开发人员的模块。首先大家才开始跟我不同意左右,我认为我们可以在一些事情上意见不一致:
希望我们至少可以就这些观点达成一致。我发现通过过度热心的同事最大化代码重用的问题是,它经常会导致上述一个或多个问题。代码重用不是直接的热情,而是重要的问题,但优先级偏向于代码重用,而不是测试覆盖率,隔音设计,确保事情足够成熟,然后才能像疯了一样重用它们等等。
当然,如果我们重复使用的所有代码都能够很好地工作,并且具有全面的测试覆盖率,它被证明可以满足所有使用它的需求,这种方式的效率远高于不重用它的效率,而且不需要经过任何多年的设计变更,我会对代码重用感到欣喜若狂。但是我的经验经常发现,在代码重用被认为成为维护问题而不是解决方案的情况下,这种理想远远不能满足这种理想。
你(个人和组织)如何管理你的源代码使得 更容易重用?你是否专门维护重用库?如果是这样,你如何索引它来最大化你的命中率?
因此,我不打算在团队内部编写的专有代码中“最大化”代码重用。我试图确保团队不会花费大量的时间在冗余的工作上,但是如果物理学家和渲染人员都实现他们自己的轴对齐的边界框类,例如,我会让事情滑动很多。这并不一定是多余的,因为物理学家可以使用对他的目的更有效的最小/最大表示,而渲染开发人员可以使用中心/半尺寸表示。我尽量确保尽可能多地重用标准库,因为这是代码重用的一种,实际上可以保证实现稳定,超级测试,并且不需要进一步的设计更改(其他团队正在花费一定的时间的时间来确保这一点)。
相反,我把重点放在测试上。一个模块复制一些代码在这里和那里是完全没问题的,如果你问我是否能够让用户真正开心,有完整的测试覆盖范围,并且不保证无尽的变化。当我们使用第三方库时,我们总是接受这种重复,这些第三方库可能会复制我们在内部代码库中也有的一些代码。当冗余不会导致冗余维护时,这不是问题。
因此,我建议只放宽一点点最大化代码重用的想法。但是,如果您想尽可能简单地重用真正可靠,经过充分测试的非重要代码,那么我发现它更有助于组织非常单一用途的库,如“数学”库, “图像”处理库等 - 而不是试图将它们全部融合到“核心”或“普通”之类的东西中。后一种类型倾向于诱使开发者投入各种折衷的效用函数,这些函数几乎不会让团队使用它们,而且大多数情况下它往往变得杂乱无章,以至于难以找到任何有趣的东西。
重构的东西的好名字。不是它来自哪里,或者它曾经做过什么,或者它目前使用的地方,但它真的是。 – 2008-09-28 13:26:09