向工程腐化开炮 | 治理思路全解

作者：刘天宇(谦风)

系列文章回顾《向工程腐化开炮 | proguard治理》《向工程腐化开炮 | manifest治理》《向工程腐化开炮：Java代码治理》《向工程腐化开炮｜资源治理》《向工程腐化开炮｜动态链接库so治理》。本文为系列文章最后一篇文章，聚焦于整体治理思路，方案设计，以及背后的思考与取舍。

工程质量是任何一个产品，能够快速、高效、稳定地进行业务功能迭代的基础，也是给用户带来良好产品使用体验不可忽视的因素，更是任何一位优秀工程师的期望和卓越追求。而工程腐化，却是任何一个大型工程都不得不面对的问题，其广泛而细碎，隐藏在不易被察觉的“角落”，对工程方方面面均有所影响。

工程腐化与工程本身相伴相生，贯穿工程生命周期的每一阶段，时间、人、代码、流程、规则，任一因素的变化都会导致腐化发生，从觉察到修补、系统性分析到应对方案制定、再到坦然接受与常态化可持续治理，本文对此逐一道来。

源起

在一个工程趋于成熟之前，腐化问题深深隐藏于代码中，一般会明显降低研发效率，但是引发的线上问题却并不频繁，因此很容易当成单点问题进行修复。但是随着腐化程度加剧，同一类型问题出现的频率越来越高，才逐渐嗅到淡淡的“腐化味道”，也因此才有了后续一系列的分析、方案设计、工具&平台研发，以及治理实践。我们来看下面这张图，可能很多研发同学会有切身感受：

1.1 嗅到腐化味道

笔者在Android架构领域有多年经验，直接负责或者间接参与了稳定性、启动性能、包瘦身、工程效能、新版本os适配等多个方向，随着各治理项的不断深入以及时间的推移，遇到过各种各样的问题，例如：冲突资源导致即使代码无变化，多次构建后的apk中也会出现资源值不一致，最终引发线上问题；java代码修改导致不兼容调用，最终引发线上java异常；线程随意使用，缺乏统一管控，一方面性能堪忧，另一方面过多线程数量超过某些设备的自定义限制，从而引发OOM异常；无用代码&资源&功能模块，导致包体积持续增加；apk构建耗时越来越长，严重影响研发效率；这样的例子，可以举出几十项，此处不再一一赘述。