系列文章目录
提示：这里可以添加系列文章的所有文章的目录，目录需要自己手动添加
TODO:写完再整理
前言
认知有限，望大家多多包涵，有什么问题也希望能够与大家多交流，共同成长！本文先对代码重构做个简单的介绍，具体内容后续再更，其他模块可以参考去我其他文章
提示：以下是本篇文章正文内容
一、重构的定义
对系统和软件内部结构的一种调整，提高其可理解性，降低其修改成本。
.
.
二、重构的目的
（1）增加代码的兼容性、拓展性
（2）增加代码的逻辑性，减少复用及多余的流程，逻辑清晰明了
在整理的时候把架构的枝叶都剪掉或者功能合并，反正重构后代码更整洁了
（3）提高代码开发的效率
理解程序有两面价值
“今天你可以为代码做什么”–【治标】实现暂时的功能
“明天代码可以为你做什么”–【治本】做好技术和程序储备，框架扩展性更强，更快的实现以后能做什么
代码都是需要进行维护与的，适当的时候进行重构，开发起来阻力才小，效率才高，差的系统代码，到处是补丁,写一个bug要修三个bug【防盗标记–盒子君hzj】
在做某个功能需求时，需要花掉大量的时间，才能找到和需求有关联的代码，大家可能深有体会，一个系统在上线初期，向系统中增加功能时，完成速度非常快，但是如果不注重代码质量，后期向系统中添加一个很小的功能可能就需要花上一周或更长的时间【防盗标记–盒子君hzj】
（1）【模块性的】系统架构能更快的响应需求，维护好扩展性更强的代码架构
（2）【代码性的】增加可维护性，降低维护成本，代码可读性和编辑性更强，对团队和个人都是正向的良性循环
（4）提高代码的可读性
我们是代码的作者，后人是代码的读者。写代码要时刻审视，做前人栽树后人乘凉、不做前人挖坑后人陪葬的事情
当你面对结构混乱、毫无章法的代码结构，词不达意的变量名、方法名时，根本无法读下去
（5）【个人的】通过复盘，更好的积累自己的技术和代码储备
（6）最终，把demo实验验证上升到一个产品
.
.
三、重构的挑战（难处）
1.意识问题
如果我纯粹为今天工作，明天我将完全无法工作，但其实大多数人都是不喜欢重构工作的，就像没有人愿意给别人“擦屁股”一样【防盗标记–盒子君hzj】
.
2.方法论问题
不知道怎么重构，缺乏重构的经验和方法论
.
3.额外工作问题
重构需要你付出额外的工作去读懂别人的程序【学习还行】，重构会破坏现有程序，带来意想不到的Bug，不想去承受这些意料之外的Bug。【防盗标记–盒子君hzj】
.
4.利益问题
很难看到短期收益，无法产出新的功能，业务上没有任何推进，长远看来，说不定当项目收获这些利益时，你已经不负责这块工作了
.
.
四、重构的程度及方法论【重点】
1.小型重构方法论【日常工作、空闲时间】
（1）变量规范命名（针对词不达意的变量再命名）
（2）逻辑过于复杂，如if-else过多
（3）消除超大函数
一个好的函数必须满足单一职责原则，短小精悍，只做一件事
（4）整理类关系
多组合，少继承
（5）消除重复代码
法将它们合而为一，避免重复阅读
（6）消除无用代码（不要舍不得）
一种是没有使用场景，如果这类代码不是工具方法或工具类，而是一些无用的业务代码，那么就需要及时的删除清理。
另外一种是用注释符包裹的代码块，这些代码在被打上注释符号的时候就应该被删除【防盗标记–盒子君hzj】
（7）整理代码注释
无病呻吟，代码本身一眼就能看明白是在干什么，写代码的人非要在这个地方加一个不关痛痒的注释，这个注释完全是口水话，毫无价值可言
不合理的注释
注释是一把双刃剑，好的注释能够给我们好的指导，不好的注释只会将人误导
.
.
2.大型重构方法论【制定计划，按部就班】
对代码顶层架构进行重新设计，这类重构可能需要进行原则再定义、模式再定义甚至业务再定义
（1）系统业务结构重构
（2）技术模块结构
（3）代码数据流结构
.
.
3.重构技巧
（1）工作时自下到上，重构时从上至下，由外到内进行建模分析，理清各种关系，是重构的重中之重
（2）提炼类，复用函数，下沉核心能力，让模块职责清晰明了【防盗标记–盒子君hzj】
（3）依赖接口优于依赖抽象，依赖抽象优于依赖实现，类关系能用组合就不要继承
（4）类、接口、抽象接口设计时考虑范围限定符，哪些可以重写、哪些不能重写，泛型限定是否准确
.
.
4.重构的效果到适度就好（定重构的需求）
（1）重构太细致泛化能力差，容易出现无病呻吟的问题
（2）重构力度太小，效果不明显【防盗标记–盒子君hzj】
（3）重构到可以了解清楚方向和得到方法论就好
.
.
五、避免经常重构的方法
（1）【规范标准】遵循代码开发规范、准则和格式对齐
正所谓理论到头成书籍，工程到头成规范
.
.
（2）【架构师】有一个好的架构师，框架要求不要变来变去【防盗标记–盒子君hzj】
当然可是可遇不可求的，分分钟产品经理觉得这个不重要哈哈，反正开发的不是他，当然大部分同事都是能达成共识的
.
.
六、大型代码重构流程【按部就班，一步一步推进】
1.事前【目标计划】
（1）自己梳理现有架构
对涉及重构部分的现有业务、架构进行梳理，明确重构的内容在系统的哪个服务层级、属于哪个业务模块，依赖方和被依赖方有哪些，有哪些业务场景，每个场景的数据输入输出是怎样的
（2）会议明确重构的内容、方向目标
满足未来的方向，且方向是经得起大家的质疑
（3）会议宣讲，项目立项
重构涉及到哪些业务和场景、大概的重构方式、业务影响可能有哪些，难点及可能在哪些步骤出现瓶颈
周知大概的时间计划表（粗略的大致时间）【防盗标记–盒子君hzj】
明确各组主要负责的人
2.事中
（1）会议架构设计与评审
（1）明确业务架构（图）
（2）明确系统技术模块架构（图）
（3）明确源码数据流程架构（图）
（2）分工进行代码的编写、测试、线下实施
3.事后【沉淀形成收获】
【公开】开一个重构复盘会
（1）检查每个参与方是否都达到了重构要求的标准【防盗标记–盒子君hzj】
（2）复盘重构期间遇到的问题、以及解决方案是什么样的
（3）沉淀方法论避免后续的工作出现类似的问题。
.
【个人】沉淀项目部署经验
（1）业务架构
（2）系统技术模块架构【依赖？】
（3）源码输入输出数据流架构
（4）相关的设计图和文档
参考资料
https://mp.weixin.qq.com/s/5Qxll-uxj4eCAl7pQ2PAwg
https://blog.csdn.net/Travis_X/article/details/87968746
还有经常看的那基本代码整洁之道、代码重构的几本书