重构：高手的姿式你学不会

软件开发是一门工程技术，其中任何一个技术或技能若是孤立地看都会是管中窥豹，只见一斑。任何一个做者在写书时都有一些前提和细节，然而常常是要不做者没说清楚，要不读者直奔主题而忽略了这些前提和细节，结果是东施效颦，拔苗助长，照猫画虎不成反类犬。

我在和不少人交流重构的时候发现，你们很是注重重构的结果，即重构先后的代码是什么样的，但会忽略重构的姿式。

高手重构的姿式

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

这个重构的过程能够用下图表示：

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

然而，咱们大部分人作不到。

不是咱们作不到小步修改。

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

因为测试成本过高，致使如下两个问题：

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

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

因此，结论是，对通常人来讲，重构很是危险。

给普通人的建议

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

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

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

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

好比修改一个线上BUG的时候。

首先，有时候重构有助于你改BUG。你根本看不懂那个BUG所处的"屎山"同样的代码块，俗称"不敢改"，在修复BUG前重构一下可能会帮助你读懂它，而后你稍微变的敢改了。

其次，因为改一个线上BUG引入的新的BUG后果并不严重，我说的不是对系统来讲不太严重，而是说对改BUG的人。大多数管理者能容忍这种改BUG引入的BUG，但难以容忍只为了改善代码可读性而引入的BUG。

最后，你改完BUG，总得回归测试一下吧，包括你本身，包括测试人员。若是引入了新的BUG，测试人员也能承担一部分责任。

不是教你学坏，实在是没有办法，除非你不介意在"屎山"上再贡献一些本身的力量。这种相对比较安全的重构孰是孰非，难以说清，我我的既不同意也不反对。

你们仍是用好惟一的那一次安全重构的机会吧。

取法乎上得乎其中

我是一个叶公好龙式的书法爱好者，我常常会照着字帖去临摹，但一直没法达到专业的水准。

有一次我看到老师教孩子写隶书，讲的是"蚕头燕尾" 笔法，一个笔画被拆的特别细，彻底是一个技术活，没有一点写字的乐趣。但我从中明白了我没法达到专业的水准的缘由。

但知道和作到仍是有一段距离的，我依然没法静下心练这些笔法，我仍是喜欢随意地按字帖去临摹。

我知道永远也达不到专业的水准了，但这些临摹确实让个人字变得比之前好看了。

对于大部分人来讲，重构也是这样。

取法乎上得乎其中。

读者福利：

分享免费学习资料

针对于还会准备免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料） 为何某些人会一直比你优秀，是由于他自己就很优秀还一直在持续努力变得更优秀，而你是否是还在知足于现状心里在窃喜！但愿读到这的您能点个小赞和关注下我，之后还会更新技术干货，谢谢您的支持！

资料领取方式：加入Java技术交流群963944895，私信管理员便可免费领取