@
no1xsyzy 我大概能理解你所说的理性化的，或者理论化的"重构"，大概就是修改一个原型，接口的实现，而不改变接口本身。但是现实情况是，重构一般是长期，局部化的调整，甚至是架构调整，甚至是一个人或者团队的资源调整。
(这个没有经历过的人大概不会明白，简单就是说，往往是以重构的名义，实际也是重构，但是期间会做转换核心资源的调整，可能原来是围绕 Amd 这个人，然后一点点慢慢局部替换，最后就编程 intel 了)
换言之，人写代码，是既要考虑人，也要考虑代码。不能只考虑代码本身呀。(您应该不是 robot 发言)
至于后面说的老大难的问题，甚至 bug，这个可以叫做 fix，但当时确实是可以支撑下去的。也就是我上面的核心观点：
业务走不下去了么？需要提重构这种事儿。具体点儿，以往那个千年虫的问题，当时他就能解决，为什么他要甩锅给后来的人，且当时用的时候也是没有问题的，只不过 1900 和 2000 出现的时候(也就是他开发时的后面)，那时才叫 bug，如果当时的人解决，就是重构了。然后这些前辈却没有，可想而知重构不是那么容易。（可能我没有说清楚）
其实我可以反问您，我耗费这么人力，时间，财力搞的重构对于当前的业务有啥益处？后来的问题，后来的人不能搞么？这个东西为啥一开始没有就设计好？既然一开始没有设计好(又不是我们设计的原型)，现在又能用，何故看了一本重构就来谈重构？
私以为，所谓的重构，clean code，不过是程序员自己的消遣，在领导面前 show own profession，然做过独立开发者，自己要解决生存，赚钱问题时，这。。。
总之，我不喜欢重构(尤其是前一个离职的人花两个礼拜写的东西，要我接下来的 2 个月都在维护和重构他的东西，所谓的兜底，所谓的擦屁股)。要么就推翻重来。要么就开始设计好。