质量与效率：POP平台代码质量提升计划总结

Posted 2021-05-02 咚咚小报

截止2017年3月31日晚上8点10分，POP平台已经持续5个月的代码质量提升计划终于取得了里程碑式的进展。重要性较高的92个应用，去重后有72个代码库，总代码行数270多万，所有代码违规清理完毕；13个研发团队历时100多天，共修复代码违规1678个，几乎POP平台内部所有的研发人员都参与到其中来了。

 

回顾过去

时间倒退回2015年，大家可以看到下图中的一组历史数据，在公司质量部每周发送的各部门代码质量周报中，POP研发部门的数据排位是倒数的。

效率与质量

大家都知道京东的业务发展速度是非常快的，那么从2010年开始上线的POP开放平台作为京东业务快速发展的一个重要推动力，业务规模的增长速度也是日新月异的，后台系统的数量和规模也随之不断的增加。

 

都说效率与质量是有些对立性的。为了实现快速的迭代，尽早上线新的系统或者新的功能给运营人员或者商家所使用，研发兄弟们一直保持着非常高负荷的工作在奋力拼搏着。那么这种情况下是不是就可以不用考虑质量了呢，何况是代码的质量，是在软件内部的，除了研发人员自己以外别人都看不到的，是不是就可以不必关注了呢？

 

答案必然是否定的，很多常见的线上问题，往往都是由于一些小小的细节没有处理好而引起的。比如说一些硬编码、错误的配置文件、没判空所引起的空指针异常等等；当然还有一些刚刚入职的新人会由于缺乏经验引入一些低级的错误；等等这些所谓的小问题，都有可能在关键时刻引发雪崩似的反应。

 

自动代码扫描

那么前面也提到了数据排名的靠后，还有代码质量的重要性。那么我们如何去做呢，如何提高代码质量呢？当然最优的方法是一开始就写出优质的代码，这可能对于普通研发人员的要求会相对高一些；那么退而求其次的方法就是尽早发现一些存在问题的代码，并把它修改掉。

那么就可以通过代码评审的方式来及早发现有问题的代码，但是也有很多研发人员反映说代码评审有些痛点：一是常常没时间，二是好不容易有时间评审了，却发现在评一些低级的错误上浪费了好多时间，筋疲力尽后才发现没有太多精力去关注更加重要的一些架构设计和业务逻辑等等。

 

那么有没有什么办法在评审之前先过滤掉一些低级的代码违规呢？那么我们就可以使用自动代码审查的方式来实现，通过代码规则的设定，在研发人员提交代码后的第一时间去扫描代码从而发现一些基础的和低级的代码违规，为后面的评审流程和上线流程增加一层过滤网。

 

质量基线

引入了自动代码扫描机制以后，有很多的代码违规就浮出水面了。上千的代码违规，如果让研发人员去一下子修改完成，那是很难实施的。因为本来大家已经发条上得紧紧地，又增加那么多工作量，而且刚一开始可能有些问题还不知道如何修改，也不知道工具如何使用，会严重打击大家的积极性，甚至还可能会影响系统的现有质量。

 

那么很好的一个办法就是设置代码质量基线。从当前时间点开始，只保证不引入新的代码违规，可以不处理老的代码违规。这样还能避免一些经验不足的研发人员在修改老代码时不小心踩雷。

 

彻底清扫代码违规

从一开始引入自动代码扫描，到开始设置基线，逐渐在POP内部所有团队都开始实施起来了。将近两年的时间过去了，到2016下半年，POP平台的代码质量数据排位早已经从倒数变成了正数第一。研发人员已经逐渐适应了自动代码扫描机制，代码质量意识也渐渐地融入到每个人的日常工作中。

 

要继续维持现状，还是啃一啃硬骨头，清理掉埋藏在这270多万行代码中的遗留的大量违规和技术债。我们的总监彪哥和各个研发团队的负责人都非常支持对代码违规进行彻底清扫，都一致认为应该清理历史技术债务，轻装上阵，为研发系统的中台策略转型奠基，为POP平台所支撑业务的蓬勃发展提供稳固的技术支撑。那么就在测试与质量管理组负责人琪哥的引导和推动下开展了为期3个多月的代码违规清扫工作。

第一阶段

