DevOps系列之 —— 持续开发与集成(六)静态代码检查

DevOps系列之 —— DevOps概览(一)软件产业和交付模式发展趋势
DevOps系列之 —— DevOps概览(二)新型软件技术及交付模式
DevOps系列之 —— DevOps概览(三)DevCloud HE2E DevOps 框架及其主要服务
DevOps系列之 —— 持续规划与设计(一)敏捷项目管理理念与方法实践
DevOps系列之 —— 持续规划与设计(二)规划与设计
DevOps系列之 —— 持续规划与设计(三)敏捷项目管理的方法【Kanban 与 Scrum】
DevOps系列之 —— 持续规划与设计(四)敏捷需求管理【用户故事 & 敏捷估算】
DevOps系列之 —— 持续规划与设计(五)团队与协作
DevOps系列之 —— 持续规划与设计(六)华为敏捷项目管理企业实践
DevOps系列之 —— 持续开发与集成(一)持续集成理念、方法及实践
DevOps系列之 —— 持续开发与集成(二)代码托管与分支策略(Git Flow、GitHub Flow & GitLab Flow)
DevOps系列之 —— 持续开发与集成(三)Git 基本概念及主要操作
DevOps系列之 —— 持续开发与集成(四)代码提交及代码评审
DevOps系列之 —— 持续开发与集成(五)华为云 DevCloud 代码托管服务及 CloudIDE
 
DevOps 系列文章,持续更新中 ~~~

静态代码检查

什么是静态代码检查

  • 静态代码检查,又被称为静态程序分析(Static program analysis)
  • 静态 是指在 不运行计算机程序 的条件下,进行程序分析
  • 大部分的静态程序的分析的对象是针对 特定版本的源代码,也有些静态程序分析的对象是 目标代码

为什么做静态代码检查

  • 静态代码检查可以不运行程序就为我们定位出来一些问题,这些问题会导致一些潜在的风险(如下表)
潜在问题 风险
重复代码过多 造成开发人力的浪费以及后期维护成本增加
编码风格糟糕 代码凌乱、不可读,难于维护与开发修改
圈复杂度过高 造成代码可维护性、可继承性降低,问题定位难度加大
编码安全风险 使用具有安全风险的函数,导致系统的安全性层级降低,加大系统的安全风险

静态代码检查关注点

编号 检查点(举例) 概述
1 重复率 表示一段源代码在一个程序,或者一个团体所维护的不同程序中重复出现,是不希望出现的现象
2 代码风格 程序开发人员所编写源代码的书写风格,良好代码风格的特点是使代码 易读
3 圈复杂度 衡量一个模型判定结构的复杂程度,数量上表现为独立线性路径条数,圈复杂度大说明程序代码可能质量低且难于测试和维护
4 代码安全 编码过程中,常见的安全问题包括(不限于):缓冲区溢出/跨站脚本攻击(XSS)/SQL 注入/XML 注入/LDAP 注入

静态代码检查常用分析技术

编号 分析技术 概述
1 词法分析 从左至右一个字符一个字符的读入源程序,对构成源程序的字符流进行扫描,通过使用正则表达式匹配方法将源代码转换为等价的符号(Token)流,生成相关符号列表
2 语法分析 判断源程序结构上是否正确,通过使用上下文无法语法将相关符号整理为语法树
3 数据流分析 对控制流图进行遍历,记录变量的初始化点和引用点,保存切片相关数据信息
4 无校代码分析 根据控制流图可分析孤立的节点部分为无效代码
5 抽象语法树分析 将程序组织成树形结构,树中相关节点代表了程序中的相关代码
6 语义分析 对结构上正确的源程序进行上下文有关性质的审查
7 控制流分析 生成有向控制流图,用节点表示基本代码块,节点间的有向边代表控制流路径,反向边表示可能存在的循环;还可生成函数调用关系图,表示函数间的嵌套关系
8 污点分析 基于数据流图判断源代码中哪些变量可能受到攻击,是验证程序输入、识别代码表达缺陷的关键

代码检查的常用工具

编号 检查工具 概述
1 Splint Splint 是开源的静态软件缺陷检测工具,用于检测用 标准C 实现的软件缺陷
2 Klocwork K8 支持 C/C++,Java,它能检测缓冲区溢出、内存泄漏、安全漏洞等软件缺陷
3 Coverity 第一个能够快速、准确分析当今的大规模(几百万、甚至几千万行的代码)、高复杂度代码的工具。检测和解决 C、C++、Java 和 C# 源代码中最严重的缺陷的领先的自动化工具
4 Findbugs 是一个基于 Java 语言的静态分析工具,它主要检查类或者 jar 文件
5 PMD 采用 BSD 协议发布的 Java 程序代码检查工具,其核心是 javacc 解析器
6 Cppcheck 一种开源的 C/C++ 代码缺陷静态检查工具,只检查编译器检查不出来的 bug,不检查语法错误

代码检查的企业实践

  • 代码检查已经被集成到华为的软件生命周期当中,作为其中的重要一环存在
  • 不通过代码检查就无法合入代码仓库
  • 在个人级和版本级的流水线当中,都会被自动触发执行
  • 通过多年的开发经验,现已积累了大量的代码检查规则,并将这些经验能力提供至华为云DevCloud平台的CodeCheck当中
    DevOps系列之 —— 持续开发与集成(六)静态代码检查

