language-agnostic - 什么时候重构代码？

Question

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

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

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

谢谢。

Answer 1

几点观察:

On on hand: 1. You never got time to do it.

如果您将重构视为与编码分开的事情(而不是体面地编码的内在部分)，并且如果您无法管理时间，那么是的，您将永远没有时间。

1. "Context switching" is mentally expensive (difficult to leave what you're doing in the middle of it).

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

1. It's usually isn't an easy task.

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

High cyclomatic complexity ,

每个类(或过程)没有单一职责，

高耦合和/或差的低内聚(又名差 LCOM metrics )，

结构差

不关注 SOLID principles .

不遵守 Law of Demeter在适当的时候。

过度遵守 Law of Demeter不合适的时候。

针对实现而不是接口(interface)进行编程。

1. There's always the fear you'll break something that's now working.

测试？确认？分析？在被检查到源代码控制之前(当然是在交付给用户之前)这些中的任何一个？

On the other: 1. Using that code is error-prone.

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

1. Over time you might realize that if you would have refactored the code the first time you saw it - That would have save you time on the long run.

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

So my question is - Practically - When do you decide it's time to refactor your code?

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

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

好的代码有助于重构；它显示了良好的指标；它的结构类似于 computer science function composition和 mathematical function composition ;责任明确；它使不变量、前置条件和后置条件变得明显；等等等等。

希望能帮助到你。