Qodana用户聚焦：对话全栈软件工程师Drew Penrod
[LOADING...]
Drew Penrod 是一位经验丰富的全栈工程师，任职于一家专为儿童设计手机的公司，其产品基于三星 Galaxy 硬件并运行定制软件。他和团队开发并维护一个基于 Android 的平台，让家长可以通过网页界面管控应用、联系人、屏幕使用时间、消息和浏览内容。
随着公司和工程组织的发展，在多个代码库和语言生态系统中保持一致的代码质量、安全可见性和策略执行变得越来越重要。
在这次访谈中，我们与 Drew 讨论了将 Qodana 引入团队工作流程的过程、他们希望解决的挑战，以及他们在推广过程中的收获。
能否介绍一下你的角色和团队？
我是一名职业全栈软件工程师，目前担任 DevSecOps 工程师。我的日常工作介于工程团队和他们的交付系统之间：CI/CD、流水线、开发者工具，以及与之配套运行的安全和质量控制。
除此之外，我还构建了几个支持 DevOps 工作的内部服务，完成了大量 PR 和代码审查，指导过其他工程师，并深入研究了代码库中的时间和空间复杂度及其他性能问题。我直接推动了 Qodana 的采用，从评估到全面推广。
在 Qodana 之前，你在代码质量方面面临的最大挑战是什么？
我们已经有成文的代码风格、PR 审查和 QA 标准。TypeScript、Kotlin 和 React 都有风格指南。每个 PR 都需要两名审查者。但缺少的是对所有这些标准的统一执行。
ESLint 只在某些地方运行，有时在本地运行，有时在构建期间运行，但它并不是正式的 CI 步骤。Prettier 和测试是可靠的，但静态分析并不可靠。在多种语言生态和不断增长的代码库数量下，这意味着标准的执行并不均匀，取决于开发者所在的代码库以及审查他们 PR 的人。没有一个统一的地方可以查看质量随时间推移是在变好还是变差。
你之前是如何管理代码审查和质量检查的？
审查是手动的，每个 PR 有两名审查者，依据成文的风格指南进行。流水线中的自动化检查仅限于格式化和测试。Linter 在各个代码库中的运行情况不一致，也没有共享的静态分析层在所有地方强制执行相同的规则。任何需要深入检查的项目（安全问题、许可证问题、依赖风险）都是逐个发现的，而不是通过流水线步骤来实现。
你们是否需要满足特定的合规或安全要求？
是的。我们销售的产品安装在儿童设备上，因此安全性和依赖状态对我们来说非常重要。我们正在努力对标 CIS Controls v8 和 NIST 网络安全框架（CSF）2.0。这些框架塑造了我们对开发流水线的思考方式。
其中几项控制措施直接落在 Qodana 所支持的工作类型上。CIS v8 控制项 7 涵盖持续漏洞管理，控制项 16 涵盖应用软件安全，明确要求了静态分析和安全编码实践。
CSF 2.0 的 Protect（保护）和 Identify（识别）功能覆盖了类似的领域：了解软件中的内容，了解风险所在，并在易受攻击的代码和生产环境之间保持控制。对我们来说，这些框架得出了相同的实际要求：对每次变更运行自动化检查，并保留可供日后审计的结果。
Drew 对 Qodana 的看法
是什么促使你开始寻找像 Qodana 这样的解决方案？
有几件事同时发生。流水线本身正在现代化，我们希望将静态分析、SCA 和许可证检查整合到其中。我们的依赖更新策略需要强制执行工具，而随着代码库的增长，各个代码库之间的不一致越来越难以忽视。我们需要一个单一工具，能够覆盖我们使用的各种语言，并同时支持在 CI 和 IDE 中运行。
你们还考虑了哪些其他工具？
我们考察了 SonarQube、仅使用 ESLint 的方案以及独立的软件成分分析工具。每个工具都覆盖了问题的一部分，但没有一个能在不产生显著运维开销或无需拼凑多个工具的情况下覆盖全部范围。
Qodana 的哪些方面让你印象深刻？
Qodana 比替代方案更符合我们的需求。它在一个平台中覆盖了静态分析、依赖扫描、风格、覆盖率和许可证审计，支持我们使用的所有语言。
它在 JetBrains IDE 中运行的检查与流水线在 CI 中运行的检查完全一致，因此开发者在推送代码之前就能看到问题，而不是等流水线失败之后才发现。它与我们现有的 CI 平台集成，并支持全局配置，确保规则在各个代码库接入时保持一致。
部署过程
你是如何将 Qodana 引入工作流程的？
采用是渐进式的。Qodana 通过共享的流水线机制接入到 PR 和主分支流水线中，这样各个代码库无需每个团队从头重建 CI 即可接入。每个已接入的代码库都会获得一个基线，将现有发现与新发现分开管理。
目前我们正在推进软性门禁。少数代码库正在试点软性和硬性门禁，但软性门禁尚未推广到所有代码库。
你们花了多长时间看到价值？
从问题出现在 PR 和 IDE 中的那一刻起，我们就开始获得价值，远在任何门禁启用之前。依赖漏洞和许可证问题的可见性是第一个显著的成果，因为这些以前在各个代码库中的暴露情况不一致。将所有信息集中在一个地方，改变了我们分类处理更新的方式。
采用过程中遇到了哪些挑战？
部分推广节奏受到底层 CI 平台限制的影响，这影响了我们在整个组织中将软性门禁升级为硬性门禁的速度。接入多语言代码库也需要针对每种生态单独花费时间，因为每种语言都需要自己的配置和基线。这些都不是阻碍性问题，但确实是我们仍在逐步推广而非全面强制执行的原因。
Qodana 对你们的代码质量产生了什么影响？
推广仍在进行中，因此到目前为止，影响主要体现在可见性方面，而不是流水线强制执行。Qodana 在代码库中发现了大约 99,000 个问题。
这个数字是一个起始基线，而不是已修复问题的数量，它同时涵盖了代码质量、风格和安全相关的发现。将这些数据集中在一个地方本身就很有价值：在 Qodana 之前，没有一致的方法来比较不同代码库或语言之间的质量。
你看到代码库的复杂度和功能方面有什么变化吗？
性能和复杂度工作是我投入大量时间的事情，Qodana 作为另一个观察视角非常有帮助。
这些检查会暴露低效循环、冗余工作以及暗示更深层时间或空间复杂度问题的模式，这让我在审查 PR 或回顾旧代码中的热点时能够抢占先机。它不能替代对算法本身的理解，但它确实能标记出足够多的问题，让我们比以往更早地展开相关讨论。
现在声称整个代码库的复杂度发生了广泛且可衡量的变化还为时过早，因为推广仍在进行中。试点代码库最终会呈现最清晰的信号。
它是否有助于合规或安全流程？
是的。依赖漏洞和许可证问题现在可以在 PR 和 IDE 中看到，而以前它们的暴露是不一致的。
这也让我们的依赖更新策略有了可依托的载体，因为 CVSS 阈值、许可证规则和审计检查可以在开发者已在使用的同一条流水线中运行。一旦我们完成软性门禁的推广并开始升级硬性门禁，这些策略规则就会从"愿景"变为"强制执行"。
准备好提升各个代码库的代码质量了吗？
[LOADING...]
Qodana 帮助开发团队将静态分析、依赖扫描、许可证审计和质量强制执行整合到单一工作流程中，直接集成在 IDE 和 CI/CD 流水线中。
试用 Qodana，看看你的团队如何改善每个代码库的一致性、可见性和代码质量。
特别感谢 Drew Penrod 接受本次访谈。祝你和你的团队继续取得成功！