想象一下，您在一家小型精益软件公司工作。您知道公司未来的竞争力在于拥有一个可重复使用的良好代码库。管理公司的重用政策以确保您今天交付，同时为未来提供支柱，这将非常重要。
在我看来，在业务中编写可重用代码有两个原因；1）在公司内部共享，以提高未来的速度和效率 2）在网络上发布和其他人将有助于改进代码（某种意义上的众包）。
当然，开发人员应该始终应用常识来重用。但是为了从管理的角度来处理这个问题，我想要一些整体的代码重用指南，以确保我们现在和未来都具有竞争力。这些指南应该鼓励开发者问“我的代码是可重用的候选者吗？”。这些指导方针应该说什么？
我最初的想法：在最低级别编写可重用的代码是不值得的（例如，我有一些在字符串末尾添加“'s”的内联代码），这样的代码太多了甚至筛选并发现有人已经这样做了。在最顶层（即应用程序）编写可重用代码也不值得，因为您的客户报告应用程序最终会被通用化为 SQL 客户端——对大多数用户来说毫无用处。
可重用代码的主要障碍：除非你知道它存在，否则你不能重用它；信任——它已经完成了，但你信任它吗？使代码通用/可重用（并记录它）所花费的初始时间。
您可以花很长时间尝试使某些东西可重用，而没有任何人重用它。所以我通常遵循这样的格言，即我只在将要被重用时才制作可重用的东西（有一些例外情况会很突出）。
通常只有当您重用某些东西时，您的客户才会说“我希望它做同样的事情，除了......”或类似的东西。只有在这一点上，您才能了解可重用代码的哪一部分是可重用的，以及需要参数化的内容（例如，通过策略模式或类似方式）
因此我不倾向于认为代码是可重用的，除非它真的被重用了:-)
我认为更好的主意是永远不要让代码可重用。
相反，当你发现两段非常相似的代码时，重构它们——去掉共同的代码，留下不同之处。重新运行你的单元测试，当它们成功时，你就完成了。
你确实有单元测试，对吧？
在德国，我们说：真相在中间
你在这里标记了两个极端，但它们是一个好的开始。当你处于低级时，你将一无所获。您的可重用代码应该值得付出努力。当它做某事时，中级程序员可以在 3-7 行或 1-3 分钟内实现，这可能不值得，除非它真的非常需要经常需要！
另一个极端是通用 SQL 客户端。当然，重用不应该给用户带来任何负担。这是一个明确的禁忌！
在我看来，您应该考虑您的项目，然后仔细观察，在多种情况下可能需要哪些部件。这些是重用的候选对象。但是还有其他因素，在使代码可重用之前，您应该检查候选人：
你可能会发现更多的因素。我想举一些特别的例子。
我认为，“首先思考”是重用的最佳经验法则……当然重用需要很多经验。
它还需要额外的努力：
这是一个非常重要的观点，很多人都忘记了。重用不是免费的！你必须为此付出代价。
您需要支付额外费用：
此外，您还必须建立一种重用文化，这并不容易，因为它违背了许多开发人员的意愿。所有开发人员都认为只有他们找到了圣杯，只有他们的代码才是好的。如此多的人会被冒犯并拒绝重用代码。抵抗可以是公开的，也可以对老板隐藏（这可能是最糟糕的）。管理层也必须意识到重用。如果没有管理备份，您的公司将不会拥有实质性的重用文化。
因此，它附有价格标签。但是，当您设法真正付出代价时，这是值得的！
只使一般代码可重用。仅在字符串中添加 s 结尾的函数将没有价值，除非它已被使用，但可以在字符串末尾添加任何一个或多个字符的函数对于其他用途也很有用。
基本功能；如果您有自己的列表、树、套接字和/或文件处理的函数和类型，那么所有这些都可以在共享库中使用。
此外，您可以评论所有函数和类型，并使用像 Doxygen（或 Javadoc）这样的系统，然后自动生成文档，即使在 IDE 之外也可以搜索并以某种不错的方式呈现。
所有编写良好的代码都可以重用。
如果您花时间使代码通用并记录在案，您不仅可以在另一个项目中重用代码，其他人也会真正查看您的代码。这将大大提高任何人在您的用户之前发现错误/怪癖的可能性。
最主要的是要很好地区分代码应该在哪里。以“向字符串添加“s”为例 - 这可能是与“向字符串添加“h”和“向字符串添加“b”一起放在字符串实用程序库中某处的代码一个字符串的函数。当您将这三个函数放在一起时，您可能会想到制作一个更通用的“将任何字符添加到字符串”函数，从而使代码更具可重用性 - 您还可以将字母“r”添加到字符串现在！
您要发现始终将字符附加到字符串这一事实的唯一方法是确保这些函数彼此相邻 - 否则每个人都会在代码的某处隐藏相同的函数。
这些类型的实用程序集合/类/包含低级代码的任何内容 - 它们是通用的，并且似乎与特定项目没有任何相关性。
规模的高端也应该被视为可重用的代码。例如，假设您的客户有一个很棒的新想法，例如在网站上添加图片。没有其他人需要这个，所以你继续并专门为这个客户添加标签。两周后，您有另一个客户要求您提供完全相同的东西。
在这种情况下通常发生的情况是，您的第一个客户的额外代码被复制到第二个客户的项目中 - 只是因为它看起来是让事情正常运行的最快方式。实际发生的是代码的可维护性降低了。您现在在两个地方拥有相同的代码，具有相同的错误。我想我们都知道这会导致未来出现问题。
如果示例是为了可重用性而编写的，您可以在第二个项目中再次使用它，从而节省时间和精力。此外，您的下一个客户要求的附加功能可能是您可以为第一个客户提供的升级功能 - （看，您现在可以设置高度和宽度，哇哦！）
至于知道代码存在，这是一个永远存在的问题。我认为传播这些知识的最快方式是确保开发人员不会自行开发——结对编程就是一个很好的例子。这样，无论什么时候写东西，至少有两个人会知道它。如果您经常将这对组合在一起，那么知识将在公司中传播而无需任何额外的努力。
我会重用并不断支持/重构：
我会扔掉（从 scm 中删除）并从头开始重写：
只有当我确定至少在其他时间需要该功能并且将代码制作成独立库所花费的时间少于重建或复制所花费的时间时，我才会倾向于构建可重用的库代码。此外，正在创建的库必须解决一个问题，这使我无法构建范围太广而无法使用的巨大代码球。
最近的一个例子是一个插件，旨在提供应用程序和 Protx 支付系统之间的接口。我是解决一个问题的东西，到目前为止已经在几个不同的项目中使用过。