你应该多久重构一次？

几个星期前我与一些同事进行了重构讨论,我似乎是少数人认为"早期重构,经常重构"是一种很好的方法,可以防止代码变得混乱和不可维护.许多其他人认为它只属于项目的维护阶段.

如果您有意见,请为其辩护.

就像你说的那样:早期重构,经常重构.

早期重构意味着必要的变化仍然在我脑海中浮现.重构通常意味着变化往往更小.

延迟重构只会导致一团糟,进一步使重构变得更加困难.我发现一塌糊涂就立即清理,防止它堆积起来,以后再成为问题.

我会在功能完成后重构代码(所有测试都通过).这样我就可以清理它,而它在我脑海中仍然是新鲜的,并且在其他任何人看到第一个版本是多么丑陋之前.

在初次登记后,我通常会在每次触摸一段代码时进行重构.重构不是你应该留出的时间.这应该是你刚才做的事情.

你用两顶帽子写代码.在刚刚获得最事情,工作帽和I-需要理解的-这,明天的帽子.显然,第二个帽子是重构帽子.因此,每次你做了一些工作时你都会重构,但是(不可避免地)引入了重复代码,长方法,脆弱的错误处理,错误的变量名等等气味......

在尝试使某些东西工作时(即戴上两顶帽子)进行重构对于非平凡的任务来说是不切实际的.但推迟重构直到第二天/周/迭代是非常糟糕的,因为问题的背景将从你的脑袋消失.因此,尽可能经常在帽子之间切换,但绝不要将它们结合起来.

我重构了每一次机会,因为它让我能够将我的代码磨练成最好的代码.即使在积极开发以防止首先创建不可维护的代码时,我也会这样做.它经常让我在一个糟糕的设计决定变得无法修复之前理顺它.

重构的三个很好的理由:

您的原始设计(可能在非常小的区域,但设计仍然是)是错误的.这包括您发现常见操作并希望共享代码的位置.

你是在迭代地设计.

代码非常糟糕,需要进行大规模整修.

不重构的三个好理由:

"这看起来有点乱".

"我不完全同意最后一个人这样做的方式".

"它可能更有效".(问题在于'可能').

"凌乱"是有争议的 - 有一个有效的论据被称为"修复破窗"或"代码卫生",这表明如果你让小东西滑动,那么你将开始让大事物滑动.这很好,并且记住是一件好事,但请记住这是一个类比.为了寻找最干净的解决方案,它不能成为无休止地分流的原因.

您重构的频率应取决于良好原因发生的频率,以及您的测试过程如何保护您免于引入错误.

重构本身并不是目标.但是如果某些东西不起作用,就必须修复它,这在初始开发中和在维护中都是如此.对于非平凡的更改,重构几乎总是更好,并且干净地整合新概念,而不是用大块垃圾修补单个地方,以避免在其他地方进行任何更改.

对于它的价值,我认为没有改变接口,只要我掌握了使用它的方法,并且所得到的更改的范围是可管理的.

正如书中所说,你重构的时候

你添加一些代码......一个新功能

当您修复错误/缺陷时

当您与多人进行代码审查时

当你发现自己第三次复制某些东西时...... 3次罢工

很多时候,当我发现想法时,我的代码开始非常紧密耦合和混乱.当我开始更多地理解这个想法时,逻辑分离开始变得越来越清晰,我开始重构.这是一个不变的过程,并且每个人都建议应该"早期和经常"完成.

我试图遵循这个座右铭:保留你所触及的所有代码.

当我修复或添加功能时,我通常会利用这个机会对受影响的代码进行有限的重构.通常这会使我更容易进行预期的更改,因此它实际上不需要任何费用.

否则,你应该预算专门的重构时间,如果你不能因为你总是在灭火(我想知道为什么)那么你应该强迫自己重构,当你发现变化变得比应该变得更难以及"代码闻起来"时真是难以忍受