1.引子
我们知道单元测试、重构、code review是日常开发中的一部分，都很重要。但是在实践中，许多团队都忽略了这一部分，尤其是对于业务开发同学来说，项目进度一赶，自然就选择性忽视了。我自己也一直在从事业务方面的开发，深有感触！
很多时候，我们连单元测试都做的不够充分，更别说重构、code review了。于是一步一步地，大多数业务开发同学就都成了拷贝粘贴代码的CURD BOY！会觉得业务开发没有技术含量。但其实我们知道技术是为业务服务的，只有技术与业务有机结合起来，才能获得完美的作品。
那么今天，我结合我个人开发方面的一些经验，重点给你分享一些我对重构方面的一些思考。抛砖引玉大家共同交流学习！
2.重构
2.1.什么是重构
关于重构，我们先来看一下定义，软件设计大师Martin Flower（就是把微服务整火起来的这位）是这么说的：重构是指对软件内部结构的改善，其目的是在不改变软件外在行为的情况下，使软件系统更容易理解，且更容易维护。
从定义上来看，着重是说不改变软件的外在行为，即软件提供的服务与能力不变，在这个基础上，提升软件作品的品质，比如可读性、维护性更好，即重构的本质可以理解为让软件系统代码质量，持续处于一种可控的范围，不至于太过腐化而难以维护。
从某种意义上来说，我们可以把重构分为大型重构，与小型重构。大型重构主要指软件架构层面的重构，比如说系统、模块、代码结构、类之间的交互关系的重构；小型重构主要指代码细节方面的重构，比如说类、方法、成员变量的重构。
你看这就是说的重构，重点是我们需要如何去重构？以及什么时候重构呢？我们接着往下看。
2.2.如何、什么时候重构
原于去年我们团队的主要任务，重构了某核心系统，在这方面有一些体会，当时我们是把一个单体应用，进行了服务化的重构，属于架构层面的大型重构。
重构前系统是基于传统ssm架构的单块应用，系统在业务量、并发量、数据量、业务复杂度上都比较高，且源代码体量比较大，好几百兆。在这个背景下，进行的微服务化重构，重构后根据业务特征拆分了五大业务域，近20个微服务。
结合这里，我重点想给你分享重构过程中的一些思考。
在架构层面，对于大型重构，要求会比较高，需要有计划，分阶段、里程碑式谨慎的进行，这其中还涉及到设计思想、设计原则、设计模式的应用。比如面向对象，高内聚、低耦合，基于接口而非实现编程设计思想；比如SOLID、DRY、LOD设计原则；比如工厂、策略、观察者等设计模式。
在编码实现阶段，我们需要持续进行小型重构，比如类的设计是否合理，函数、成员变量是否合理等。
契合小结标题，我们回答了如何重构，即大型重构需要有计划、分阶段进行，且需要综合应用设计思想、设计原则、设计模式；那么小型重构，我们需要在编写代码实现的时候，考虑类、函数、成员变量是否合理，对于小型重构，更多的是需要编码规范进行支撑，编码规范我们将在下一篇文章来分享。
那么什么时候重构呢？我们说重构是一个持续的过程，尤其像小型重构，在编写实现代码的过程中，需要持续保持代码质量在一个可控的范围。千万不要面向离职编写代码，程序员都不容易，何苦相互为难对吧。
关于重构，除了技能技巧，我更加想要分享给你的是要有重构的意识，我们应该做一个持续有追求，对代码质量有洁癖。
2.3.为重构保驾护航
很多开发同学经常会说，每每看到维护项目中前人留下的糟糕代码，很多时候都有重构的冲动，最后愣是没敢下手，怕改出问题！一个怕字，说出了大家的心声对吧。
想改，改好了没功劳，改出了问题要背锅！这就比较麻烦了，涉及到如何为重构保驾护航的问题。针对这个问题，我想要分享给你的答案是：单元测试。
不论是开发新需求任务，还是重构已有的代码，我们都应该要有单元测试。当然关於单元测试，很多团队落实得都不好，我们团队也没有做好。很多后端开发同学，都是开发好接口，通过像postman这样的工具，简单调一下接口调通后，就直接发布到测试环境，等测试同学测试发现问题后再进行修改。
这也是为什么线上bug多，代码质量不好的原因。事实上，单元测试这个事情，于后端开发同学来说，做好是非常有收获的，有时候，我们可以通过测试反向来验证代码质量问题。比如说一个方法，难以给它编写单元测试用例，那么我们就可以思考该方法的设计实现是否不合理了，是否依赖过多，或者说不满足单一职责、接口隔离原则等。
最后，这篇文章我们就分享到这里了，期望给你带来一下关于重构的思考。