你如何使代码可重用？

Question

任何代码都可以以某种方式重用，至少在您修改代码时是这样。随机代码不是那么可重复使用。当我阅读一些书籍时，他们通常会说你应该通过考虑其他代码使用情况来明确地使代码可重用。但是某些代码也不应该是一个无所不能的所有人都在上课。

我想拥有可重复使用的代码，以后我无需更改。你如何使代码可重用？代码可重用的要求是什么？可重用代码应该具有哪些东西以及哪些东西是可选的？

Answer 1

请参阅10 tips on writing reusable code获取一些帮助。

1. 保持代码DRY。干意味着“不要重复自己”。
2. 让一个类/方法做一件事。
3. 为您的课程编写单元测试，并使测试课程变得容易。
4. 从任何框架代码中删除业务逻辑或主代码
5. 尝试更抽象地思考并使用Interfaces和Abstract类。
6. 扩展代码。编写可以在将来轻松扩展的代码。
7. 不要编写不需要的代码。
8. 尽量减少耦合。
9. 更多模块化
10. 像代码一样编写代码是外部API

Answer 2

如果您采用测试驱动开发方法，那么您的代码只能根据即将出现的方案重新用作重构。

就我个人而言，我发现不断重构会产生更清晰的代码，而不是试图猜测我需要为特定类编码的场景。

Answer 3

最重要的是，可维护性使代码可以重复使用。

可重用性本身很少是一个有价值的目标。相反，它是编写代码结构良好，易于维护和有用的副产品。

如果您打算制作可重复使用的代码，您经常会发现自己试图考虑未来项目可能需要的行为要求。无论你在这方面有多好，你都会发现这些未来的要求是错误的。

另一方面，如果您从当前项目的基本要求开始，您会发现您的代码可以干净，紧凑和优雅。当您正在处理需要类似功能的另一个项目时，您将自然地调整原始代码。

我建议您查看所选编程语言/范例的最佳实践（例如，Java / C＃类型的模式和SOLID），精益/敏捷编程文献，以及（当然）“代码完成”一书。了解这些方法的优缺点将不断改进您的编码实践。然后，您的所有代码都将变为可重复 - 但“偶然”，而不是设计。

另请参阅此处：Writing Maintainable Code

Answer 4

对于“重用”的大多数定义，重用代码是一个神话，至少在我的经验中。你能告诉我有一些伤疤吗？ :-)

通过重用，我并不是指在新的组件或服务失败之前接受现有的源文件并将其击败。我的意思是采取特定的组件或服务，并重复使用它。

我认为第一步是让自己陷入一种思维模式，即至少需要3次迭代才能创建可重用的组件。为什么3？因为第一次尝试重用组件时，总会发现无法处理的内容。那么你必须改变它。这种情况发生了几次，直到最后你有一个至少看起来可以重复使用的组件。

另一种方法是进行昂贵的前瞻性设计。但随后费用全部都在前期，并且好处（可能）会在未来一段时间内出现。如果你的老板坚持认为当前的项目时间表总是占主导地位，那么这种方法将不起作用。

Answer 5

在编写一个相对较大的项目时，您将编写各种模块（部件）。实践中可重用的代码意味着您将创建需要相同功能的其他项目可以使用的库。

因此，您必须确定可以重复使用的模块

1. 确定每个模块的核心竞争力。例如，如果您的项目必须压缩文件，您将拥有一个将处理文件压缩的​​模块。 不让它做的不仅仅是 ONE THING 。只有一件事。

2. 编写一个将处理文件压缩的​​库（或类），而不需要压缩文件，输出和压缩格式。这将使模块与项目的其余部分分离，使其能够（重新）在不同的设置中使用。

3. 第一次没有必要完美，当你真正重用库时，你可能会发现设计中存在缺陷（例如，你没有使模块足够模块化以便能够轻松添加新的压缩格式），您可以第二次修复它们并提高模块的可重用性。您重复使用它（并修复缺陷）越多，重用就越容易。

最重要的是要考虑解耦，如果你编写紧密耦合的代码可重用性是第一个牺牲品。

将所有必需的状态或上下文保留在库外。添加方法以指定库的状态。

Answer 6

面向对象允许您将代码重构为超类。这可能是最简单，最便宜和最有效的重用方式。普通的阶级继承不需要考虑“其他情况”;你不必建立“无所不能”的代码。

除了简单的继承之外，重用是你发现的东西而不是你发明的东西。当您想要重用一个自己的包来解决稍微不同的问题时，您会发现重用情况。如果要重用不适合新情况的包，则有两种选择。

1. 复制并修复它。你现在需要几乎相似的包 - 这是一个代价高昂的错误。

2. 在两种情况下使原始包可重复使用。

只需重复使用即可。而已。过多地考虑“潜在的”重用和未定义的“其他情况”可能会浪费时间。

Answer 7

其他人已经提到过这些策略，但在这里它们是正式的。这三个会让你走得很远：

• 坚持Single Responsibility Principle - 它确保您的课程“只做一件事”，这意味着它更有可能重复使用包含同样内容的其他应用程序。
• 坚持Liskov Substitution Principle - 它可以确保您的代码“毫无意外地执行所谓的操作”，这意味着它更有可能重新用于需要完成相同操作的其他应用程序。
• 坚持Open/Closed Principle - 它确保您的代码可以在不修改其来源的情况下以不同的方式运行，这意味着在没有直接修改的情况下，它更有可能重复使用。

Answer 8

要添加上述项目，我会说：

• 使那些需要重用的功能通用
• 使用配置文件并使代码使用files / db
中定义的属性
• 明确地将您的代码分解为这些功能/类，这些功能/类提供独立的功能，可以在不同的场景中使用，并使用配置文件定义这些场景

Answer 9

我会添加“类组合超类继承”的概念（这是从其他答案派生而来的）。 这样，“组合”对象不关心它所依赖的对象的内部结构 - 只关注它的行为，这导致更好的封装和更易于维护（测试，关注的细节更少）。 在C＃和Java等语言中，它通常是至关重要的，因为没有多重继承，所以它有助于避免你可能拥有的继承图。

Answer 10

如前所述，模块化代码比非模块化代码更具可重用性。

帮助模块化代码的一种方法是使用封装，请参阅封装理论： http://www.edmundkirwan.com/

版

Answer 11

避免重新发明轮子。而已。而这本身就有很多好处。如果你确实需要改变一些东西，那么你只需要创建另一段代码，另一个类，另一个常量，库等......它可以帮助你和其他开发人员在同一个应用程序中工作。

Answer 12

评论，详细，下次回到代码时看起来可能会让您感到困惑的一切。过于冗长的评论可能会有点烦人，但它们远比稀疏评论好得多，并且可以节省数小时试图找出你上次做的WTF。