JetBrains Qodana 团队代码质量问答
[LOADING...]
代码质量由无数决策塑造，从开发者如何管理复杂度，到他们多快能发现回归。但技术债务、认知复杂度和单元测试等常见概念并不总是被清楚理解。
在一次新的代码质量问答中，我们请 Qodana 团队成员回答了一些关于维护代码质量的热门搜索问题。以下是他们简明实用的解释。
目录
技术债务与代码质量差之间有什么区别？
“代码质量差描述的是代码本身，而技术债务描述的是一种会带来未来工作的妥协。例如，‘我们之所以使用硬编码值而不是配置，只是因为我们得尽快写出 POC’，这就是有意的技术债务。
相比之下，‘我不知道为什么需要使用配置，所以才硬编码值’，这是由知识缺乏导致的代码质量差。技术债务可能导致代码质量差，但代码质量差并不总是由技术债务造成的。”——Alexandr Kugushev
[LOADING...]
在深层嵌套循环中最小化认知复杂度的最佳实践是什么？
“在嵌套循环中最小化复杂度的最佳实践就是避免嵌套循环：提取函数、反复检查条件（也许可以通过不同的逻辑规则简化它们）、明确命名中间结果、使用迭代器、生成器、map、filter、reduce 函数、尽量在处理前展平数据，等等。”——Anastasia Lavrenko
内聚与耦合有什么区别，它们如何影响可维护性？
“代码覆盖率和变异测试服务于不同但相关的目的。代码覆盖率衡量单元测试执行了多少生产代码。变异测试通过故意对代码引入小的改动，并检查测试是否能检测到这些改动，来评估这些测试的质量。如果测试仍然通过，该变异就存活下来，表明测试套件可能存在缺口。
没有普遍理想的变异得分，因为结果因项目和测试策略而异。然而，大约 40–60% 的得分通常被认为是合理的起始范围。更高的得分可能表明测试套件更强，但目标应该是实现有意义的测试质量，而不是达到某个具体数字。”——Aleksander Movsesov
[LOADING...]
单元测试在维护质量标准方面发挥什么作用？
“单元测试能针对代码变更提供最快的反馈。通过隔离地测试各个行为单元，它们能在回归引入点附近捕获回归，使重构更安全，并确认代码继续按预期运行。”——Arman Ayvazyan
你如何追踪代码质量是否真的在改善？
“我认为，追踪代码质量是否真的在改善，最好的方法是观察随时间变化的趋势。静态分析可以给出信号，例如新增了多少问题、这些问题有多严重，以及技术债务是在上升还是下降。但你也应该能够在静态分析之外看到影响。
如果代码质量在改善，你应该开始看到进入生产环境的 Sev 1 问题减少，并且在问题确实发生时 MTTR（平均修复时间）更快。这能让你更好地了解，你所做的改变是否真的在提升软件的质量和可靠性。”——Alex Costa
如何消除自动化漏洞扫描流水线中的误报？
“首先，我们应该区分漏洞扫描和静态分析。Qodana 所做的并不总是漏洞扫描——它发现的很多问题无法被第三方利用。当然，Qodana 确实会发现漏洞，但它也会发现常规 bug、危险函数、死代码等。
话虽如此，无论是什么问题，消除误报的方式都类似——让你使用的工具获得更多关于你的仓库的信息。最常见的误报情况是，自动化工具不知道你是有意以某种方式编写代码的，例如当你不同意既有实践时，或者当你使用不支持更安全替代方案的旧版语言标准时，或者当你被第三方依赖迫使采用不安全的代码模式时。
所有这些都可以解决：对于整个仓库范围内的误报，你可以在 qodana.yaml 中排除相应检查。对于单行和代码块，你可以使用 // NOLINT(<INSPECTION ID>) 和 // NOLINTNEXTLINE(<INSPECTION ID>) 这样的注释显式地抑制检查。”——Anna Zhukhova
维护代码质量不仅仅需要修复单个问题。团队需要有意识地做出技术妥协，保持代码可理解，并创建能尽早发现问题的快速反馈循环。
自动化代码分析可以通过持续识别质量问题，并帮助团队在整个开发过程中应用一致的标准，来支持这些实践。借助 Qodana，团队可以将 JetBrains 检查引入其 CI/CD 流水线，并在问题变得更难、更昂贵之前解决它们。
不要错过下一期代码质量问答
需要为你最关心的代码质量和安全问题找到答案？在下方留言参与下一轮，或者了解 Qodana 如何帮助你保护和改进代码库。