万事开头都挺难，虽然制定目标的时候雄心万丈，可是具体到研发人员实施起来，还是有些困难的。POP平台全量应用有200来个，是选择分批清理呢还是选择一次性清理呢？如果是分批清理的话，是按照什么维度分批呢？先清理部分应用还是先清理全量应用的部分重要的违规？先在一部分团队施行还是所有团队都开始施行呢？

 

这个时候我们的研发架构师华哥、阿良和强哥提出了先从一部分应用开始实施清理。挑选出了重要程度最高的一批应用，那就是天工计划项目中正在开发阶段的一些新man端，还有POP平台的一些最核心的中心系统。开发这些重要系统和应用的研发人员都是各团队的核心骨干，代码质量意识本身就比较高，后来事实证明第一批的应用选择是非常明智和正确的。历时20天左右就完成了第一阶段的目标。

 

期间我们针对代码规则专门做了中文翻译，架构师们也积极指导研发工程师在修改代码违规过程中遇到的问题，并把问题积累下来写成博客，以便更多的人来参考和学习。

第二阶段

第二阶段的计划相对是比较顺利的，临近春节，在这一年中收获和总结的时期，大家的清理工作都非常迅速和顺利。根本原因在于第二阶段的代码违规清理工作，应用和规则的范围都没有扩大，实施清理的人员也没太大变化。所以大家操作都比较熟练，在我们质量组每周发周报跟进进度的时候，一般都能提前完成任务。

 

在这个时期，我们在代码扫描机制和反馈机制上做了一些改进。SonarLint 的推广使用解决了研发人员大都喜欢在本地代码编辑器里操作的需求，他能够在编辑器里面直接扫描代码并且显示出具体的代码违规位置，更加便利于及时修改。周报邮件中每个团队和应用对应的代码违规数量都加上了具体问题列表的超链接，这样通过反馈的结果就可以直接点击打开具体问题的页面，不用再去Sonar首页海量的应用去搜索了。

第三阶段

如果说前两个阶段的清理工作是特种部队突击的话，第三个阶段的工作就是大规模的步兵推进战役了。

 

涉及应用范围比较广，覆盖到了POP平台所有的调用量和重要性都较高的应用，总共78个应用，代码违规1139个。刚过完春节，各个团队开始都收到海量的业务需求排期，面对业务压力，还要修改代码违规，困难不小。

 

在制定目标的时候就遇到了困难，这次计划设计到具体的研发团队较多，各个团队的情况不一样，需要和各个研发团队而Leader逐个沟通才行。当时用了两天时间，找13个研发团队分别确定了第三阶段的清理代码违规的目标，并且确定了每个团队的接口人，其中祥子同学更是同时担任了5个研发团队的接口人，无论是制定目标还是过程中的跟进他都做出了很大的贡献。

 

刚刚制定目标的时候心里还是有些忐忑的，能不能按时完成计划呢？因此把同步数据的频率由每周一次改为了每周2~3次，会把具体的代码违规数量反馈给研发Leader，并给出具体问题列表，作者分别是谁。还有个占用时间比较多的事情就是处理误判，SonarQube有个很好的功能就是，如果某一个代码违规经过分析后发现确实属于误判，那么可以由具备管理员权限的账户把该违规标记为误判，以后每次扫描就会忽略掉该问题了。其实处理误判的过程也是学习的过程，能够更加深入地了解到这个规则，并且为以后的违规定制和修改做些积累。

 

这次的示范团队是F团队，在接口人阿明的努力下，该团队率先完成372个遗留代码违规的清理，他们修改的违规数量占第三阶段总量的30%以上。经过大家的共同努力，终于在计划日期的最后一天完成了目标。

 

在此期间，扩展了原来的代码规则集，加入了针对strusts2漏洞、fastjson漏洞 和sql注入漏洞的代码规则。

总结

经过努力，我们终于做到了，激动之余还要思考下前因后果，以后继续努力。那么总结一下要完成代码质量提升计划，首先要有个好用的工具，然后要有适当的规则，还要持续的跟进。最终共同实现目标。接下来要进行第四阶段的计划。要增加规则，加入安全规则，增加应用范围。

 

并且已经推广到外部，目前我们研发的基于SonarQube的代码质量平台已经应用到Y事业部、交易平台、虚拟平台、网站平台、POP平台五大部门。期望大家能够共享技术经验，共同打造京东质量，营造工程师文化。

 

最后由衷感谢下在此期间付出辛苦努力的POP平台各研发团队成员！