重构：高手的姿势你学不会(1)

我在和很多人交流重构的时候发现，大家非常注重重构的结果，即重构前后的代码是什么样的，但会忽略重构的姿势。

高手重构的姿势

=======

老马在书中强调频繁且小步地进行重构："犯错误是很容易的，至少我很容易犯错误……重构技术是以微小的步伐修改程序，如果你犯下错误，很容易便可发现……真的犯错后，只考虑一个很小的改动范围，这使得查错和修复问题易如反掌，如果我改动了太多的东西，犯错时就可能陷入麻烦的调试，并为此耗费大把时间。小步修改，以及它带来的频繁的反馈，正是防止混乱的关键“。

这个重构的过程可以用下图表示：

“这就是重构过程的精髓所在，小步修改，每次修改后就运行测试”。

然而，我们大部分人做不到。

不是我们做不到小步修改。

是我们做不到每次修改后就运行测试。准确的说是无法做到每次修改后运行充分的测试，这成本太高了。要做到这一点，除非修改部分的代码有充分的自动化单元测试代码覆盖。然而，我见过的大部分工程中，单测代码少的可怜。所以，我们的重构过程可能是这样的：

由于测试成本太高，导致以下两个问题：

重构的步子变大，这样可以少测试几次，但步子大了，容易累积错误，修改错误变得困难

更可怕的是步子大了，累积的错误也多，有些错误不容易及时发现，会在某个节点暴雷，如果是提测后上线前还算幸运，但如果是在上线后暴雷，重构的罪过就大了

所以，结论是，对一般人来说，重构非常危险。

给普通人的建议

=======

如果做不到自动化单元测试覆盖，但为了避免危险，建议就是：不要对已经上线的代码进行重构，甚至，时间点再提前一点，不要在测试之后去重构。

写一段新的代码的时候，很难一开始就把代码写的很整洁，所以先怎么舒服怎么写，写的差不多了，能跑通了，这时候，先不要去做全面的人工测试，先去重构，先去整理代码，整理完后，在做全面的人工测试。这样可以省下人工回归测试的成本。

这是对一般开发人员最实用的重构姿势。按理想的重构姿势做，软件原有功能很少被破坏，所以有非常多的时机做重构，这来源于自动化测试的保障以及这种保障下的小步修改，这些是"防止混乱的关键"；但对于实用的重构姿势，你安全重构的机会只有测试前的这一次。所以，要无比珍惜。

除了这种安全的重构的时机，还有一些相对比较安全的重构，如果你的情怀能支撑你冒一点风险的话。

文末

我将这三次阿里面试的题目全部分专题整理出来，并附带上详细的答案解析，生成了一份PDF文档

• 第一个要分享给大家的就是算法和数据结构

• 第二个就是数据库的高频知识点与性能优化

• 第三个则是并发编程（72个知识点学习）

• 最后一个是各大JAVA架构专题的面试点+解析+我的一些学习的书籍资料

还有更多的Redis、MySQL、JVM、Kafka、微服务、Spring全家桶等学习笔记这里就不一一列举出来

[外链图片转存中…(img-n00dY9kF-1714813507417)]

还有更多的Redis、MySQL、JVM、Kafka、微服务、Spring全家桶等学习笔记这里就不一一列举出来

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录