代码静态分析系统设计及实践

1、技术创新，变革未来代码静态分析系统设计及实践目录代码质量管理是个大问题静态分析+代码评审的实践学习和强调，红线和惩罚，100%的测试覆盖率，和事后复盘并不够有经验的程序员也会犯错对代码提要求很难监督落实测试更多是验证功能，很难检测编码缺陷代码的快速变化使质量更难管生产质量是责任靠运维和事后复盘善后够吗？静态分析工具：半智能的代码分析机器人静态分析辅助代码评审自动化工具+流程才是未来Bug!Thx!Bug!投入大KPI不痛不痒使用主体和责任主体不一致一步登天想要终极AI代码质量改进工具、流程落地难Bug!No Thx!DevOps: 代码质量责任应该左移设计代码开发代码评审入库测试发布非研发人员

2、主导，沟通成本高，推动修复周期长很难形成标准推动研发实施形成技术债，偿债成本高代码签入前，研发人员有义务修复问题测试人员早期加入，更懂项目研发的情况，沟通成本低，加快上线能逐步形成好的编码规范和最佳实践检查代码风格问题挺准，但是 我warning都不看，还看这个？大多数开发人员眼中的静态分析工具检查逻辑问题好，但耗时长 还挺多误报，想用而不敢用编译器里的Errors and warnings自带静态分析的语言如Typescript, RustIDE里的智能提示代码混淆和美化代码交叉索引Eclipse等IDE中的一键重构App市场的审核成功静态分析应用代码评审中的静态分析针对该提交 代码片段自

3、动触发分析发现问题，拒绝代码合并发起代码提交，如Pull Request没有问题，允许合入开发者代码仓库静态代码评审的样子为何代码评审阶段？2K Bugs12K Warnings 225K Code Smell“找到几万个问题，没法修”“这是以前的业务逻辑，不用修”“这别人写的代码，不关我事”大量报告引起不适刚写的代码立即自动扫描，程序员强迫使用 只体现新增代码问题，责任边界清晰评审流程多人督促渐进式开启更多检查器增量分析减少不适软件工程师一天被邀请进行多次 代码评审，这些都不是他们自身 的KPI一旦工期紧996，人工评审容易 变成走形式任务挂着还容易造成工程师焦虑降低工程师劳动强度大规模C/

4、C+静态代码评审系统搭建数千个活跃开发的代码仓库每天上千次代码评审请求平均每次代码评审小于50分钟需要编译C/C+代码使用了定理证明器求解可行路径（精确，耗时）能跨函数分析能处理指针使用有深度的代码分析器做到快速和准确用尽量少机器完成一天几千次分析每次分析10分钟要能结束控制误报并建立反馈和改进机制挑战：超大规模代码仓库项目平均40分钟单机编译时间 项目平均编译代码量超百万行编译的价值C/C+代码逻辑受编 译参数深度控制源代码索引和统计提升开源静态分析工 具分析质量提高分析质量测试项目 glog （谷歌的日志项目）, 17个源文件。cppcheck不带编译分析：111个分析报告cppcheck

5、带编译分析：280个分析报告111 280不编译编译300250200150报告数 100500编译流程融合静态分析分布式编译与分析大量使用缓存提升静态分析的理论速度如何做到10分钟反馈分析结果系统地改进分析时间编译流程分析流程依赖关系分析分布式 编译分布式 分析分布式链接跨模块分析 报告整合缓存缓存缓存缓存硬核玩家：从理论上改进静态分析能力PLDI2018: 去掉路径 遍历分析中的冗余ICSE2019：路径遍历内 存泄漏分析的多项式算法需求2：误报率要低方法1： 数据驱动的改进循环降低误报率标注反馈优化代码扫描新增分析器淘汰分析器感知误报率数据驱动的开发管理方法2： 高低搭配高危，误报率偏高

6、的高价值检查器 搭配其他误报率低的检查器避免重要问题被忽略的同时降低 “感知误报率”降低感知误报率方法3：易于理解的报告关键步骤高亮和行为解释配套完善的文档代码交叉索引降低感知误报率回忆下代码评审 时最不能忍的事 是啥？对，就是 不能像在IDE里 面一样查看符号 定义使用。代码交叉索引方法4：Bug生命周期跟踪精确查找类似Bug，利用标记数据排除潜在误报通过修复率等参数对分析 器进行综合评价降低感知误报率降低感知误报率方法5：防止误标和作弊标记量，间隔时间，标记内容用基线数据训练模型用聚类和离群检测找到违反者红黑榜鼓励参与者用数据风控的方式管理总结：代码评审中的静态分析无需额外操作，不改变程序员习惯的流