前几周我和一些同事讨论了代码重构的问题,我似乎是少数认为“早重构,常重构”是一个好方法,可以避免代码变得混乱和难以维护。其他人认为这只适用于项目的维护阶段。
如果你有自己的观点,请进行辩护。
前几周我和一些同事讨论了代码重构的问题,我似乎是少数认为“早重构,常重构”是一个好方法,可以避免代码变得混乱和难以维护。其他人认为这只适用于项目的维护阶段。
如果你有自己的观点,请进行辩护。
所有测试通过后,我会立即对代码进行重构。这样我可以在脑海中清晰地记得如何改进它,并且在其他人看到第一版有多丑之前就清理掉。
在最初的提交之后,每次接触代码时我通常都会进行重构。重构不应该是你单独留出时间来做的事情。你应该边做边重构。
我尽可能地重构代码,因为这让我能够将代码打磨到最佳状态。即使在主动开发过程中,我也会这样做,以防止一开始就创建难以维护的代码。这通常还可以让我在设计错误变得无法修复之前,将其纠正。
重构的三个好处:
不重构的三个好处:
"杂乱无章"是有争议的 - 有一个合理的论点称为“修补破窗户”或“代码卫生”,它建议如果你让小事物滑落了,那么你将开始让大事物滑落。这很好,记住这一点是件好事,但要记住这只是一个比喻。这并不能成为毫无止境地移动代码以寻求最干净的解决方案的借口。
你应该根据好的理由出现的频率和测试过程保护您免受引入缺陷的程度来确定重构的频率。
重构从来不是一个目标。但是如果某些东西不起作用,就必须修复它。这对于初始开发和维护来说都是正确的。对于非平凡的更改,几乎总是比在单个地方打补丁要好得多,而且要避免在其他地方进行任何更改。
值得一提的是,只要我能掌握使用它的内容,并且结果变化的范围可管理,我就会毫不犹豫地更改接口。
正如书中所说,当你:
时,你需要进行重构。
很多时候,当我在构思想法时,我的代码开始非常紧密耦合和混乱。随着我对想法的不断完善,逻辑分离变得越来越清晰,我开始进行重构。这是一个不断的过程,正如每个人建议的那样,应该“早期和经常”进行。
我进行重构的情况有:
当我修改代码时,感到困惑。如果我要花费一段时间才能理清楚它,那就需要进行重构。
当我创建新代码并得到“工作”后。通常情况下,我会让事情运行起来,随着编码的进行,我意识到“嘿,我需要重新做我之前做的20行代码,只不过稍作修改。” 在这个时候我就会进行重构并继续进行。
我认为唯一应该阻止你这样做的是时间限制。无论你喜欢与否,有时候你就是没有足够的时间去做。
随时进行重构!只要容易就做。
如果重构很困难,那么你可能选择了错误的时间(代码不需要)或错误的部分(其他地方可以获得更好的效率)。 (或者你还不太擅长重构。)
将重构留到“维护”时期是一种说辞。重构就是维护。