什么代码是重复使用的候选人?

时间:2009-07-14 10:54:34

标签: agile code-reuse

想象一下,你为一家小型精益软件公司工作。您知道公司未来的竞争力在于拥有良好的可重用代码库。管理公司的重复使用政策以确保您今天的交付,同时为未来提供支持,这将是非常重要的。

在我看来,在业务中编写可重用代码有两个原因; 1)在公司内共享以提高未来的速度和效率2)在网络上发布和其他人将有助于改进代码(从某种意义上说是众包)。

开发人员应该始终运用常识来重复使用。但是为了从管理角度处理这个问题,我想要一些整体的代码重用指南,以确保我们现在和将来都具有竞争力。这些指南应鼓励开发人员询问“我的代码是否为重用候选人?”。 这些指南应该说什么?

我最初的想法:在最低级别编写可重用代码是不值得的(例如,我有一些内联代码在字符串的末尾添加“s”),会有太多的这段代码甚至可以筛选并发现有人已经完成了它。在最顶层(即应用程序)编写可重用代码也是不值得的,因为您的客户报告应用程序最终会被通用化为SQL客户端 - 对大多数用户来说是无用的。

可重复使用代码的主要障碍:除非您知道它存在,否则不能重复使用它;信任 - 它已经完成,但你相信吗?使代码通用/可重用(并记录)的初始时间。

7 个答案:

答案 0 :(得分:8)

您可以花很长时间尝试重复使用某些内容,而无需重复使用。因此,我通常遵循这样的格言,即只有在重复使用时才会重复使用(有一些例外情况会突出)。

通常情况下,只有当您重复使用客户所说的“我希望它做同样的事情,除了......”或类似的事情时。只有在这一点上,您才能了解可重用代码的哪一部分是可重用的,以及需要参数化的内容(例如,通过strategy模式或类似方法)

因此,我不倾向于认为代码是可重用的,除非它真的被重用: - )

答案 1 :(得分:4)

我认为更好的想法是永远不要让代码重复使用。

相反,当您发现两段非常相似的代码时,重构它们 - 将公共代码拉出来并保留差异。重新运行单元测试,当它们成功时,您就完成了。

进行了单元测试,对吧?

答案 2 :(得分:2)

在德国,我们说:事实在于中间

你在这里标出了两个极端,但它们是一个好的开始。当你处于低级别时,你将一无所获。您的可重用代码应该值得付出努力。当它做某事时,一个中产阶级程序员可以在3-7行或1-3分钟内实现,它可能不值得,除非它真的,真的经常需要!

另一个极端是通用SQL客户端。当然,重用不应该给用户带来任何负担。这是一个明确的禁忌!

在我看来,你应该考虑你的项目,然后仔细观察,在多种情况下可能需要哪些部分。这些是重用的候选者。但是还有其他因素,你应该在你重复使用代码之前检查候选人:

  • 额外的努力(见下文)是否值得? (3-7衬里!)
  • 是否会给重用者和/或用户带来额外负担?
  • 多久重复使用(估计)
  • 我现在可以决定吗? (你现在可能没有足够的经验 - 然后更好地延迟它并将一些用例作为独立实现,然后才能重复使用)
  • 我能否真正概括所有细节,我可以拥有一个代码行吗?特殊情况可能是重复使用的死亡......

您可能会发现更多因素。我想举一些特别的例子。

我认为,“先思考”是重用的最佳经验法则......当然,重用需要很多经验。

还需要额外的努力:

这是一个非常重要的观点,很多人都忘了。 重用不是免费的!你必须付钱。

您需要支付额外费用:

  • 额外猜测,如何让它真正普及
  • 额外询问所有潜在消费者
  • 额外记录,因为消费者只会使用它,当它真的很容易使用时
  • 广告,因为潜在的消费者必须知道,存在可重复使用的东西,并且值得重复使用。

此外,您必须建立一种重用文化,这并不容易,因为它违背了大量开发人员的努力。所有开发人员都认为只有他们才能找到圣杯,只有他们的代码才是好的。这么多人会被冒犯并拒绝重用代码。抵抗可以是开放的,也可以隐藏给老板(这可能是最糟糕的)。管理层也必须意识到重用。如果没有管理备份,您的公司将无法拥有实质性的重用文化。

