什么时候重构代码？

Question

在手:
1.你永远没有时间去做.
2."上下文切换"在精神上很昂贵(很难留下你正在做的事情).
这通常不是一件容易的事.
人们总是害怕你会破坏现在正在发挥作用的东西.

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

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

谢谢.

Answer 1

几点意见:

在手边: 1.你没有时间去做.

如果你将重新分解视为与编码分开的东西(而不是正确编码的内在部分),如果你无法管理时间,那么是的,你永远不会有时间.

1. "上下文切换"在精神上很昂贵(很难留下你正在做的事情).

见上面的上一点.重构是良好编码实践的积极组成部分.如果将两者分开,就好像它们是两个不同的任务一样,那么1)您的编码实践需要改进/成熟; 2)如果您的代码严重需要重构,您将参与严格的上下文切换(同样,代码质量. )

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

只有当您生成的代码不适合重构时.也就是说,难以重构的代码展示了以下一个或多个(列表不是普遍包含的):

1. 高圈复杂度,
2. 每班(或程序)不承担任何责任,
3. 高耦合和/或差的低内聚(又称差的LCOM指标),
4. 结构不好
5. 不遵循SOLID原则.
6. 在适当的时候不遵守得墨忒耳法.
7. 不恰当时过度遵守得墨忒耳法则.
8. 针对实现而不是接口进行编程.

1. 总是害怕你会破坏现在正在发挥作用的东西.

测试？验证？分析？在检查源代码控制之前(当然在交付给用户之前)中的任何一个？

另一方面: 1.使用该代码容易出错.

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

1. 随着时间的推移,你可能会意识到,如果你第一次看到代码就会重构代码 - 从长远来看,这可以节省你的时间.

这种认识不应该随着时间而发生.良好的工程和工作道德要求在人工制品(硬件或软件)正在制造时实现.

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

实际上,当我编码时; 我检测到需要改进的区域(或者在需求或期望发生变化后需要修正的区域); 我有机会在不牺牲截止日期的情况下改进它.如果我不能在那一刻重新考虑因素,我只需记录感知缺陷并创建一个可行的,切合实际的计划来重新审视用于重构的工件.

在现实生活中,有些时候我们会编写一些丑陋的kludge只是为了让事情运转起来,或者因为我们已经筋疲力尽或者其他什么.这是现实.我们的工作是确保这些事件不会堆积并且无人看管.而关键是在编码时重构,保持代码简单,并具有良好,简单和优雅的结构.而"优雅"我并不是指"聪明屁股"或深奥,而是显示通常被认为是可读,简单,可组合的属性(以及实际应用时的数学属性).

好的代码有助于重构; 它显示了良好的指标; 其结构类似于计算机科学的功能组成和数学功能组成 ; 它有明确的责任; 它使其不变量,前后条件明显; 等等等等.

希望能帮助到你.

Answer 2

1. 每当它闻起来,我都会重构.我现在可能不会完美,但我至少可以向更好的状态迈出一小步.随着时间的推移,这些微小的变化会增加......
2. 如果我在注意到气味的时候处于中间位置,并且修复它并不是微不足道的(或者我只是在释放之前),我可能会做一个(精神或纸质)注释,一旦我完成了主要任务.
3. 实践使一个更好:-)但如果我没有看到问题的解决方案,我把它放在一边,让它酿造一段时间,与同事讨论,甚至发布在SO ;-)
4. 如果我没有单元测试并且修复不是微不足道的,那么我将从测试开始.如果测试也不重要,我会应用第2点.

Answer 3

我看到的最常见的错误之一是人们将"重构"一词与"大变革"联系在一起.

重构代码并不总是很大.即使很小的更改,例如将a更改为bool正确的枚举,或者将方法重命名为更接近实际功能而非意图,都是重构代码.除了里程碑的结束之外,我每次登记都会尝试至少进行一次非常小的重构.而且你会惊讶于它在代码中产生明显差异的速度有多快.

更大的变化确实需要更大的规划.在正常的开发周期中,我尝试每两周安排一次约1/2,以解决更大的重构变化.这是足够的时间来对代码库进行实质性的改进.如果重构每天失败1/2,则不会造成太大的损失.并且它很少完全丢失,因为即使是失败的重构也会教你一些关于代码的东西.