原文标题:精简代码实战:核心系统缩减80%代码
原文作者:阿里云开发者
冷月清谈:
-
文章提出通过“代码精简”来解决提高代码质量的问题,并给出了代码精简实践方案三步法:决策、投入、风险。
-
在决策难方面,给出了用流量统计来评估系统中有效代码占比的方法,当有效代码占比低于10%时,适合开展代码精简。
-
在投入高方面,介绍了一种“函数称重”的方法,它通过对不同函数被调用的次数进行统计,可以量化评估每一个函数的重要性程度,提高代码走读效率。
-
在风险高方面,提出了一系列质量保障策略,包括回归,灰度,压测,演练等。
怜星夜思:
2、在代码走读过程中,除了函数权重之外,还有哪些因素需要考虑?
3、精简代码需要注意哪些风险?
原文内容
阿里妹导读
背景
“代码的阅读时间比写代码的时间多十倍以上。所以,让代码易于阅读至关重要。” --Robert C. Martin
方案
1. 决策难
Fowler、Bob大叔等人都在强调要重构、要优化系统代码。
但要是问他们:什么时候应该优化?
估计他们会答:任何时候。
问他们:优化能带来哪些好处?
2. 投入高
20世纪初,福特公司有一台电机出了问题,导致整个车间生产停转,大批内部工人、专家反复查看都无法找到原因。后来,公司请来了斯坦门茨。斯坦门茨仔细检查了电机,然后用粉笔在电机外壳画了一条线,对工作人员说:“打开电机,在记号处把里面的线圈减少16圈。”人们照办了,令人惊异的是,故障竟然排除了!生产立刻恢复了!福特公司经理问斯坦门茨要多少酬金,斯坦门茨说:“不多,只需要1万美元。”1万美元?就只简简单单画了一条线!斯坦门茨看大家迷惑不解,转身开了个清单:画一条线,1美元;知道在哪儿画线,9999美元。
3. 风险高
-
天启用例不能直接使用,需要人工修复流量、mock子调用、mock配置等。而这部分的复杂度极高,导致ROI极低,我们最终放弃了天启回归方案。进一步,引发了回归覆盖的挑战。
-
新系统,新的配置,需要专门验证。对于一个演进多年的系统,往往有大量的switch, diamond配置,如何高效的验证是一个难题。
-
新建的部署结构,重点关注高可用风险,性能、限流、单元化等。
关键难点和风险
|
质量策略
|
开发迁移成本高!
alsc-pc代码量多(70+w行)、通过人工评估方式迁移成本极高,可能存在功能迁移遗漏风险。
|
通过 函数称重工具 辅助进行代码精简评估和函数能力评估。
|
测试成本高!
全量业务迁移,接口数量多,涉及全量券类活动,影响券生命周期全链路,评估不全会带来接口不可用、资源不可用的风险。
|
通过 全面的回归和校验能力 进行质量保障
|
新老配置一致性风险
一期迁移switch、不迁移diamond配置,二期diamond配置迁移至switch,可能会存在配置遗漏。
|
通过 配置一致性检测能力 进行新老服务switch、diamond配置保障,通过配置变更流水线保证变更的感知和新老同步。
|
资金安全风险
新服务监控、核对配置不完全,存在资损问题遗漏风险。
|
借助 VIP mock和异常注入的功能:
|
高可用风险
新服务的熔断限流、单元化、服务&db性能均可能出现风险问题。
|
通过 压测 进行性能和高可用配置合理性评估,重点关注单元化和容灾切流。
|
由于灰度、压测、演练等各个保障手段,有已经有大量的文章专门介绍,不再具体展开。万象仿真是基于场景的E2E回归方案,场景背后是DB数据特征抽取;配置一致性检测,是一个繁锁和重复的过程,我们沉淀了镜铃平台;VIP已经是一个老朋友了,由于其能力在持续演进,跟文章中描述已经是面目全非了,计划“重构”文章中。
"任何值得追求的目标都会涉及风险。成功的关键是学会管理风险,而不是回避它。" --赫伯特·欧特尔
后记