提出我的看法:
较小的增量更改使代码处于比发现状态更好的状态
绝对可以:与功能没有直接关系的“化妆品”更改(即,不作为更改请求计费)。
绝对不能:重写大块显然违反了“小增量”部分。重构通常被用作重写的反义词:而不是再做一次,而是改进现有的重构。
绝对可能:替换数据结构和算法在某种程度上是一个边界案例。IMO的决定性差异是很小的步骤:准备交付,准备处理其他案件。
示例:假设您有一个报告随机化器模块,该模块因使用矢量而减慢了速度。您已经剖析了矢量插入是瓶颈,但是不幸的是,该模块在许多地方都依赖连续内存,因此当使用列表时,事情会悄无声息地中断。
重写意味着将模块从头开始扔掉一栋更好,更快的建筑,而只是从旧建筑中挑选一些。或编写一个新的核心,然后将其放入现有对话框中。
重构意味着将采取一些小步骤来删除指针算法,以便进行切换。甚至您甚至可以创建一个实用程序函数来包装指针算术,用对该函数的调用替换直接的指针操作,然后切换到迭代器,以便编译器抱怨仍然使用指针算术的地方,然后切换到list
,然后删除多功能功能。
背后的想法是代码本身会变得更糟。修复错误并添加功能时,质量会逐步降低-变量的含义会微妙地改变,函数会获得一个额外的参数来破坏隔离,循环会变得有些复杂等。这些都不是真正的错误,您可以不能说会使循环变得复杂的行数,但会损害可读性和维护性。
同样,更改变量名称或提取函数本身并不是明显的改进。但总的来说,他们与缓慢的侵蚀作斗争。
就像鹅卵石的墙壁,每天都掉在地上。每天都有一个路人把它捡起来放回去。