WHAT：什么是重构？
Martin Fowler：重构是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，使其更易理解，修改成本更低。
- 大型重构
- 对象：对系统、模块、代码结构、类与类之间的关系等的重构
- 方法：有分层垂直拆分、模块化水平拆分、解耦、抽象UI组件、抽象业务组件、抽象区块
- 方法论：编程范式、
设计原则、设计模式 - 影响：代码改动多，影响面广，难度较大，耗时较长，引入BUG风险高
- 小型重构
- 对象：对类、函数、变量等代码级别的重构
- 方法：规范命名(
见名知意)、规范注释、函数拆分、提取重复代码、eslint等 - 方法论：统一代码风格、制定规范、
语义化编程、eslint - 影响：影响面小，难度小，次数频繁，引入BUG风险低
WHY：为什么要重构？
- 软件最初设计的时候没有考虑到全部的功能和细节
- 软件需求变更和持续迭代导致原先的设计已不适用
- 消除
破窗效应，当代码里面有了坏味道而不及时改善，容易破罐子破摔加速恶化
HOW：如何重构代码？
- 灵活运用编程范式思想
- 面向对象
- 面向过程
- 函数式编程
- 以设计原则为核心
- SOLID
- KISS
- DRY
- YAGNI
- LOD
- CRP
- 以eslint为基础手段
- airbnb
- standard
- recommanded
- prettier
- 自定义
- 以
渐进式持续重构代码为方法论 - 优点：持续集成、进度可控、过程可逆、不影响正常业务开发进度
- 按金字塔原则对项目代码进行拆分
- 业务模块水平拆分
- 代码分层垂直拆分
- 评估出每一个重构单元的耗时
- 合理评估工作量
- 权衡重构的性价比
- 增加重构的可控性
- 正在做或规划中的业务单元顺手完成重构，其他部分安排空闲时间依次重构
- 注意
- 从0->1一次性完成重构的理想场景只存在于理想中。如果真实存在，只能说明项目过小或者已经趋于稳定迭代很少，这种情况要考虑是否真的有重构的必要！！！
- 不要有了锤子(重构方法论)，就满世界去找钉子
- 重构不是软件开发的必要流程，而是现有代码的组织缺陷或不合理的补救方式。
养成好的代码风格和code review的习惯避免代码的坏味道才是根本
WHEN：什么时候重构？
- 不要等到积重难返有了瓶颈之后再进行重构，大规模高层次的重构耗时耗力难度剧大
- 应该建立起渐进式持续重构的意识，发现当前业务代码写的有问题就应该及时进行小规模的重构，而不是欠一屁股技术债
BUG：重构会不会引入新的BUG？
会，所以怎么办呢？
- 通过完整的
单元测试保证重构前后的外部可见性一致 - 有条件的话找专业的测试进行
端到端测试和灰度测试
RISK：重构上线带来BUG的风险怎么解决？
如果不通知业务方直接将重构的代码上线，一旦出现问题，你肯定全责并且重构没有功劳也没有苦劳了
- 有条件的话找专业的测试进行端到端测试和灰度测试
- 必须通知业务方并说服业务方同意，让业务方做好准备上线后检查一下。如果真的引入了bug也不太会追责，因为在预期内并且我们的目标也是为了项目的长远发展呀
FEASIBILITY：如何让业务方意识到现阶段重构是必要的并同意？
- 让业务方、产品、测试看到开发中的痛点和技术上的瓶颈
- 让所有人意识到缝缝补补破窗效应导致问题加剧，已经积重难返了
- 强调重构带来的
技术收益和业务收益 - 提供
切实可行并可控的重构计划方案
PERFORMANCE：重构价值不被认可怎么办？
- 明明是你代码写的烂才导致的重构，浪费时间，还有脸要绩效？想屁吃呢
- 承认自己会写bug，表明没有不写bug的程序员（勇于担当并弱化责任，表明
owner身份和地盘） - 指出导致重构的其他原因：需求频繁变更，紧急需求倒排工时，没有将业务长期规划方向信息同步给开发，多人协作团队没有统一风格，团队没有code review，没有eslint规范等等（表明主要责任不在我，但是我
意识到了问题并主动解决了） - 强调重构带来的优点：BUG数量减少，维护成本下降，BUG排查变快，开发速度增高等（
业务价值才是绩效的根本）
- 承认自己会写bug，表明没有不写bug的程序员（勇于担当并弱化责任，表明
(ps：本博客用于学习总结，欢迎友好交流)
