如何借助 Qodana 和 Unity 提高游戏开发中的代码质量
如果您还不熟悉 JetBrains Qodana，它是一个将静态分析扩展到 CI/CD 系统中的团队审查的代码质量平台。
它的一部分作用是能够让您的团队更有效地进行协作 – 特别是在设置代码审查标准和质量门时。 此过程还可以促进每位团队成员都更严格地遵守这些标准。
我们的 VR Unity 团队决定将 Qodana 用于一个内部 Unity 项目 – Archipelago，这是一款以山脉形式直观呈现销售数据的虚拟现实应用。 Qodana 将 Rider 的 Unity 检查全部引入到了 CI 分析中，使整个团队都可以进行代码审查，这是我们非常感兴趣的方式。 我们安排一名初级开发者帮助进行了分析，以确定它是否适合初学者。
我们希望这能够为一些初级开发者提供一次学习经历，也希望这会是一个能够提高代码质量的实用工具。 事实证明它的作用远不止于此，它帮助初级开发者交付了更高级别的代码。 在下文中，我们的团队详细介绍了他们运行分析所采取的步骤，并分享了他们的体验。
先决条件：管道设置
在开始使用 Qodana 之前，我们已经在 TeamCity 中配置了构建管道。 此管道借助包含 Docker 化版本 Unity 编辑器的 Linux Docker 镜像来构建 Unity 项目。 每当我们在主分支上创建拉取请求时，这都会为我们提供项目的构建 APK。
为了获得 Qodana 分析报告，我们采取了以下步骤：
2. 生成解决方案并安装所有必需软件包。
Unity 项目通常不包含 C# 解决方案和项目文件，我们需要生成这些文件以便 Qodana 对其进行处理。 我们在构建环境中安装了相应的 .NET SDK，并在每次构建时执行以下脚本：
#!/usr/bin/env bash
${UNITY_EXECUTABLE:-xvfb-run --auto-servernum --server-args='-screen 0 640x480x24' unity-editor}
-batchmode -quit -projectPath $UNITY_DIR -executeMethod Packages.Rider.Editor.RiderScriptEditor.SyncSolution
3. 将 qodana.yaml 文件添加到我们项目的仓库根目录。
ide: QDNET version: "1.0" baseProfile: "qodana.recommended"
4. 在管道配置中设置名为 QODANA_TOKEN 的环境变量，以便 Qodana 对其进行访问。 该令牌应从 Qodana Cloud 中的项目页面获取。
5. 开始 Qodana 分析。
由于我们使用的是自定义构建管道，我们决定使用 Qodana CLI 以原生模式（在构建计算机上）启动 Qodana，而非启动容器来对其进行托管。 要在 Linux 计算机上执行此操作，我们必须下载 Qodana CLI。 对于 GitHub、GitLab 或 Azure DevOps 管道，则无需下载。 您可以在此处了解有关 Qodana 与各种 CI 系统集成的更多信息。
为了正确运行分析，我们需要在项目所在文件夹中执行以下命令。 然后，在 /report 文件夹中生成输出和报告。 为了方便起见，我们修改了构建管道配置，以便通过构建工件访问报告。
curl -fsSL https://jb.gg/qodana-cli/install | bash qodana scan -i $(pwd) -o /report
因此，每次对主分支进行更改时，我们不仅会获得一个 APK 文件，还会在 Qodana Cloud 中获得一份报告，我们可以在浏览器中查看或在 Rider 中打开该报告。
Qodana 报告设置
我们最初得到了一份包含近 33,000 个问题的报告。 不要惊慌，这些并非全部是我们的问题！ 使用默认配置文件触发分析时，我们意外得到了源自于资源商店中所有 Unity 库和资源的问题。
在 UI 中选择 Scripts 文件夹后，我们得到了大约 400 个问题。 在我们看来，问题仍然很多，但我们决定进行更深入的研究。
我们能够使用此报告，但如果我们尝试在 IDE 中将其打开，仍会得到包含 32,856 个问题的完整报告，这并不实用。 为了仅对我们的代码库而非整个项目进行分析，我们添加了一个自定义配置文件。 然后，我们更新了我们的 qodana.yaml 文件，使其仅包含指向我们配置文件的链接，从而更易于使用。
ide: QDNET version: 1.0 profile: path: profile.yaml qodana.yaml
profile.yaml 文件包含针对我们完整分析的检查。 我们只想查看 Scripts 文件夹，我们为此使用了作用域。
baseProfile: "qodana.recommended" inspections: - group: ALL ignore: - "scope#!file:Assets/Scripts//*" profile.yaml
使用报告
当我们选择正确的配置文件并获得正确的报告后，我们更为细致地查看了警报。 您可以在文档中详细了解如何将 Qodana 报告与 Rider 进行链接。 大多数警报识别的是冗余和约束违规问题，例如冗余 using 指令或命名空间与文件位置不符。
借助 IDE 中的上下文操作，只需点击几下即可修正此类问题。
除了冗余和约束违规问题之外，还有许多涉及语法错误或与常见做法不符的警报。 大多数情况下，问题都源于缺少 private 修饰符或可设为 private 的成员。
接下来，我们仅针对 Unity 和 Unity 性能检查选择了单独的类别。 这些问题可以通过在 IDE 中使用上下文操作提供的快速修复来解决，这些改进有助于提高代码效率和可读性。
对于诸如方法调用开销较大等问题，我们需要重写一些代码。 其中最常见的方案通常涉及将 GetComponent 方法从性能关键型上下文移动到 Awake 或 Start 事件函数，如此处所述。
使用基线
我们逐渐遇到了修正方法更为复杂的问题。 例如，创建构建时使用了 BuildCommand.cs 类和 PerformBuild 方法，但在 Unity 中却未对其进行调用。
接下来，在我们的案例中，DateContext.cs 中存在被标记为开销较大的方法调用。 我们决定将此类问题放入基线当中，因为这些问题被视为对于我们的项目布局无足轻重的问题。 下图显示了我们选择不修正的错误的列表。
为了向我们的项目添加基线，我们从 Qodana Cloud 下载了 qodana.sarif.json 文件并将其移动到我们的根目录。
然后，我们向构建步骤添加了一个基线形参。
curl -fsSL https://jb.gg/qodana-cli/install | bash qodana scan -i $(pwd) -o /report --baseline ./qodana.sarif.json Baseline parameter.
此后，我们将仅获得包含新问题的报告。 而目前看来，似乎一切正常。
深入研究结果
在本次实验过程中，我们将 Qodana 添加到了 TeamCity 管道中，配置了配置文件，获得了多份分析报告，并修正了项目中的几乎所有问题！
使用 Qodana 对审查我们项目的代码并使其更加简洁有效起到了很大帮助。 Qodana 的真正实力在于团队协作，但它在帮助团队实现静态代码分析方面也是一个非常宝贵的工具，特别是对于那些使用 JetBrains IDE（本例中为 Rider）或 VS Code（借助 Qodana VS Code 扩展程序）的团队而言。
安装 Qodana 并按照这些说明亲自试用。 如果您想更全面地了解我们的经验，欢迎随时发表评论。
特邀贡献者：Ekaterina Trukhan，VR Unity 开发者
来自 Qodana 团队的消息
感谢 Ekaterina 和团队尝试 Qodana 和 Unity。 如果您对如何着手使用有任何疑问，我们会随时为您提供帮助 – 只需在下方评论区告诉我们或在 Qodana 的 YouTrack 项目上提交问题。 您可以在 LinkedIn 或 Twitter 上关注我们以获取更多动态。
本博文英文原作者：
Subscribe to Qodana Blog updates
