阅读 6120

大厂代码重构最佳实践,你真的会代码重构吗?

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:本博客用于学习总结,欢迎友好交流)

文章分类
前端
文章标签