什么时候重构代码？

Question

现有：
1.你永远没有时间去做这件事。
2.“上下文切换”在精神上是昂贵的（很难将你正在做的事情留在中间）。
3. 这通常不是一件容易的事。
4. 总是担心你会破坏正在运行的东西。

另一方面：
1. 使用该代码很容易出错。
2. 随着时间的推移，您可能会意识到，如果您在第一次看到代码时就对其进行了重构，从长远来看，这会节省您的时间。

所以我的问题是 - 实际上 - 你什么时候决定重构你的代码？

谢谢。

Answer 1

一些观察结果：

现有：
1. 你从来没有时间去做这件事。

如果您将重构视为与编码分开的事情（而不是像样地编码的固有部分），并且如果您无法管理时间，那么是的，您将永远没有时间去做它。

1. “上下文切换”在精神上是昂贵的（很难将你正在做的事情留在中间）。

请参阅上面的前一点。重构是良好编码实践的一个积极组成部分。如果您将两者分开，就好像它们是两个不同的任务一样，那么 1）您的编码实践需要改进/成熟，2）如果您的代码迫切需要重构（再次强调代码质量），您将进行严格的上下文切换。 ）

1. 这通常不是一件容易的事。

仅当您生成的代码不适合重构时。也就是说，难以重构的代码表现出以下一项或多项（列表并不普遍包含）：

1. 高圈复杂度，
2. 每个类（或过程）没有单一责任，
3. 高耦合和/或较差的低内聚性（又名较差的LCOM 指标），
4. 结构不佳
5. 不遵循 SOLID 原则。
6. 在适当的情况下不遵守德米特法则。
7. 在不适当的情况下过度遵守德墨忒尔法则。
8. 针对实现而不是接口进行编程。

1. 总是担心您会破坏正在运行的东西。

测试？确认？分析？在检查到源代码控制之前（当然还有在交付给用户之前），其中有任何一个吗？

另一方面：
1. 使用该代码很容易出错。

仅当它从未测试/验证和/或没有清楚地了解潜在易错代码可接受的运行条件和使用模式时。

1. 随着时间的推移，您可能会意识到，如果您重构代码
   当您第一次看到它时 - 从长远来看，这会节省您的时间。

这种认识不应该随着时间的推移而发生。良好的工程和职业道德要求在制造工件（硬件或软件）时实现这一点。

所以我的问题是 - 实际上 - 你什么时候决定重构你的代码？

实际上，当我编码时；我发现需要改进的地方（或者在需求或期望发生变化后需要纠正的地方）；我有机会在不牺牲最后期限的情况下改进它。如果我当时无法重构，我只需记录感知到的缺陷并创建一个可行的、现实的计划来重新审视重构的工件。

在现实生活中，有时我们会编写一些丑陋的代码，只是为了让事情正常运行，或者因为我们精疲力竭、疲倦或其他原因。这是现实。我们的工作是确保这些事件不会堆积起来并且无人处理。而做到这一点的关键是在编码时进行重构，保持代码简单并具有良好、简单和优雅的结构。我所说的“优雅”并不是指“自作聪明”或深奥，而是显示了通常被认为是可读的、简单的、可组合的属性（以及实际应用时的数学属性）

。它显示出良好的指标；它的结构类似于计算机科学函数组合和数学函数组合;有明确的责任；它使其不变量、前置条件和后置条件变得明显；等等等等。

希望有帮助。

Answer 2

我看到的最常见的错误之一是人们将“重构”一词与“大改变”联系在一起。

重构代码并不总是很大。即使是很小的更改，例如将 bool 更改为适当的枚举，或者将方法重命名为更接近实际功能而不是意图，都会重构您的代码。除了里程碑的结束之外，我每次签入时都会尝试至少进行一次非常小的重构。您会惊讶地发现这在代码中产生了明显的差异。

不过，更大的改变确实需要更大的规划。在正常的开发周期中，我尝试每两周安排大约每天 1/2 次，以应对更大的重构变更。这足以对代码库进行实质性改进。如果每天重构失败 1/2，损失也不算太大。而且这很少会是彻底的损失，因为即使是失败的重构也会教会你一些关于代码的知识。

Answer 3

1. 只要有气味，我就会重构。我现在或许还不能做到完美，但至少可以向更好的状态迈出一小步。随着时间的推移，这些微小的变化确实会累积起来……
2. 如果我正在做某事，当我注意到气味时，修复它并不是微不足道的（或者我就在发布之前），我可能会做一个（心理或纸质的） ）注意一旦我完成主要任务就返回它。
3. 实践使人变得更好:-)但是如果我没有看到问题的解决方案，我会把它放在一边并让它酝酿一段时间，与同事讨论，甚至将其发布在SO上；-)
4. 如果我不这样做没有单元测试并且修复并不简单，我从测试开始。如果测试也很重要，我将应用第 2 点。

Answer 4

一旦我发现自己在重复自己，我就开始重构。 DRY 原则。

另外，如果方法/函数变得太长，以至于它们看起来很笨拙，或者它们的目的被函数的长度所掩盖，我会将其分解为私有子函数来解释真正发生的事情。

最后，如果一切都正常运行，并且代码非常慢，我会开始考虑重构以提高性能。

Answer 5

在实现新功能时，我经常注意到，如果我正在处理的代码以不同的方式构建，那么任务会简单得多。在这种情况下，我通常会退一步，尝试先进行重构，只有完成后我才会继续实现新功能。

我还有一个习惯，就是在笔记或错误跟踪器中跟踪我想到的所有潜在改进。这些想法在那里酝酿了一段时间，其中一些不再那么引人注目，而合理的想法是在我致力于较小任务的一天中实现的。

Answer 6

当需要重构时重构代码。我寻找的一些症状：

• 相似对象中的重复代码。
• 一个对象的方法内出现重复代码。
• 每当需求发生两次或多次更改时。
• 任何时候有人说“我们稍后会清理它”。
• 任何时候我读完代码并摇头思考“哪个傻瓜做了这个”（即使有问题的傻瓜是我）

一般来说，较少的设计和/或不太明确的需求意味着更多的重构机会。

Answer 7

这听起来可能像个笑话，但实际上，我只在事情“变得混乱”时才进行重构。当一个简单的任务开始花费更多的时间和平常一样时，当我必须扭转我的思维来记住哪个函数正在做什么等等时。另外，如果代码开始运行缓慢，并且不是因为我在开发环境中运行（有很多可变输出等），如果我无法优化它，我会重构代码。正如你所说，从长远来看，这是值得的。

尽管如此，我总是确保在开始之前有足够的时间来思考问题，这样我就不会陷入这种情况。

干杯!

Answer 8

当出现以下情况之一时，我通常会进行重构：

• 我没有更好的事情可做，正在等待下一个项目进入我的收件箱
• 我对代码所做的添加/更改无法工作，除非，或者如果我重构
• 我对代码的布局方式在审美上不满意

Answer 9

Martin Fowler 在他的书中，如果同名建议您第三次这样做您正在代码块中进行另一项更改。第一次进入该块时，您碰巧注意到应该重构，但没有时间。第二次回来……同样的事情。第三次回溯重构。
另外，我读到当前版本的smalltalk（我想是squeak.org）的开发人员说他们经历了几周的紧张编码……然后他们退后一步看看可以重构什么。
就我个人而言，我必须在编码时抵制重构的冲动，否则我就会“瘫痪”。