携手创作，共同成长！这是我参与「日新计划 8 月更文挑战」的第1天，点击查看活动详情

性能和开放是目前钉钉表格比较重要的命题，而随着我们的优化逐渐进入深水区，难免需要对已有的架构做一些手术。下面是我最近在实际开发中，对代码进行重构的一些心得的记录。

第一步：掌握所有相关逻辑

这里的关键是：「掌握」和「所有」。

通常我们说的重构，是不会包含新的 feature 的，只是对已有逻辑实现层面的优化，从「实现 A」变为「实现 B」。因此，「掌握」和「所有」的意思就是要遍历重构部分的代码逻辑以及相关的影响面，具体到每一行相关的代码，要具备对这部分逻辑的掌控感，否则我们很难预测这次改动会对已有功能产生什么影响，真的出现线上问题以后，也很难快速定位。

在实际操作的过程中，可以从以下几个方面入手：

  1. 组件，比如包含的所有状态
  2. 模型的核心逻辑，要重点关注是否依赖了外部 api
  3. 组件的引用，模型的调用，递归地找到并搞清楚所有正在使用的场景

第二步：设计并实现新的代码逻辑

这部分更多地是 case by case 的工作，取决于你的重构目标。有了第一步的工作，这一步会变得很简单。

第三步：删除旧代码

把旧的代码删掉，不要担心这些代码再被需要，绝大多数情况都只会被遗忘然后腐烂，甚至引发更多问题。

不过要注意合理地拆分 commit 和 CR 的粒度，需要的时候能够快速回滚。

第四步：单元测试/E2E/手工测试

测试是重构的底气。在钉钉表格可以通过三种方式来保障重构的可靠性：

  1. 单元测试，核心逻辑完备的单测会给你安全感
  2. E2E，关键链路的端到端测试，会让你大幅减少出现 P0 问题的概率
  3. 根据第一步的工作，梳理详尽的手工测试，尽可能覆盖所有场景，并完成自测。

如果实在没办法做到 1 和 2，也要把第三步给做好。

第五步：代码合入开发主干

经过以上四个步骤，代码层面的工作就基本完成了。接下来就是提交 CR，找到你可能会影响到的功能的 owner，帮你一起 review 一下是否还有遗漏或不合理的改造。当所有人都回复你 LGTM 之后，就可以把代码合入，按照迭代的节奏，完成 BVT，最终上线。

这样一次重构就完成了

好处是什么？

其一，是因为在前期梳理的过程中，我们对细节有了更深的了解。这就意味着新的方案考虑会更周全，从而降低因为某些细节导致修改方案返工的概率。在看起来完成上面这些繁琐的步骤之后，我们的时间其实是被省下来的。

其二，完备的测试环节会大大降低出现线上问题的概率，一旦因为重构导致了线上问题，再去回滚或者 hotfix 消耗的时间都会远远超过写测试的时间，并且测试用例的积累本身也是工程的复利。