2019年面向亿行C／C++代码的静态分析系统设计及实践.pdf

《2019年面向亿行C／C++代码的静态分析系统设计及实践.pdf》由会员分享，可在线阅读，更多相关《2019年面向亿行C／C++代码的静态分析系统设计及实践.pdf（35页珍藏版）》请在三个皮匠报告上搜索。

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

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

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

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

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

6、2：高低搭配高危，误报率偏高的高价值检查器搭配其他误报率低的检查器避免重要问题被忽略的同时降低“感知误报率”降低感知误报率方法3：易于理解的报告 关键步骤高亮和行为解释 配套完善的文档 代码交叉索引降低感知误报率回忆下代码评审时最不能忍的事是啥？对，就是不能像在IDE里面一样查看符号定义使用。代码交叉索引方法4：Bug生命周期跟踪 精确查找类似Bug，利用标记数据排除潜在误报 通过修复率等参数对分析器进行综合评价降低感知误报率方法5：防止误标和作弊 标记量，间隔时间，标记内容