实战篇:一个核心系统 3 万行代码的重构之旅

2023-11-06 18:30

本文主要是介绍实战篇:一个核心系统 3 万行代码的重构之旅,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

经典著作《重构》这本书中有这么一段话:

一开始,我所做的重构都停留在细枝末节上。随着代码趋向简洁,我发现自己可以看到一些设计层面的东西了,这些是我以前理解不到的,如果没有重构,我达不到这种高度。

重构,着实是一件让程序员兴奋的事情。

今年年初,我们团队完成了一个复杂项目的重构工作,它属于广告系统最核心的引擎部分,大概有 300 多个文件,3 万多行代码。

从技术方案设计到最终全量上线仅仅花了 1 个月左右的时间,而且没有产生事故。

这应该是我 8 年程序生涯中,经历过的最大型的同时最成功的一次重构项目:速度足够快、计划比较周全、质量过关。

 

01 先聊聊这个系统的历史包袱

我们的广告引擎在这次重构前大概经历了1年半时间的迭代,初期针对的是搜索场景,业务单一,流程清晰。

2019年开始,公司的广告业务开始快速扩张,收入几乎是指数级的增长。在这个过程中,我们的广告引擎面临了两个挑战:

1、业务场景开始变得复杂,除了搜索广告,还需要支持信息流推荐以及相似推荐场景。

2、广告流量开始快速增加,除了满足功能性需求,还需要兼顾好性能。

经过梳理,整个引擎有大部分逻辑是可以公用的,因此我们定义了一个主体框架,同时将可扩展部分进行了抽象。这样,各个场景能够根据自身业务的特殊性实现某些公共接口即可。另外,从性能角度考虑,我们牺牲了一些代码可读性,把某些逻辑并行化了。

随着业务的发展,搜索场景开始进入快速迭代期,新增策略越来越多,我们的主体框架也是在这个时候逐渐变得不灵活。

如果动主体框架,搜索以外的场景都需要跟着重构。 在业务的快速发展期,工期根本不允许,因此我们只能在现有框架上进行补丁式的开发。 这样,带来了两个很明显的问题:

1、为了兼容搜索的特殊逻辑,我们需要在其他场景中增加各种 if 判断来绕过这些逻辑。

2、广告策略越来越多,累计了几十个,当框架失去清晰的结构后,有些策略的实现开始变得定制化,缺少层次化的划分和可插拔式的抽象设计。

在这样的背景下,随着改动的积累,代码开始偏离了设计的初衷,技术债务越来越重。但是,我们又始终找不到合适的时机进行重构。

转机出现在 2019 年年底,由于广告业务的特殊性,流量开始自然走低,另外产品运营团队将重心放在了第 2 年的工作规划上,因此给了我们非常好的窗口期开始此次重构。

我们将工期定成了 1 个月,最终仅比预期晚上线了一天,虽然出现了两个线上问题,但是在灰度期都及时发现和修复了,并没有造成线上事故。

总体来说,这是一次难度颇大并且比较成功的重构项目,下面详细说一下我从这个项目中吸取到的宝贵经验。

 

02 重构前,我们做了哪些准备工作?

这次重构的代码量很大,3 万多行,而且是广告系统最核心的引擎部分。启动前,我们能预期到下面这些困难:

1、业务侧的阻力:广告是极其以业务为导向的,本次重构虽然能带来长期研发效率的提升,但是没法直接提升业务收益,而且开发周期不会太短,如何才能得到业务同学的支持?

2、技术侧的顾虑 :重构一旦引起线上事故,公司是有处罚制度的,如何让大家轻装上阵?同时,重构过程中如果还有非常重的业务迭代穿插,交付时间没人敢保证,质量也很难得到控制。

针对这两方的顾虑,我认为下面这几项工作起到了很关键的作用。

 

1、让所有人看到痛点

前面提到:随着业务迭代,我们广告引擎的主体框架已经变得模糊不清,另外几十个广告策略散落在不同的业务场景中,配置凌乱。

针对这两个痛点,我们提前1个月启动了现有业务的梳理,走读旧代码、同时翻阅以前的需求文档,最终我们将不同场景的核心流程以及广告策略归类成了一张清晰的表格。

正是这一张表格,让技术和产品第一次很清晰地看到了我们引擎部分的全貌,体会到了业务的复杂度以及当前技术上的瓶颈。

 

2、明确重构的目标和价值

让所有人感受到痛点后,我们规划了本次重构的两个核心目标:

1、主体框架的重构:将主流程模块化,重新定义上下层协议,确保接口清晰;各层级内部也需要做好抽象,具备良好的扩展性。

2、策略灵活可配置:将广告策略按照业务意图进行归类抽象,策略的执行条件动态可配置,同时策略可任意插拔。

此外,我们将这两个核心目标完成后可带来的预期收益进行了细化:

1、技术收益:代码结构更清晰,更容易理解和维护;可扩展性增强,引擎的开发效率将进一步提升。

