01 先聊聊这个系统的历史包袱
我们的广告引擎在这次重构前大概经历了1年半时间的迭代，初期针对的是搜索场景，业务单一，流程清晰。
转机出现在 2019 年年底，由于广告业务的特殊性，流量开始自然走低，另外产品运营团队将重心放在了第 2 年的工作规划上，因此给了我们非常好的窗口期开始此次重构。
我们将工期定成了 1 个月，最终仅比预期晚上线了一天，虽然出现了两个线上问题，但是在灰度期都及时发现和修复了，并没有造成线上事故。
02 重构前，我们做了哪些准备工作？
这次重构的代码量很大，3 万多行，而且是广告系统最核心的引擎部分。启动前，我们能预期到下面这些困难：
1、业务侧的阻力：广告是极其以业务为导向的，本次重构虽然能带来长期研发效率的提升，但是没法直接提升业务收益，而且开发周期不会太短，如何才能得到业务同学的支持？
▍让所有人看到痛点
前面提到：随着业务迭代，我们广告引擎的主体框架已经变得模糊不清，另外几十个广告策略散落在不同的业务场景中，配置凌乱。
针对这两个痛点，我们提前1个月启动了现有业务的梳理，走读旧代码、同时翻阅以前的需求文档，最终我们将不同场景的核心流程以及广告策略归类成了一张清晰的表格。
正是这一张表格，让技术和产品第一次很清晰地看到了我们引擎部分的全貌，体会到了业务的复杂度以及当前技术上的瓶颈。
▍明确重构的目标和价值
让所有人感受到痛点后，我们规划了本次重构的两个核心目标：
此外，我们将这两个核心目标完成后可带来的预期收益进行了细化：
▍整体节奏的把控
整体节奏的把控也是非常重要的一环，能让所有人对这件事情有一个时间上的预期。
首先，我们将工期定成了 1 个月，一方面考虑了业务侧可以接受的最大周期，技术上也希望速战速决；另一方面，春节即将来临，我们必须赶在公司封网前上线，同时预留出1-2周的 buffer 以防意外情况发生。
03 执行过程中有哪些可分享的经验？
1. 高质量的技术设计方案
这一点得益于日常的要求，针对开发周期超过3天的项目我们都会进行技术方案设计，本次重构当然也不例外。
框架部分的整体架构、模块之间的协议设计、以及策略的可扩展性设计是本次技术方案的重点，团队前后讨论了不下3次。
在大方案定稿后，团队进一步对数据库、接口字段、缓存结构、日志埋点等公共部分进行了细化，因为涉及到多人协作开发，团队约定以文档作为沟通界面，文档始终保持和代码同步。
2. 预重构出框架性代码
这一个 PR 非常关键，是我们从技术方案落地到代码最重要的一步。我们把重构后的包结构、模块划分、各层之间的API定义、不同广告策略的抽象进行了梳理，先忽略实现的细节。
这样主体代码基本成型，能很清楚地描绘出我们理想中的框架。然后，我们组织了多次集中代码审查，最终形成了统一意见。
这一步能很好地避免过早陷入实现细节，导致主体框架关注不够、代码不稳固，后期再返工反而会拖累效率。
3. 频繁沟通和成对代码 Review 机制
进入到细节实现阶段后，很重要的一点是：对现有逻辑的理解。引擎代码经过一年半的迭代，历史上被很多人开发过，但是本次只有 3 个同学参与重构。
整个过程中，我们遇到任何代码逻辑不明确的地方，都是反复沟通和求证，不主观猜想，这一份谨慎其实很关键。
另外在代码审查上，我们按模块分配了对这块业务比较熟悉的同学来负责，成对搭配，机制灵活。
4. 有效的测试方案
重构未动，测试先行。这个原则是《重构》一书中重点强调的，也是我们本次技术方案讨论的重点，我这里单独拎出来详细展开下。
首先，我们前期便约定好：不动任何老代码，完全建新的 package 进行重构。这样方便比对重构前后的结果，同时进行线上灰度实验。
测试方案上，以下 4 点值得借鉴：
写在最后
回顾整个重构的过程，总结成下面 7 个关键点：
7、小心求证，为每行代码负责
当然，最关键的因素还是人，大型项目重构极其考验团队的协作能力，如果每个人都很靠谱，重构就已经成功了一半。
以上就是硬核干货：一个核心系统 3 万多行代码的重构之旅的详细内容，更多请关注Work网其它相关文章！