专栏首页云前端抽丝剥茧 - 实例简析重构代码的三板斧

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

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/单元测试

本文分享自微信公众号 - 云前端(fewelife),作者:lua

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-01-03

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • [译] 更可靠的 React 组件:清楚易懂的可表达性

    原文摘自:https://dmitripavlutin.com/7-architectural-attributes-of-a-reliable-react-c...

    江米小枣
  • [译] React 中的 dumb 组件和 smart 组件

    原文:https://medium.com/@thejasonfile/dumb-components-and-smart-components-e7b33a6...

    江米小枣
  • [译]: Vue.js 函数式组件:what, why & when?

    原文:https://medium.com/js-dojo/vue-js-functional-components-what-why-and-when-439...

    江米小枣
  • UCLA朱松纯: 正本清源·初探计算机视觉的三个源头、兼谈人工智能

    朱松纯,全球著名计算机视觉专家,统计与应用数学家、人工智能专家。美国洛杉矶加州大学(UCLA)统计系兼计算机系教授、计算机视觉与图像科学中心主任、长江学者、千人...

    马上科普尚尚
  • 开篇-比特币是什么

    Tiny熊
  • Swift教程(五)--控制流

    Swift 提供所有多样化的控制流语句。包括 while 循环来多次执行任务;if , guard 和 switch 语句来基于特定的条件执行不同的代码分支;还...

    roc
  • 硅谷狂人:我从来都不理解为什么需要睡觉

    IT派 - {技术青年圈} 持续关注互联网、大数据、人工智能领域 关注 选择了征途,注定会拼得遍体鳞伤。那些经过无数个夜晚煎熬创造出来的伟大产品,就是战功赫赫...

    IT派
  • React Native智能提示输入框组件

    npm install--save react-native-autocomplete-input

    forrest23
  • Leetcode 69. Sqrt(x)

    版权声明:博客文章都是作者辛苦整理的,转载请注明出处,谢谢! https://blog.csdn....

    Tyan
  • python抓取不得姐动图(报错 urllib.error.HTTPError: HTTP Error 403: Forbidden)

    未来sky

扫码关注云+社区

领取腾讯云代金券