抽丝剥茧 - 实例简析重构代码的三板斧

1,221 阅读6分钟

I. 太阳之下无新事:如何面对既有代码

既有代码

可以说,任何软件系统从设计部署好的第二天起,就都变成了 既有代码(existing code)。一个几年的系统和一个几周的系统中存在的问题,并无本质上的差异。

俗话说,创业容易守业难。比新搭建一个系统更常见的工作,正是对既有系统的日常维护,一般包括:

  • 添加新特性
  • 修正bug
  • 优化设计和性能

如何有效进行这些工作,而不是陷入“修复一个bug,还你几个新bug”的恶性循环,是每个开发者必然面对的课题。

遗留代码

既有代码的一种极端情况,就 是遗留代码(legacy code),一般指那些无人再维护的,或架构非常过时,亦或运行在老旧的操作系统上的代码。

相比于在大抵上每几天就打个照面的既有代码中修修改改;当面对一头雾水的遗留代码时,如果没有正确的方法,即便再小心翼翼,也总会陷入束手无策的境地。

II. 既有代码的困境

每个开发者可能都见过奇奇怪怪的各种具体问题,但归纳起来,主要有这么三种情况:

  • 过重的依赖:实例化或方法调用的过程中,过多过深的依赖于其他类或组件
  • 错误的封装:类或组件承担了不应有或过多的功能
  • 裸奔的功能:没有测试代码或过时、不完整的测试覆盖

III. 重构的意义

面对以上困境,需要做的就是重构:

在不改变代码功能的前提下,改善其设计的行为被称为 重构(refactor)

重构的意义:使既有代码更具可维护性,并消除其不确定性

重构的关键:在其过程中不应该有任何功能上的改变

在之前提到过的几种日常工作中,无一例外不需要先进行有效的重构,才能保证工作的顺利进行。

IV. 重构三板斧:解开依赖、合理封装、测试覆盖

同样显而易见的是,将三重困境一一化解,就可以达到理想的重构:

  1. 依赖:

    • 简化导致逻辑复杂的过重依赖,将关注点从散布在艰深冗长的调用链条中拉回来
    • 设置setter方法或借鉴interface的思路等,解决由于关联了太多其他类或组件,从而无法在测试用例中实例化和调用方法的问题
  2. 封装:

    • 类或组件只应该承担尽量简单而少量的职责,过长的类或组件应抽取成多个
    • 类或组件不应当包含其子层级或兄弟层级的逻辑
    • 出现在多处的重复代码总是可疑的,应该尽量抽象和提取出来
  3. 测试:

    • 测试的作用就是检验正确性和检验变化
    • 回归测试(regression testing):周期性的运行测试,来检验已知的良好行为是否依然正常工作。
    • 单元测试(unit testing):是指对软件中的最小可测试单元进行检查和验证;在 JS 中“单元”一般可以认为是一个函数或一个类。
    • 测试用例(test case):就是设定输入数据,运行被测试函数,然后判断实际输出是否符合预期

简而言之,前两项是最后“落在实处”的工作,而测试的重要性并不亚于任何工作,甚至是保证前两项进行下去的关键。 **测试覆盖率(test coverage)**越高,说明所覆盖部分的可靠性越有保证,而不必时时担心改动带来的未知影响。

遵循为独立单元(视情况为函数、类或组件等)编写测试的理念,就可以写出小而易理解的一个个测试用例,也反过来使得代码比写注释更容易理解。

对于新开发的功能,可以用测试驱动开发(TDD)的方法,即重复“写一点代码->编写测试->失败->修改代码->测试通过”的过程,最终达到方法的完成。

对于既有代码,可以根据日常需求,对涉及到的部分逐步引入单元测试,持续不断的提高系统的测试覆盖率。

V. 一个stepper组件的重构实例

这里举一个足够简单也比较典型的例子:重构stepper组件

场景描述:

在这个由 react 组件构建的既有系统中,在若干界面中都引用了一个常见的 数字选择器(numeric stepper),其变化会触发判断逻辑,提示商品对应的数量是否有足够库存、是否达到了限购数量等

既有的结构和问题:

  • “全局”组件NumberStepper里糅杂了具体业务逻辑“限购”和“库存”的判断
  • 以上判断逻辑冒泡到各种容器组件中,“演化”出了同一函数的不同签名形式 -- 梳理后发现:虽然参数定义不同且含糊不清,实际要达成的逻辑却是一样的
  • 相关的逻辑判断代码和弹窗jsx结构,均重复出现于不同组件中
  • NumberStepper和各种容器组件中,均分别存在用 0|1|2|3 定义的判断和显示逻辑,且无注释说明

问题的分解:

困境 问题A 问题B 问题C
依赖过重
封装错误
缺乏测试

问题的解决:

  • 在测试的保护下,将NumberStepper中的具体业务逻辑依赖删除
  • NumberStepper暴露props.checkLimit,在数量增减时响应,将判断逻辑交给调用者
  • 统一判断逻辑onLimitOver的函数签名,明确参数的意义
  • 将展现部分的逻辑和界面分别提取为单一的部分,统一调用
  • 将之前用数字区分的逻辑归纳成常量类,交由各处统一调用
  • NumberStepperOverLimit等组件编写测试,保证改动的全面和正确性

VI. 总结

至此,之前的结构得到了有效的梳理;再进行相关的功能添加就有章可循、心中有数了。

  • 处理大部分“添加新特性、修正bug和优化”类的日常工作时,需要科学具体的方法论
  • 过重的依赖、错误的封装、缺少测试,是既有代码的常见问题
  • 有针对性的从以上三个方面入手,并辅以必要的单元测试,就可以保证工作有条理的进行下去

VII. 参考资料

  • https://book.douban.com/subject/2248759/
  • https://en.wikipedia.org/wiki/Legacy_code
  • https://www.tuicool.com/articles/3QRBRr
  • https://baike.baidu.com/item/单元测试


(end)


长按二维码或搜索 fewelife 关注我们哦