2、业务收益:策略能做到更细粒度的配置和扩展,对业务支持更友好;研发提效后能进一步加快业务的迭代速度。

将重构的价值同步给大家后,进一步提升了所有人的兴奋度,让大家有了更强的动力参与进来。

 

3、整体节奏的把控

整体节奏的把控也是非常重要的一环,能让所有人对这件事情有一个时间上的预期。

首先,我们将工期定成了 1 个月,一方面考虑了业务侧可以接受的最大周期,技术上也希望速战速决;另一方面,春节即将来临,我们必须赶在公司封网前上线,同时预留出1-2周的 buffer 以防意外情况发生。

此外,我们和业务侧达成了一致:重构期间,引擎部分的非紧急需求一律不接,这样可最大限度地减少并行开发和代码冲突,让团队精力更集中。

 

 

03 执行过程中有哪些可分享的经验?

这次重构能够实施得如此顺利,有 4 点我认为很有价值的经验跟大家分享下。

 

1、高质量的技术设计方案

这一点得益于日常的要求,针对开发周期超过3天的项目我们都会进行技术方案设计,本次重构当然也不例外。

框架部分的整体架构、模块之间的协议设计、以及策略的可扩展性设计是本次技术方案的重点,团队前后讨论了不下3次。

在大方案定稿后,团队进一步对数据库、接口字段、缓存结构、日志埋点等公共部分进行了细化,因为涉及到多人协作开发,团队约定以文档作为沟通界面,文档始终保持和代码同步。

在这样的高要求下,团队产出了 5000 多字的技术方案文档,合计 36 页,这些为整体质量的保障打下了很好的基础。

 

2、 预重构出框架性代码

这一个 PR 非常关键,是我们从技术方案落地到代码最重要的一步。我们把重构后的包结构、模块划分、各层之间的API定义、不同广告策略的抽象进行了梳理,先忽略实现的细节。

这样主体代码基本成型,能很清楚地描绘出我们理想中的框架。然后,我们组织了多次集中代码审查,最终形成了统一意见。

这一步能很好地避免过早陷入实现细节,导致主体框架关注不够、代码不稳固,后期再返工反而会拖累效率。

 

3、 频繁沟通和成对代码 Review 机制

进入到细节实现阶段后,很重要的一点是:对现有逻辑的理解。引擎代码经过一年半的迭代,历史上被很多人开发过,但是本次只有 3 个同学参与重构。

整个过程中,我们遇到任何代码逻辑不明确的地方,都是反复沟通和求证,不主观猜想,这一份谨慎其实很关键。

另外在代码审查上,我们按模块分配了对这块业务比较熟悉的同学来负责,成对搭配,机制灵活。

 

4、 有效的测试方案

重构未动,测试先行。这个原则是《重构》一书中重点强调的,也是我们本次技术方案讨论的重点,我这里单独拎出来详细展开下。

首先,我们前期便约定好:不动任何老代码,完全建新的 package 进行重构。这样方便比对重构前后的结果,同时进行线上灰度实验。

测试方案上,以下 4 点值得借鉴:

1、端到端测试:本次重构不涉及功能性的调整,因此外层API的行为是不会有任何变化的,这样端到端的测试方法最为有效,这个是研发和QA测试最主要的手段。

2、冒烟测试:QA同学提供冒烟 Case,由研发同学进行冒烟,研发提测前必须保证所有冒烟 Case 执行通过。这一点在大部分互联网公司都不常见,但是对于大型项目绝对有效。

3、沙箱环境双流程验证:前面提到我们重构前后的代码都保留了,因此可以通过脚本抓取线上环境的入参作为case,然后用自动化的方式对 API 的返回字段进行逐一比对。

4、线上环境灰度实验:灰度对于重构非常重要,我们利用已有的ABTest平台,逐步放开灰度流量,从5%、到10%、到30%、最后到100%,制定了很谨慎的放量节奏,然后通过日志以及业务指标监控进行验证。

 

写在最后

回顾整个重构的过程,总结成下面 7 个关键点:

1、把握好重构时机

2、前期梳理很重要,先找到痛点

3、明确出目标和价值,让大家兴奋起来

4、不宜长线作战,不宜和业务并行

5、需要高质量的技术方案

6、重构未动,测试先行

7、小心求证,为每行代码负责

当然,最关键的因素还是人,大型项目重构极其考验团队的协作能力,如果每个人都很靠谱,重构就已经成功了一半。

 

作者简介:985硕士,前亚马逊工程师,现58转转技术总监,欢迎关注我的个人公众号:IT人的职场进阶

这篇关于实战篇:一个核心系统 3 万行代码的重构之旅的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/358306

相关文章

不懂推荐算法也能设计推荐系统

本文以商业化应用推荐为例,告诉我们不懂推荐算法的产品,也能从产品侧出发, 设计出一款不错的推荐系统。 相信很多新手产品,看到算法二字,多是懵圈的。 什么排序算法、最短路径等都是相对传统的算法(注:传统是指科班出身的产品都会接触过)。但对于推荐算法,多数产品对着网上搜到的资源,都会无从下手。特别当某些推荐算法 和 “AI”扯上关系后,更是加大了理解的难度。 但,不了解推荐算法,就无法做推荐系

