何时重构

三次法则, 第一次做某件事时只管去做;第二次做类似的事会产生反感,但无论如何还是可以去做;第三次再做类似的事,你就应该重构. 事不过三,三则重构.

预备性重构: 让添加新功能能容易

在添加新功能之前,我们看看现有的代码库,此时经常会发现:如果对代码结构做一些微调,工作会容易很多.

例如: 删除冗余的数据类型操作方法,使用 lodash 库

用重构帮助理解,给一两个变量改名,让他们更清楚的表达意图,以方便理解,或是将一个长函数拆成几个小函数.让代码变得更清晰一些.

我已经理解代码在做什么,但发现它做得不好,例如两个函数几乎相同,可以用一个参数化的函数取而代之.有时这样的垃圾需要好几个小时才能解决,而我有更紧急的事要完成.不过即便如此,稍微花一点功夫做一点清理,通常都是值得的.有时一块垃圾在好几个月之后才终于清理干净,但即便每次清理并不完整,代码也不会被破坏.

预备性重构、帮助理解的重构、捡垃圾式重构 -- 都是见机行事的: 作者并不专门安排一段时间来重构,而是在添加功能或修复 bug 的同时顺便重构.

肮脏的代码必须重构,但漂亮的代码也需要重构.

有时,即便团队做了日常的重构,还是有问题在某个区域逐渐累积长大,最终需要专门花谢时间来解决.但这种有计划的重构应该很少,大部分重构应该是不起眼的、见机行事的.

有一些大型的重构可能要花上几个星期,例如要替换一个正在使用的库,或者将整块代码抽取到一个组件中并共享给另一个团队使用,再或者处理一大堆混乱的依赖关系.

code review

如果我看见一块凌乱的代码,但并不需要修改它,那么我就不需要重构它.如果丑陋的代码能被隐藏在一个 API 之下,我就可以容忍它继续保持丑陋.只有我需要理解其工作原理时,对其重构才有价值.

另一种情况是,如果重写比重构还容易,就别重构了.决定到底应该重构还是重写,需要良好的判断力与丰富的经验.

重构的唯一目的就是让我们开发更快,用更少的工作量创造更大的价值