什么是重构？软件设计大师 Martin Fowler 是这样定义重构的：“重构是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，使其更易理解，修改成本更低。”
为什么要重构保证代码质量在日常工作中，随着项目的演进，代码不停的堆砌，如果没有人为代码的质量负责，代码必定是朝着越来越混乱的方向演进的。混乱到一定程度之后，量变引起质变，导致项目bug频发，解决bug耗时且困难。代码可读性差，想要添加一个新功能时，开发人员需要花更多的时间去思考，去考虑如何把新功能塞进现有的代码库中，避免因改一个地方而出现牵一发而动全身的尴尬境界。
避免过度设计优秀的代码或架构不是一开始就能完全设计好的，就像优秀的公司和产品也都是迭代出来的。我们无法 100% 遇见未来的需求，也没有足够的精力、时间、资源为遥远的未来买单，所以，随着系统的演进，重构代码也是不可避免的。在我们维护代码的过程中，真正遇到问题的时候，再对代码进行重构，能有效避免前期投入太多时间做过度的设计，做到有的放矢。
提升工程师技术水平重构也是对我们学习的经典的设计思想、设计原则、设计模式、编程规范的一种应用，能够锻炼我们熟练使用这些理论知识的能力。可见重构能力也是衡量一个工程师代码能力的有效手段。
重构有哪些级别代码级在日常开发过程中，或因公司业务发展迅速，公司为了项目能早点上线压缩开发周期。开发人员在改bug或功能优化时，经常在没有完全理解架构设计的情况下，为了赶进度就使用临时方案，今天张三改一下明天李四改一下，于是代码逐渐失去了自己的结构。久而久之，程序员越来越难通过阅读代码理解原来的设计，于是代码就越愈发腐败得更快，最终沦为一个谁也不敢动的巨坑。
另一方面需求在演进，原有的设计模式可能已无法满足现今的业务需求，这时我们也需要通过重构来调整代码的结构保证代码的可扩展性。
最后，除了这些外部因素，开发人员本身对设计模式、设计思想的理解与应用场景出现偏差也会使得代码可维护性不高。
所以，代码级的重构就是使用设计模式、封装继承、优化拆解代码，使得代码的结构更清晰，维护成本更低，运行效率更高。
系统架构级随着项目的演进，系统功能变的丰富，业务逻辑也越来越复杂。开发人员熟悉和掌握整个项目的成本也在不断的增加。我们需要一种架构能帮我们化繁为简，使我们的代码不会因为一点小的改动导致牵一发而动全身。让我们的开发人员可以分组配合甚至单兵作战，每个人或小组只需要熟悉自己负责的那一块就能完成开发工作，而不需要熟悉整个项目从而让新人能够快速参与开发工作。
所以，系统级架构主要是通过对项目进行横向或纵向的拆分来降低项目间或模块间的耦合度，提高项目和模块的独立性和可复用性。
例如，在横向拆分方面我们可以：通过代码分层来隐藏底层的实现方式与复杂性，使得上下层解耦，提高各层实现方案的可替换性和可维护性。通过抽象可复用组件来降低开发成本与周期。在纵向拆分方面：通过模块化来提高业务间的独立性，降低模块内部的修改对外界的影响。
什么情况下重构搞清楚了什么是重构、为什么要重构、重构的级别之后，我们再来看一下什么时候重构？
代码级在日常开发过程中如果没有code review代码质量的高低是不容易在日常工作中体现的。但当烂代码堆砌到一定程度时，量变引起质变，你会发现“接手这个项目的人频繁离职，开发效率低，招了很多人，天天加班，出活却不多，线上 bug 频发，查找 bug 困难”，这时我们要考虑的就不仅仅是要不要重构的问题了，而是重构成本是否已经超过了重新开发一套新代码的成本的问题。
目前业界的主流声音是比较反对平时不注重代码质量，堆砌烂代码，实在维护不了了就大刀阔斧地重构、甚至重写的行为。一方面维护代码的人也换了几批，代码的可读性差，重构时很难保证对原业务逻辑理解的准确性。另一方项目太过庞大，公司也不可能停下业务发展的步伐，给我们大量的时间重构。我们需要一边开发新功能一边重构，这样的重构往往很难做到彻底，最后往往又搞出来一个新的半成品，留下一个老的残次品！所以，寄希望于在代码烂到一定程度之后，集中重构解决所有问题是不现实的，我们必须探索一条可持续、可演进的方式。要把重构融入我们的开发过程中。
系统架构级系统架构级通常是阶段性的。它发生在模块间耦合度过高开发周期长且困难、代码分层不够清晰各层间实现方案的可维护性和可替换性变差、当前系统性能遇到瓶颈、单个系统开发人员过于庞杂沟通成本过高、出现重复开发等。
总结这篇文章比较偏理论、偏思想教育，主要还是对过去学习到的思想做一个总结，让自己对重构有个正确的、全局性的认知，建立持续重构意识。我觉得，这可能比重构技巧更重要，因为很多技术问题本身就不是单纯靠技术来解决的，更重要的是要有这种认知和意识。当然本文还只是在一个较高的纬度上对重构的一些梳理与总结，要想全面的认识重构，我们还得完善更微观知识，例如重构的对象以及重构的手段。
参考《设计模式之美》