“这就是重构过程的精髓所在，小步修改，每次修改后就运行测试”。
然而，我们大部分人做不到。
不是我们做不到小步修改。
是我们做不到每次修改后就运行测试。准确的说是无法做到每次修改后运行充分的测试，这成本太高了。要做到这一点，除非修改部分的代码有充分的自动化单元测试代码覆盖。然而，我见过的大部分工程中，单测代码少的可怜。所以，我们的重构过程可能是这样的：
由于测试成本太高，导致以下两个问题：
重构的步子变大，这样可以少测试几次，但步子大了，容易累积错误，修改错误变得困难
更可怕的是步子大了，累积的错误也多，有些错误不容易及时发现，会在某个节点暴雷，如果是提测后上线前还算幸运，但如果是在上线后暴雷，重构的罪过就大了
所以，结论是，对一般人来说，重构非常危险。
给普通人的建议
=======
如果做不到自动化单元测试覆盖，但为了避免危险，建议就是：不要对已经上线的代码进行重构，甚至，时间点再提前一点，不要在测试之后去重构。
写一段新的代码的时候，很难一开始就把代码写的很整洁，所以先怎么舒服怎么写，写的差不多了，能跑通了，这时候，先不要去做全面的人工测试，先去重构，先去整理代码，整理完后，在做全面的人工测试。这样可以省下人工回归测试的成本。
这是对一般开发人员最实用的重构姿势。按理想的重构姿势做，软件原有功能很少被破坏，所以有非常多的时机做重构，这来源于自动化测试的保障以及这种保障下的小步修改，这些是"防止混乱的关键"；但对于实用的重构姿势，你安全重构的机会只有测试前的这一次。所以，要无比珍惜。
除了这种安全的重构的时机，还有一些相对比较安全的重构，如果你的情怀能支撑你冒一点风险的话。
比如修改一个线上BUG的时候。
首先，有时候重构有助于你改BUG。你根本看不懂那个BUG所处的"屎山"一样的代码块，俗称"不敢改"，在修复BUG前重构一下可能会帮助你读懂它，然后你稍微变的敢改了。
其次，由于改一个线上BUG引入的新的BUG后果并不严重，我说的不是对系统来说不太严重，而是说对改BUG的人。大多数管理者能容忍这种改BUG引入的BUG，但难以容忍只为了改善代码可读性而引入的BUG。
最后，你改完BUG，总得回归测试一下吧，包括你自己，包括测试人员。如果引入了新的BUG，测试人员也能承担一部分责任。
不是教你学坏，实在是没有办法，除非你不介意在"屎山"上再贡献一些自己的力量。这种相对比较安全的重构孰是孰非，难以说清，我个人既不赞成也不反对。
读者福利
由于篇幅过长，就不展示所有面试题了，感兴趣的小伙伴
更多笔记分享
转存中…(img-GBaPl2EN-1714813573782)]
更多笔记分享
[外链图片转存中…(img-TO17UVoU-1714813573783)]
789
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
