从香肠到煎蛋卷

Source: Dev.to

没有人真的想看到香肠是怎么做的，对吧？这个过程又脏又不光鲜，通常在最终展示时会被跳过（而且我们真的很高兴它被跳过！🤮🤮🤮）……但如果你跳过“香肠制作”，你永远也吃不到“完整的煎蛋卷”！

嗯，香肠……

……但我们今天说的不是早餐食品，而是技术！在我们的世界里，大多数人更愿意关注闪亮的新功能或巨大的成本节约案例，而不是去处理诸如测试、重构和工具链等琐碎细节。如果没有这些“香肠制作”环节，完整的 DevOps “大餐”（以及我们渴望的所有加速和改进）总是遥不可及。

我的团队最近亲身经历了这一过程，所以今天我们将分享一次“香肠制作”之旅，看看它如何提升代码质量，并直接映射到 DevOps 成果的“煎蛋卷”。

香肠是怎么做的 🐖

和许多团队一样，我们一开始并不够自律。别误会，我们确实在检查所有必需的事项：

• 我们的代码存放在公司官方的版本控制系统中。
• 拉取请求（PR）按照治理标准进行审查和批准。
• 我们的变更通过 CI/CD 部署。
• 我们的流水线中有依赖分析扫描。

从公司角度看，我们的 DevOps 实践已经在正轨上……甚至有点前卫？但仔细观察后发现防护层出现了裂缝：

• 大多数 PR 审查仅仅是为了遵守公司规定。几百行代码的批准有时在半分钟内就完成（老派的“草草批复” ✏️）。
• 测试？那一点点测试根本没有集成到流水线中；只有在你记得手动运行时才会执行。
• 质量分析工具？呃…

我们跑得很快，但有时会出问题。每一次代码推送都变成了一个循环：

1. 获得 PR 批准并推送。
2. 哎呀，部署为什么坏了？
3. 修复错误，打开新 PR。
4. 🤞 回到第 1 步

显而易见，我们的目标不是更快，而是更可持续。要实现这一点，我们必须先做点“香肠”。于是我们决定把代码质量放在首位。这对我们意味着什么？

统一我们的工具链 🎯

我们先调研了一套最小化的工具，整个团队都采用。

重要提示 – 这不是对工作站进行严苛治理，而是让团队就少数几款扩展和工具达成共识，使其成为“我们的东西”。

我们如何决定哪些工具入选

• 工具必须在业界得到广泛认可。
• 如果是开源项目，不能是🧟“僵尸项目”（即必须有近期活动）。
• 必须能够在 CI 环境和开发者本地编辑器中同时使用。
• 对开发者几乎不增加额外工作量。“别把安全带做成仙人掌 🌵”。
• 必须可定制，以便在护栏中体现团队特有的覆盖。

公司已经提供了一些工具，例如 Blackduck 和 SonarQube。由于这些工具是必需或已列入路线图，我们也必须将它们集成进来。

在流水线中实现 🛠️

确定质量工具清单后，我们在临时的代码副本上运行它们——每次运行都会创建容器，运行结束后即销毁。这样可以强迫我们关注每一个依赖和细节。代码在不同环境中流转时，我们会定期扫描，及早捕获错误或安全问题。

重要提示 – 实现 ≠ 强制。

团队在提升代码质量时最常犯的第一大错误是“贪多嚼不烂”。如果你长期没有质量检查，初期的痛感会很强。可以先让工具运行一段时间，等明显问题被清理后再阻止合并，以降低阻力。

我们发现 SonarQube 已经在每个 PR 上进行扫描（但并未强制）。结果相当糟糕：几百个安全热点、几百个代码味道，而且由于我们的单体仓库结构，覆盖率根本没有报告。

• 安全热点 – 可能被利用的风险点（类似“龙卷风预警”）。
• 代码味道 – 能运行但可以更清晰、更易维护的代码。
• 代码覆盖率 – 自动化测试执行的代码比例；高覆盖率意味着测试全面。

接下来几周我们做了：

1. 让工具能够报告可靠信息（为我们的多语言单体仓库编写自定义 GitHub Actions 工作流）。
2. 制定运行测试、聚合结果并交付最终数据的策略。
3. 编写大量测试，覆盖已经上线的遗留代码。
4. 重构那些不易测试的代码，消除大量味道和热点。

我们的简单口号是：让它通过。每一次推送看到指标提升，都让人极度满足——纯粹的多巴胺！

我们现在有香肠了 🐷

今天我们可以自豪地报告：

• 5 条代码味道（从约 150 条下降）
• 0 个安全热点（从约 130 个下降）
• 测试覆盖率 > 85 %（从 0 % 上升）

“香肠制作”工作得到了回报，交付了更健康的 DevOps “煎蛋卷”。