几个星期前我与一些同事进行了重构讨论,我似乎是少数人认为"早期重构,经常重构"是一种很好的方法,可以防止代码变得混乱和不可维护.许多其他人认为它只属于项目的维护阶段.
如果您有意见,请为其辩护.
jop*_*jop 78
就像你说的那样:早期重构,经常重构.
早期重构意味着必要的变化仍然在我脑海中浮现.重构通常意味着变化往往更小.
延迟重构只会导致一团糟,进一步使重构变得更加困难.我发现一塌糊涂就立即清理,防止它堆积起来,以后再成为问题.
Bil*_*ard 34
我会在功能完成后重构代码(所有测试都通过).这样我就可以清理它,而它在我脑海中仍然是新鲜的,并且在其他任何人看到第一个版本是多么丑陋之前.
在初次登记后,我通常会在每次触摸一段代码时进行重构.重构不是你应该留出的时间.这应该是你刚才做的事情.
Gar*_*our 23
你用两顶帽子写代码.在刚刚获得最事情,工作帽和I-需要理解的-这,明天的帽子.显然,第二个帽子是重构帽子.因此,每次你做了一些工作时你都会重构,但是(不可避免地)引入了重复代码,长方法,脆弱的错误处理,错误的变量名等等气味......
在尝试使某些东西工作时(即戴上两顶帽子)进行重构对于非平凡的任务来说是不切实际的.但推迟重构直到第二天/周/迭代是非常糟糕的,因为问题的背景将从你的脑袋消失.因此,尽可能经常在帽子之间切换,但绝不要将它们结合起来.
Bob*_*ing 18
我重构了每一次机会,因为它让我能够将我的代码磨练成最好的代码.即使在积极开发以防止首先创建不可维护的代码时,我也会这样做.它经常让我在一个糟糕的设计决定变得无法修复之前理顺它.
Ste*_*sop 13
重构的三个很好的理由:
不重构的三个好理由:
"凌乱"是有争议的 - 有一个有效的论据被称为"修复破窗"或"代码卫生",这表明如果你让小东西滑动,那么你将开始让大事物滑动.这很好,并且记住是一件好事,但请记住这是一个类比.为了寻找最干净的解决方案,它不能成为无休止地分流的原因.
您重构的频率应取决于良好原因发生的频率,以及您的测试过程如何保护您免于引入错误.
重构本身并不是目标.但是如果某些东西不起作用,就必须修复它,这在初始开发中和在维护中都是如此.对于非平凡的更改,重构几乎总是更好,并且干净地整合新概念,而不是用大块垃圾修补单个地方,以避免在其他地方进行任何更改.
对于它的价值,我认为没有改变接口,只要我掌握了使用它的方法,并且所得到的更改的范围是可管理的.
很多时候,当我发现想法时,我的代码开始非常紧密耦合和混乱.当我开始更多地理解这个想法时,逻辑分离开始变得越来越清晰,我开始重构.这是一个不变的过程,并且每个人都建议应该"早期和经常"完成.
我试图遵循这个座右铭:保留你所触及的所有代码.
当我修复或添加功能时,我通常会利用这个机会对受影响的代码进行有限的重构.通常这会使我更容易进行预期的更改,因此它实际上不需要任何费用.
否则,你应该预算专门的重构时间,如果你不能因为你总是在灭火(我想知道为什么)那么你应该强迫自己重构,当你发现变化变得比应该变得更难以及"代码闻起来"时真是难以忍受