基于人工智能的图像分类系统

目录 引言项目背景环境准备 硬件要求软件安装与配置系统设计 系统架构关键技术代码示例 数据预处理模型训练模型预测应用场景结论 1. 引言 图像分类是计算机视觉中的一个重要任务,目标是自动识别图像中的对象类别。通过卷积神经网络(CNN)等深度学习技术,我们可以构建高效的图像分类系统,广泛应用于自动驾驶、医疗影像诊断、监控分析等领域。本文将介绍如何构建一个基于人工智能的图像分类系统,包括环境

水位雨量在线监测系统概述及应用介绍

在当今社会,随着科技的飞速发展,各种智能监测系统已成为保障公共安全、促进资源管理和环境保护的重要工具。其中,水位雨量在线监测系统作为自然灾害预警、水资源管理及水利工程运行的关键技术,其重要性不言而喻。 一、水位雨量在线监测系统的基本原理 水位雨量在线监测系统主要由数据采集单元、数据传输网络、数据处理中心及用户终端四大部分构成,形成了一个完整的闭环系统。 数据采集单元:这是系统的“眼睛”,

Andrej Karpathy最新采访:认知核心模型10亿参数就够了,AI会打破教育不公的僵局

夕小瑶科技说 原创  作者 | 海野 AI圈子的红人,AI大神Andrej Karpathy,曾是OpenAI联合创始人之一,特斯拉AI总监。上一次的动态是官宣创办一家名为 Eureka Labs 的人工智能+教育公司 ,宣布将长期致力于AI原生教育。 近日,Andrej Karpathy接受了No Priors(投资博客)的采访,与硅谷知名投资人 Sara Guo 和 Elad G

嵌入式QT开发:构建高效智能的嵌入式系统

摘要: 本文深入探讨了嵌入式 QT 相关的各个方面。从 QT 框架的基础架构和核心概念出发,详细阐述了其在嵌入式环境中的优势与特点。文中分析了嵌入式 QT 的开发环境搭建过程,包括交叉编译工具链的配置等关键步骤。进一步探讨了嵌入式 QT 的界面设计与开发,涵盖了从基本控件的使用到复杂界面布局的构建。同时也深入研究了信号与槽机制在嵌入式系统中的应用,以及嵌入式 QT 与硬件设备的交互,包括输入输出设

JAVA智听未来一站式有声阅读平台听书系统小程序源码

智听未来,一站式有声阅读平台听书系统 🌟 开篇:遇见未来,从“智听”开始 在这个快节奏的时代,你是否渴望在忙碌的间隙,找到一片属于自己的宁静角落?是否梦想着能随时随地,沉浸在知识的海洋,或是故事的奇幻世界里?今天,就让我带你一起探索“智听未来”——这一站式有声阅读平台听书系统,它正悄悄改变着我们的阅读方式,让未来触手可及! 📚 第一站:海量资源,应有尽有 走进“智听

活用c4d官方开发文档查询代码

当你问AI助手比如豆包,如何用python禁止掉xpresso标签时候,它会提示到 这时候要用到两个东西。https://developers.maxon.net/论坛搜索和开发文档 比如这里我就在官方找到正确的id描述 然后我就把参数标签换过来

poj 1258 Agri-Net(最小生成树模板代码)

感觉用这题来当模板更适合。 题意就是给你邻接矩阵求最小生成树啦。~ prim代码:效率很高。172k...0ms。 #include<stdio.h>#include<algorithm>using namespace std;const int MaxN = 101;const int INF = 0x3f3f3f3f;int g[MaxN][MaxN];int n

【区块链 + 人才服务】可信教育区块链治理系统 | FISCO BCOS应用案例

伴随着区块链技术的不断完善,其在教育信息化中的应用也在持续发展。利用区块链数据共识、不可篡改的特性, 将与教育相关的数据要素在区块链上进行存证确权,在确保数据可信的前提下,促进教育的公平、透明、开放,为教育教学质量提升赋能,实现教育数据的安全共享、高等教育体系的智慧治理。 可信教育区块链治理系统的顶层治理架构由教育部、高校、企业、学生等多方角色共同参与建设、维护,支撑教育资源共享、教学质量评估、

软考系统规划与管理师考试证书含金量高吗?

2024年软考系统规划与管理师考试报名时间节点: 报名时间:2024年上半年软考将于3月中旬陆续开始报名 考试时间:上半年5月25日到28日,下半年11月9日到12日 分数线:所有科目成绩均须达到45分以上(包括45分)方可通过考试 成绩查询:可在“中国计算机技术职业资格网”上查询软考成绩 出成绩时间:预计在11月左右 证书领取时间:一般在考试成绩公布后3~4个月,各地领取时间有所不同