代码扫描 | 把控代码质量的利器

本文作者：潘金赤 —— CODING 产品总监

腾讯云研发平台负责人，十年研发能效建设经验

CODING 代码扫描产品负责人

有位小伙子在办公大楼门口抽烟，一位路人经过他的身边对他说：“你知不知道这个东西会危害你的健康？你有没有注意到香烟盒上的那个警告（Warning）？”

小伙子说：“没事儿，我是一个程序员。”

路人说：“这又怎样？”

程序员回答道：“我们从来不关心 Warning，只关心 Error。”

以笑开场，这是一篇写给极少使用/了解代码扫描工具的用户的“启蒙”读物。一方面因为代码扫描存在一定的技术壁垒，涉及到词法/语法分析、编译注入、模式识别及安全等相关领域，想要了解这方面的内容可能难以下手；另一方面，由于目前大众对于代码扫描产品及其领域还存在着较多误解，极大程度上影响了代码扫描的使用体验，更有甚者直接把 Lint/Style 与扫描划了等号，让人啼笑皆非。

CODING 代码扫描自开放试用以来，已累计为 5000+ 团队提供扫描服务，帮助开发团队及时发现了大量潜藏的代码缺陷、安全漏洞以及不规范代码。希望通过这篇文章，以一些常见场景为例，通俗易懂地解释代码扫描的价值与使用方法，帮助读者深入理解，快速上手，让代码扫描产品在助力企业建设 DevSecOps 的道路上，发挥最大的价值。

代码扫描有什么价值

抛开那些老生常谈的 质量前移 或 质量内建 的概念，从实际运用的角度来看，代码扫描往往是一个团队向 DevOps 转型的第二步（第一步是持续集成/流水线）。一是因为流水线上只跑了编译打包部署还是略显单薄，二是相比单侧、接口自动化及 e2e 自动化，接入代码扫描的成本是最低的。以 Jenkins 为例，只需要运维在 Jenkins 集群中安装 SonarQube 插件，再在 Jenkinsfile 中增加一行命令，就可以在无需开发人员介入的前提下，完成代码扫描的接入。

此外，稍有代码文化意识的开发也会在本地 IDE 中安装插件做本地检查，一旦出现语法或者风格问题时能直接在 IDE 上标注警示甚至自动修复。

越容易得到的东西往往也最容易被忽视，IDE 的 auto inspect/format 或流水线的静默执行，容易让研发淡化代码扫描的感知和价值：我有做 Style check，完成了代码检查任务、研发上线周期太紧张，扫描的问题以后再看、代码扫描发现的问题无伤大雅、代码扫描这个工具/环节可有可无。事实上，各大软件/互联网厂商每年都会花费上百万购买各类扫描软件 License（Sona