加入收藏 | 设为首页 | 会员中心 | 我要投稿 南昌站长网 (https://www.0791zz.cn/)- 终端安全、安全管理、数据治理、图像分析、大数据!
当前位置: 首页 > 站长资讯 > 动态 > 正文

一个核心系统 3 万多行代码

发布时间:2020-11-11 14:10:59 所属栏目:动态 来源:互联网
导读:进入到细节实现阶段后,很重要的一点是:对现有逻辑的理解。引擎代码经过一年半的迭代,历史上被很多人开发过,但是本次只有 3 个同学参与重构。 整个过程中,我们遇到任何代码逻辑不明确的地方,都是反复沟通和求证,不主观猜想,这一份谨慎其实很关键。 另

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

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

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

4. 有效的测试方案

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

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

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

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

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

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

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

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

整体节奏的把控

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

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

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

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

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

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

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

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

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

在这样的高要求下,团队产出了 5000 多字的技术方案文档,合计 36 页,这些为整体质量的保障打下了很好的基础。经过梳理,整个引擎有大部分逻辑是可以公用的,因此我们定义了一个主体框架,同时将可扩展部分进行了抽象。这样,各个场景能够根据自身业务的特殊性实现某些公共接口即可。另外,从性能角度考虑,我们牺牲了一些代码可读性,把某些逻辑并行化了。

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

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

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

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

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

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

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

总体来说,这是一次难度颇大并且比较成功的重构项目,下面详细说一下我从这个项目中吸取到的宝贵经验。今年年初,我们团队完成了一个复杂项目的重构工作,它属于广告系统最核心的引擎部分,大概有 300 多个文件,3 万多行代码。

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

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

(编辑:南昌站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读