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

WHAT：什么是重构？

• 大型重构
  • 对象：对系统、模块、代码结构、类与类之间的关系等的重构
  • 方法：有分层垂直拆分、模块化水平拆分、解耦、抽象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：本博客用于学习总结，欢迎友好交流)