前段时间刚重构了一个功能模块。该模块可以说是祖传代码。里面堆砌着各种判断条件，就是所谓的箭头型代码。我接手这个功能重构的
1.把代码读一遍和跑一遍，理解里面的需求。尽量画一个流程图。
2.建立防护网。将需求拆分之后，针对每个拆分的业务点写单元测试。
4.开始重构，解耦逻辑，设计方法的时候尽量让职业单一，类与类之间尽量符合迪米特原则，有依赖关系的类尽量只依赖类的特定方法。我觉得比较基础也是比较重要一点。不要有重复代码。命名要规范，类的各个职业要清晰。重构过程中，其实也要时不时的识别代码的坏味道。尽然是重构，那么肯定要比不重构之前肯定要更好。
5.重构完成之后，通过防护网的测试。

当天重构代码上线之后，基本上没有问题。运行了几天之后有一小段逻辑隐藏的比较深没有写这个逻辑测试，后面补上了一直都没有出过问题了。还是比较稳定的。
我这里只是做了中小规模的重构，后面跟着小争哥继续系统的学习大规模重构，以及重构的技巧和思想。

重构自然是要用的我们牛逼的设计模式和数据结构了。。。啊-_-||开个玩笑哈。

重构这玩意嘛，其实在第一版提上去的时候就应该要重构了，也就是我们常说的，边写边重构。

一个方法写的时候发现分支判断太多，工厂模式就要登场了。

如果大部分代码都比较重复，这个时候就需要往底层的抽象，甚至用上策略模式。

需要做一个非功能性需求，每一个接口调用都要记录的东西，我们为了避免业务侵入性，就要考虑代理模式重构之前的业务侵入性强的代码，将功能与非功能分离。

说到底，重构不要等，而是马上动手，只有行动了，才不会害怕。第一版稍微辛苦一些，以后就不会那么恶心了，功在当代，利在千秋。

代码中的坏味道，好比人的头疼脑热。“小病”不管的话，迟早会发展成大病，需要动大手术，甚至病入膏肓。
实际中的一些体会：
一、在完成一个新需求时，在时间允许的情况下，会经常改进代码，使代码更优雅。
二、“重构不改变外部的可见行为“，引入自动化测试非常重要，国内有些团队可能做的不好。因为改动代码可能引入bug，如果没有自动化测试，测起来就会非常费劲，改动的结果不确定。如果测试不方便，谁会愿意修改之前work的代码呢？
三、持续集成、自动化测试、持续重构都是很好的工程实践。即使工作的项目中暂时没有使用，也应该有所了解。

1.座右铭：你写的每一行代码，都是你的名片。

2.重构要考虑时机和力度。一般是增加需求时，对关联的逻辑代码做的重构。这时需要考虑自己当前的开发期限去决定重构的力度。在保证“营地比自己来时干净”的前提下，量时重构。（逻辑级别小重构一般就如栏主说的改变量名，方法名，以及不破坏现有逻辑做实现代码实现重构，移动变量，内联提炼啥的）（逻辑级别的大重构就要动实现逻辑，甚至需求设计了。往往需要再三与产品沟通确认，并充分测试，甚至在实现上留有开关，一旦现网有问题，及时切换）（架构级别的大重构，包括调整分层模型，重新划分各个微服务持有的聚合，基础技术栈升级，比如spring到springboot，或则jdk。这些影响面都比较大，很难测试全，所以一般是并行重构，然后走现网镜像流量持续观察，大面积业务场景没问题后再整个切换）

3.持续重构锻炼架构思维，受益匪浅。重构不难，难的是在代码上讲究的意愿。

设计模式_27

没有做过大重构，小重构倒是经常做，我发现我做需求常常比别人慢，原因是大概率我改的地方比需求涉及的多一些，可以算是小重构吧。

很同意王争老师说的，大部分人都没有进行过重构，而大部分的代码又是由这大部分的人写的，所以，市面上的大部分代码可能都。。。

我在创业公司呆过，见识过技术总监申请重构时被挑战的体无完肤，不欢而散，代码一直烂下去，最终谁也改不动，大量的客户流失，业务严重受损。当然，我在这个过程中，毫无作为。。。

打卡
一、重构的目的：
定义：“重构是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，使其更易理解，修改成本更低。”
1、在保持功能不变的前提下，利用设计思想、原则、模式、编程规范等理论来优化代码，修改设计上的不足，提高代码质量。
2、时刻保证代码质量的一个有效手段
3、优秀的架构或是代码不是一开始就能设计好的，需要持续演进
4、避免前期的过度设计
5、重构是对我们的学习的经典的设计思想、设计原则、设计模式、编程规范的一个综合应用
二、重构的对象
1、大型重构：对代码结构、模块、类与之间的关系、
大型重构的手段：分层、模块化、解耦、抽象可复用组件等
2、小规模低层次重构：针对代码细节重构
小型重构的手段：针对类、函数、变量等代码级别的重构
三、重构的时机：
融入到日常开发中
三、重构的方法：
大规模：有组织、有计划、分阶段小步快跑
小规模：随时进行