你好，我是小树。这是我为你写的第 24 封信。每期都会同步更新在微信公众号一颗小树和竹白专栏。现在有 79 位朋友订阅了这封信，也欢迎你邮件订阅，第一时间收到更新推送。
性能和开放是目前钉钉表格比较重要的命题，而随着我们的优化逐渐进入深水区，难免需要对已有的架构做一些手术。下面是我最近在实际开发中，对代码进行重构的一些心得的记录。
这里的关键是：「掌握」和「所有」。
通常我们说的重构，是不会包含新的 feature 的，只是对已有逻辑实现层面的优化，从「实现 A」变为「实现 B」。因此，「掌握」和「所有」的意思就是要遍历重构部分的代码逻辑以及相关的影响面，具体到每一行相关的代码，要具备对这部分逻辑的掌控感，否则我们很难预测这次改动会对已有功能产生什么影响，真的出现线上问题以后，也很难快速定位。
在实际操作的过程中，可以从以下几个方面入手：
这部分更多地是 case by case 的工作，取决于你的重构目标。有了第一步的工作，这一步会变得很简单。
把旧的代码删掉，不要担心这些代码再被需要，绝大多数情况都只会被遗忘然后腐烂，甚至引发更多问题。
不过要注意合理地拆分 commit 和 CR 的粒度，需要的时候能够快速回滚。
测试是重构的底气。在钉钉表格可以通过三种方式来保障重构的可靠性：
如果实在没办法做到 1 和 2，也要把第三步给做好。
经过以上四个步骤，代码层面的工作就基本完成了。接下来就是提交 CR，找到你可能会影响到的功能的 owner，帮你一起 review 一下是否还有遗漏或不合理的改造。当所有人都回复你 LGTM 之后，就可以把代码合入，按照迭代的节奏，完成 BVT，最终上线。
这样一次重构就完成了👏
其一，是因为在前期梳理的过程中，我们对细节有了更深的了解。这就意味着新的方案考虑会更周全，从而降低因为某些细节导致修改方案返工的概率。在看起来完成上面这些繁琐的步骤之后，我们的时间其实是被省下来的。
其二，完备的测试环节会大大降低出现线上问题的概率，一旦因为重构导致了线上问题，再去回滚或者 hotfix 消耗的时间都会远远超过写测试的时间，并且测试用例的积累本身也是工程的复利。
后面几天要去潮汕团建，所以这周就提前发出来了。好久没出过京了，对这趟旅程还是非常期待的，夏天和大海就是最配的！
谢谢你的关注，我们下期再见。👋🏻
你也可以在这里找到我：即刻、Twitter、微信公众号一颗小树。
这里是小树的 newsletter。 每周一发布，欢迎订阅。 如果你觉得这篇文章对你有用，欢迎分享给更多好友。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。