静态代码检查的效果

  • 静态代码检查前
    • 如何找 Bug?
      • 单元测试,黑盒测试,代码审查
    • 资源约束
      • 人力有限:人员的质量(测试人员的能力水平、素质等),投入回报比等
      • 时间有限:产品快速迭代,发布周期短,个人时间有限
      • 空间有限:测试用例检查范围小,测试覆盖率不够大
      • 精力有限:人类大脑精力等有限
  • 静态代码检查后
    • 如何找 Bug?
      • 静态代码检查
    • 克服约束
      • 在不运行程序的前提下找出问题
      • 不依赖于好的测试用例(对人员的素质要求有所降低)
      • 不单单测试单个代码片段【全路径覆盖】
      • 不需要知道软件到底想干什么

CodeCheck

CodeCheck 多语言检查

  • 支持混合语言检查
    DevOps系列之 —— 持续开发与集成(六)静态代码检查

CodeCheck 问题可视化

DevOps系列之 —— 持续开发与集成(六)静态代码检查

CodeCheck 规则集管理

  • 自定义规则集
  • 集中管理并共享规则集
    DevOps系列之 —— 持续开发与集成(六)静态代码检查

CodeCheck 误报与漏报统一管理

  • Others:
    • 误报率高
    • 误报优化难
    • 误报问题重复报
  • CodeCheck:
    • 支持跨函数的深度检查
    • 标记误报后不会再报
    • 预置规则集误报率低
    • 部分误报持续优化

什么叫误报?

  • 在代码检查的过程中,发现某个东西有问题报错,我们进行审核的时候再看,同样是没有问题,这就是误报

CodeCheck 特性

  • 一站式
    • 覆盖主流语言和标准
    • SDLC 集成:提交代码时、合并代码时,会触发流水线当中的静态代码检查环节
  • 专业性
    • 提供专业级的预置规则集
    • 提供专业的缺陷修复建议
    • 支持跨函数的深度检查
    • 缺陷精确定位到代码行
  • 多分支检查
    • 可*切换分支进行检查
  • 聚焦新问题
    • 在每个任务的基础上可以设置新问题起始时间(默认起始时间为当前任务上一次检查成功的时间,起始时间之后检查出的所有问题属于新问题)
  • 责任自动归属
    • 静态分析过程中,自动将新问题分配给问题代码行上的 最后一次提交者
  • 问题协作
    • 可以与他人分享问题链接,提升协作便利性

CodeCheck 产品典型操作流程

DevOps系列之 —— 持续开发与集成(六)静态代码检查

创建代码检查任务

  • 选择代码仓库
    DevOps系列之 —— 持续开发与集成(六)静态代码检查
  • 选择检查语言
    DevOps系列之 —— 持续开发与集成(六)静态代码检查
  • 完成任务创建
    DevOps系列之 —— 持续开发与集成(六)静态代码检查

执行代码检查任务

  • 任务主页点击开始检查
    DevOps系列之 —— 持续开发与集成(六)静态代码检查
  • 等待任务检查完成(查看检查进度)
    DevOps系列之 —— 持续开发与集成(六)静态代码检查
  • 查看检查结果
    DevOps系列之 —— 持续开发与集成(六)静态代码检查

任务详情 —— 概览视图

  • 任务当前分支:默认为 master 分支
  • 任务最近检查时间
  • 未检查问题数、未解决新问题数、已解决问题数
  • 代码平均圈复杂度、代码重复率、有效代码行数
  • 未解决问题严重程度统计
  • 问题最多 Top 10 检查规则
  • 问题指派分布统计
    DevOps系列之 —— 持续开发与集成(六)静态代码检查

任务详情 —— 问题视图

  • 过滤器功能:提供按问题级别、问题状态、问题检测时间、规则、文件目录、负责人过滤
  • 单个问题卡片:包含问题所在文件、问题报错信息、问题级别、状态、负责人、修改建议等
  • 问题可操作区域:可手动更新问题状态、问题负责人、查看问题修改建议等
  • 问题关键代码片段
    DevOps系列之 —— 持续开发与集成(六)静态代码检查

任务详情 —— 代码度量视图

  • 代码度量指标(可切换过滤)
  • 对应指标下的具体数据列表
    DevOps系列之 —— 持续开发与集成(六)静态代码检查

任务详情 —— 设置视图

  • 任务名称、检查语言等的更新
  • 选择代码检查任务的规则集
  • 自定义执行计划
  • 自定义任务通知(比如检查完成时通知)
  • 自定义新问题初始时间等
  • 删除当前任务
    DevOps系列之 —— 持续开发与集成(六)静态代码检查
思考题

以下对于 Git Rebase 和 Merge 两种合并方式的区别,哪些选项描述是正确的?
A. Merge 是一个合并操作,会将两个分支的修改合并在一起,默认操作的情况下会提交合并中修改的内容
B. Rebase 的提交历史忠实地记录了实际发生过什么,关注点在真实的提交历史上面
C. Rebase 并没有进行合并操作,只是提取了当前分支的修改,将其复制在了目标分支的最新提交后面
D. Merge 的提交历史反映了项目过程中发生了什么,关注点在开发过程上面
答案:AC

最后,欢迎大家关注我的个人微信公众号 『小小猿若尘』,获取更多IT技术、干货知识、热点资讯。同时,我在公众号中分享了精心整理的一些视频资料(包括 Python全栈教程、AI教程、前端、数据库等),大家回复相应关键词即可获取网盘视频链接,感谢大家的关注

上一篇:Azure Devops实践(5)- 构建springboot项目打包docker镜像及容器化部署


下一篇:聊聊《阿里巴巴DevOps实践指南2021》