疲惫的代码迁移
date
Aug 30, 2025
slug
lesson-from-code-rewrite
status
Published
tags
coding
summary
type
Post
最近对一些已经到达不可维护程度的代码进行了迁移，实在是很累。
算是第一次对已经运行很久的核心老代码进行重写。由于对这部分代码已经维护很久时间，我能够比较确定这一部分的缺陷，以及从底层着手改写的必要性。
最明显的缺陷在于耦合太深，这部分代码是一个引擎型的存在，却和具体业务代码交杂不堪，导致无论是引擎本身和业务代码，在体积膨胀到万行的水平时就已经无法继续迭代。此时重写已经势在必行。
引擎最核心的部分本质上是一个自推自取的任务队列，这部分代码非常轻量，重写起来很舒服，很快就搞定了。在写完这部分之后，我试图在短时间内将尽可能多的具体实例迁移到新的引擎之上，虽然知道一次迁移完所有部分是不可能的，但我仍然想看看新引擎在不同实例下的表现是否符合预期。
试着迁移时发现了不少问题，例如在去除基类的存在之后不应该写太多样板代码，样板的部分可以通过工厂函数和精巧的数据结构来减轻工作量与心智负担等。然而这部分浪费了太多时间，因为没有去评估哪些实例需要迁移，哪些实例目前在旧引擎下运转良好未来也大概不会出现新的需求，暂时没什么必要迁移，只是一股脑的10%、20%的给自己排进度条，导致出现了实际进度缓慢，而真正应该做的事情却远没有想象的多。很尴尬的局面QAQ。
同时也因为这部分工作，忽视了引擎的另一核心功能：将进度上报给外部组件以及云端服务器。这个功能看起来并不起眼，却很重要，如果没有做好这一功能，那么迁移完成的实例就不可能部署到生产环境工作，因为这意味着我们的新版本可观测性为0。好在我们在意识到问题后，还算比较顺利的将观测能力兼容性的加入到了新的引擎之中。
说到这里，代码重写比较令人头疼的地方就在于兼容性，老引擎和外部通信的部分新引擎也应当保持兼容，或者选择将与之通信的外部也一并写出两个分岔出来。由于重写改写外部组件同样是需要高度谨慎精心的活儿，目前的时间资源暂时不足以支撑，我们最终选择让新引擎看起来丑一点，也要将兼容的责任完全压在引擎内部。