重构--代码如何进行重构
这一篇旨在让自己认识重构的重要性，在项目开发过程中要培养自己的重构思维。能在项目迭代过程中，让code review成为开发的一部分，以提高自己的代码能力。
什么情况下重构？
到底重构什么？
又该如何重构？
“重构”这个词对于大部分工程师来说可能不陌生，但真正进行代码重构的人不多，而持续重构作为开发的一部分的人少之又少。这是什么原因呢
1、重构代码对一个工程师能力的要求，要比单纯写代码高的多。重构需要你能洞察出代码存在的坏味道或者设计上的不足，并且能合理、熟练地利用设计思想、原则、模式、编程规范等理论知识解决这些问题。
2、很多工程师对为什么要重构，到底重构什么、什么时候重构，又该如何重构等相关问题理解不深，对重构没有系统性的认识，面对一堆烂代码，没有重构技巧的指导，只能想到哪改到哪，并不能全面地改善代码的质量。
重构需要掌握的知识点：
1、对重构概括性的介绍，包括重构的目的(why)、对象(what)、时机（when）、方法（how）。
2、保证不出错的手段，重点是单元测试和代码的可测试性
3、不同规模的重构，大规模高层次的重构(比如系统、模块、代码结构、类与类之间的交互等重构)和小规模低层次重构（类、函数、变量等重构）
这一部分内容：重构的目的、对象、时机、方法
重构是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，使其更易理解，修改成本降低。其中的重点“重构不改变外部可见行为”。我们可以理解为，在保持功能不变的情况下，利用设计思想、原则、模式、编程规范等理论来优化代码，修改设计上的不足，提高代码质量。
重构的目的：为什么重构(why)
对于项目而言：
1、重构使避免过度设计的重要手段。在维护过程总，真正遇到问题的时候，再对代码遇到问题时再进行重构，能过有效的避免项目前期过度设计，做到有的放矢。
2、优秀的的代码或者架构不是一开始就能完全设计好的。而是不断迭代出来。而重构是在迭代过程中保证代码质量的一个重要的手段，不至于让代码腐化到无可救药的地步。
3、在项目演进过程中如果没有人为代码的质量负责，代码总会往越来越混乱的地方演进。当混乱到一定程度，可能会引起质变，设置维护项目的成本要高于重新开发一套新代码的成本。
对个人而言：
1、重构是我们学习经典设计思想、设计原则、设计模式、编程规范的练兵场，是将这些理论知识进行实践的好机会。能够有效的提高我们的代码能力。
2、所谓“初级工程师在维护代码、高级工程师在设计代码、资深工程师在重构代码”。这句话的意思是说，初级工程师在已有的框架下修改bug,修改添加功能代码；高级工程师从零开始设计代码结构，搭建代码框架；而资深工程师为代码质量负责，需要发觉代码存在的问题，重构代码，时候保证代码处于一个可控状态。
重构的对象：到底重构什么(what)
重构可以笼统的分为：大规模高层次的重构（以下简称为“大型重构”）和小规模低层次的重构（以下简称“小型重构”）。
大型重构指的是对顶层代码设计重构，包括：系统、模块、代码结构、类与类之间的关系的重构。重构的手段有：分层、模块化、解耦、抽象可用重复组件等等。这类重构设计到的代码多，范围广，影响和难度都比较大，耗时较长，有可能引入bug。
小型重构指的是对代码细节的重构，主要针对的是类、函数、变量等代码级别的重构，比如命名规范、规范注释、消除超大类或者函数、提取重复代码等等。这类重构修改的地方比较集中，比较简单、可操作性比较强，耗时比较短，引入bug的风险也比较小。只需要掌握各种编程规规范，就可以得心应手。
重构的时机：什么时候重构(when)
不要在代码烂到一定程度，在集中重构解决所有问题，这是不现实的，必须有一条可持续、可演进的方式。所以提倡的重构策略是持续重构。就是平时没有事情的时候，看看项目中有哪些地方写的不够好，哪些功能代码不符合规范，是不好的设计，可以主动的去优化代码，主动进行代码重构。把code review作为开发的一部分。
重构的方法：又该如何重构(how)
对于大型重构，需要提前做好完善的重构计划，有条不紊的进行。每个阶段完成一小部分代码重构，然后提交、测试、运行，发现没有问题。再继续下一阶段的重构，保证代码一直处于可运行，逻辑正确的状态。每次重构都要控制好重构影响的代码范围，考虑好如何兼容老的代码逻辑，必要的时候还需要写一些兼容性的过度代码，只有这样才能让每个阶段的重构都不至于耗时太长，不至于与新功能相冲突。
大型重构一定是有组织，有计划，并且非常严谨，需要有经验，熟悉业务的资深同事来主导。
对于低层次的重构，影响范围小，只要愿意随时可以做。
参考：设计模式之美--王争
本文地址：https://blog.csdn.net/erge353729094/article/details/107501793