一颗小树 #24 代码重构的一点心得

你好,我是小树。这是我为你写的第 24 封信。每期都会同步更新在微信公众号一颗小树竹白专栏。现在有 79 位朋友订阅了这封信,也欢迎你邮件订阅,第一时间收到更新推送。

代码重构的一点心得

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

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

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

通常我们说的重构,是不会包含新的 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 消耗的时间都会远远超过写测试的时间,并且测试用例的积累本身也是工程的复利。

碎碎念

后面几天要去潮汕团建,所以这周就提前发出来了。好久没出过京了,对这趟旅程还是非常期待的,夏天和大海就是最配的!

谢谢你的关注,我们下期再见。👋🏻


往期推荐

你也可以在这里找到我:即刻Twitter、微信公众号一颗小树

这里是小树的 newsletter。 每周一发布,欢迎订阅
如果你觉得这篇文章对你有用,欢迎分享给更多好友。