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

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的函数签名，明确参数的意义
• 将展示部分的逻辑和界面分别提取为单一的部分，统一调用
• 将以前用数字区分的逻辑概括成常量类，交由各处统一调用
• 为NumberStepper和OverLimit等组件编写测试，保证改动的全面和正确性

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 关注咱们哦