所以,附有价格标签。但是,当你真的付出代价时,它是值得的!

答案 3 :(得分:1)

只能使通用代码可重用。只在字符串中附加s last的函数除了已经使用的函数之外没有任何价值,但是一个可以在字符串末尾添加任何一个或多个字符的函数对其他用途也很有用。

基本功能;如果你有自己的列表,树,套接字和/或文件处理的函数和类型,那么所有这些在共享库中都很有用。

此外,您可以评论所有函数和类型,并使用像Doxygen(或Javadoc)这样的系统,然后自动生成文档,这样即使在IDE之外也可以搜索并以一种不太好的方式呈现。

答案 4 :(得分:1)

所有编写良好的代码都是重复使用的候选代码。

如果您花时间使代码通用并记录在案,那么您不仅可以在其他项目中重复使用代码,其他人实际上会查看您的代码。这将大大提高任何人在用户之前发现错误/怪癖的可能性。

最重要的是要在代码应该是一个很好的区别。要把'添加's“带到一个字符串'的例子中 - 这可能是代码放在strings-util库中,同时'添加'h”到字符串'和'添加“b”到一个字符串'的功能。当你看到这三个函数在一起时,你可能会想到一个更通用的“为字符串添加任何字符”函数,从而使代码更加可重用 - 你也可以在字符串中添加字母'r'现在!

您要发现将字符追加到字符串的唯一方法是确保这些函数彼此相邻 - 否则每个人都会在代码中的某处隐藏相同的功能。

这些类型的util集合/类/包含低级代码片段 - 它们是通用的,并且似乎与特定项目没有任何关联。

比例的高端也应被视为可重复使用的代码。比如说你有一个有很好新想法的顾客,比如在网站上添加图片。没有其他人需要这个,所以你继续为这个客户专门添加标签。两周后,你有另一个客户问你完全相同的事情。

在这种情况下经常发生的情况是,您的第一个客户端的额外代码被复制到第二个客户端的项目中 - 只是因为它看起来是最快速的工作方式。实际发生的是,代码的可维护性降低了。您现在在两个地方拥有相同的代码,具有相同的错误。我想我们都知道这会在未来导致问题。

如果该示例是为可重用性而编写的,则可以在第二个项目中再次使用它,从而节省时间和精力。此外,您的下一个客户要求的附加功能可能是您可以提供第一个客户端作为升级 - (请参阅,您现在可以设置高度和宽度,哇!)

至于知道代码存在,这是一个永远存在的问题。我认为传播这些知识的最快方法是确保开发人员不自己开发 - 结对编程就是一个很好的例子。这样,无论什么时候写东西,至少有两个人会知道它。如果你经常混淆对子,知识将通过公司传播而不需要任何额外的努力。

答案 5 :(得分:0)

我会重复使用并不断支持/重构:

  • 完成特定任务的所有库
  • 客户端到特定服务,只要服务没有显着改变
  • 业务层/模型,只要业务案例不被丢弃
  • 网络/桌面界面,只要它仍能很好地发挥其功能

我会扔掉(从scm删除)并从头开始重写:

  • 任何写得不好的图书馆;那些试图完成几项任务而且做得非常糟糕
  • 服务完全重写后使用服务的客户端,使用不同的技术进行更改(使用Web服务更改数据库)
  • 业务层/模型,当它不再提供任何服务时
  • 客户端想要进行重大更改或切换到其他框架时的界面

答案 6 :(得分:0)

我倾向于构建可重用的库,只有当我确定至少在其他时间才需要这个功能时,将代码放入独立库所花费的时间少于花费的时间。重建或复制代码。此外,正在创建的库必须解决一个问题,这使我无法构建范围太广而无法使用的巨大代码球。

最近的一个例子是一个插件,旨在提供应用程序和Protx支付系统之间的接口。我解决了一个问题,到目前为止已经在几个不同的项目中使用过。