大厂代码重构最佳实践，你真的会代码重构吗？

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排查变快，开发速度增高等（业务价值才是绩效的根本）

(ps：本博客用于学习总结，欢迎友好交流)