只重构经常修改的部分：重构收益取决于代码未来还会不会被继续维护

关于重构技巧最直接的一条经验是：只重构那些经常被修改的代码——如果一段代码在一两年内都没有被改动过，这本身就是一个强烈的信号，说明继续改动它的收益很小。这条经验背后的逻辑很直接：重构本身唯一能改善的是代码的可维护性（让未来的修改更容易、更安全），而”可维护性”这个价值只有在代码”未来确实还会被维护”这个前提下才有意义——一段代码如果几乎不再需要被修改，那么无论它写得多烂，它的可维护性差这个缺点根本不会再被真正触发，重构它带来的收益趋近于零，投入的精力和承担的风险却是实实在在的。这条原则和”只重构经常修改的部分”是同一枚硬币的两面，也呼应了[[重构的悖论：变更越频繁的系统越需要重构，却越难被停下来重构]]里的核心判断——重构决策不应该单纯依据”这段代码质量差不差”，而要依据”这段代码在未来的活跃度”，把两者结合起来看：真正值得投入重构精力的，是那些既质量不佳、又会被持续修改的代码，这类代码的重构收益会在未来的每一次修改中持续兑现；而质量差但很少被碰的代码、以及质量本来就还行的代码，都不值得被优先安排进重构计划里。这条原则给出了一条评估任何”改善型工作”投入产出比的通用思路：不要只看当前状态的糟糕程度，还要评估这个状态未来会被多频繁地触碰到——改善一个几乎不会再被触碰的东西，即使改善幅度再大，实际能兑现的价值也是有限的。