重温 Joel's Test - exe.dev 博客

# 重探乔尔测试 来源: https://blog.exe.dev/revisiting-joel 早在 2000 年，Joel Spolsky 撰写了一篇颇具影响力的博文《乔尔测试：打造卓越代码的 12 个步骤》(https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/)，用于快速评估一个软件团队是否高效运作。以下是他公之于众的十二个问题： 1. 你们使用源代码控制吗？ 2. 能否一步完成构建？ 3. 是否进行每日构建？ 4. 是否有缺陷数据库？ 5. 在编写新代码前是否先修复缺陷？ 6. 是否有最新的进度计划？ 7. 是否有需求规格说明？ 8. 程序员是否有安静的工作环境？ 9. 是否使用能买到的最佳工具？ 10. 是否有测试人员？ 11. 新候选人在面试时会编写代码吗？ 12. 是否进行走廊可用性测试？ 这些问题至今仍然相关，但随着智能体的出现，又有了更多新的问题。我将其称为谢莉测试，以我们的编码智能体命名——它源自 Unix shell、玛丽·雪莱和珀西·比希·雪莱： 1. 你是否使用智能体进行代码审查？ 2. 你是否在 LLM 智能体的监督下持续部署？ 3. 你是否有端到端的集成测试？ 4. 你和你的编码智能体是否能轻松使用可观测性工具？ 5. 你是否能获取来自顶级供应商的最新模型？ 6. 你是否有合并队列，并在 3 分钟或更短时间内完成？ 7. 你的团队是否能轻松部署新工具和智能体，用于开发并协助处理开发相关的所有事务？ 8. 团队成员是否定期讨论他们的工具、工作流程，并在必要时进行调整？ 9. 对于编码智能体作为用户而言，你的产品是否易于理解？ ### 1. 你是否使用智能体进行代码审查？ 基于同行的代码审查已过时(https://crawshield.io/blog/agent-principal-agent)。LLM 编写代码，而工程师对其负责。增加另一个人的橡皮图章，无论多延迟，都已过时。（即使在最优秀的团队，我们都知道一个小的、有针对性的改动可能会产生漫长的代码审查周期和无谓的争论，而如果你把两周的改动堆到邻居那里，那很可能直接 LGTM。） 相反，要求你的智能体使用不同模型的子智能体进行对抗性代码审查，以确保提交的内容与预期一致，这将产生奇效。（你的开发工具只支持一个模型系列吗？换一个不会束缚你的工具吧。）另请参阅《评审评审》(https://blog.exe.dev/review-the-reviews)和Roborev (https://github.com/kenn-io/roborev)。 ### 2. 你是否在 LLM 智能体的监督下持续部署？ 我们并不教条地坚持这一定意味着每小时、每次提交或每天一次。你仓库里的代码清单将面临现实考验，至关重要的是让它尽快接受检验。周期越短越好。持续部署需要你可以信赖的集成测试，这是好事。它同样需要功能开关基础设施；这同样是好事。 我们的智能体 Athena (https://blog.exe.dev/athena-deploys-exe) 监督持续部署，如今已不可或缺。它读取日志、检查指标，并为下一次部署记录经验教训。Athena 通过 Slack 进行交流，并拥有终止部署的权力。 如果你因为不确信你的部署平台拥有所有正确的指标门控而一直推迟持续部署，请立即放弃那个项目，为你自己编写一个 Athena 智能体循环。它已深度集成到我们的部署控制中心软件中，但如果你想让我们提取其核心，请与我们联系。（而且，是的，我们给我们的机器人起名字(https://blog.exe.dev/botiquette)，这样它们更容易被提及。） ### 3. 你是否有端到端的集成测试？ 当缺陷不可避免地溜过时，你需要找出你的测试在何处不足。LLM 擅长编写测试。（例如，参见关于 Go 语言加密标准测试的评论(https://bsky.app/profile/filippo.abyssdomain.expert/post/msj4dfbihb2u)。）拥有集成测试基础设施可以让你确信部署不会破坏核心功能。 顺便说一句，如果你必须依赖外部依赖，为那个令人畏惧的外部 API 构建“数字孪生体”(https://factory.strongdm.ai/techniques/dtu)从未如此简单。 ### 4. 你和你的编码智能体是否能轻松使用可观测性工具？ 在 LLM 时代，监控栈必须支持机器查询，最好使用 SQL，最好能关联业务数据。（在 exe.dev，我们喜爱Clickhouse (https://clickhouse.com/clickstack)。） 使用一个机器人进行警报的初步分类和维护。我们的机器人名叫西西弗斯。 不要使用可观测性工具（或其内置智能体）来查看指标和诊断棘手的客户缺陷，而是将你常规的编码智能体指向可观测性工具。结合代码和日志效果绝佳。 来自 exe.bots 应用的一条 Slack 消息：西西弗斯正在对一条错误日志警报进行分类，并附有证据、评估和建议的下一步。西西弗斯在 Slack 中对警报进行分类。 ### 5. 你是否能获取来自顶级供应商的最新模型？ 这重复了乔尔的“你是否使用能买到的最佳工具？”乔尔的问题正受到考验，因为 CFO 们发现，如今，昂贵的 IntelliJ 或 Tableau 订阅只是他们最微不足道的担忧之一。 ### 6. 你是否有合并队列，并在 3 分钟或更短时间内完成？ 不要使用长生命周期的分支。将你的更改提交到主分支，并保持主分支绿色。实现这一点的方法是先运行测试，然后再将其合并。你的测试越快，这就越容易！ 如果你的合并队列速度慢，它将会积压（或需要技巧）。使用 LLM 进行工程开发极度缺乏人类注意力：漫长的延迟会摧毁这种注意力。 自https://sketch.dev/blog/lightweight-merge-queue这篇文章发布以来，我们已经放弃了 GitHub Actions，但其基本功能仍然有效。 如果有机会，智能体在加速你的 CI 方面表现惊人。撰写本文时，最近一次构建耗时约 2 分 30 秒，在一台巨大的机器上使用了非常、非常多的并行通道，CPU 利用率尚可，尽管 60 秒的尾巴还有很大改进空间！ 一张构建机器的 CPU 使用图表，在大部分构建过程中上升到约 75%，然后在最后 60 秒逐渐下降。一次构建期间的 CPU 利用率。CI 流水线瀑布图：数十个构建和测试通道并行运行，几乎都在大约一分钟内完成。54 个通道，大部分并行。耗时 2.5 分钟。 ### 7. 你的团队是否能轻松部署新工具和智能体，用于开发并协助处理开发相关的所有事务？ 评估是否值得构建一个工具(https://xkcd.com/1205/)的先验数学模型现在已不准确，因为编码智能体可以一次性构建出相当不错的工具。必须能够轻松托管并在这些工具上进行迭代(https://blog.exe.dev/devtools-must-be-open-source)。 ### 8. 你的团队成员是否定期讨论他们的工具、工作流程，并在必要时进行调整？ 我们身处一个探索的时代(https://blog.exe.dev/bones-of-the-software-factory)，与同行分享哪些有效（以及哪些无效）至关重要。这一直是个好主意，但如果你不这样做，现在你就会错失复合效应。我们不断这样做：在 Slack 上、电话里以及我们的团队会议中。 ### 9. 对于编码智能体作为用户而言，你的产品是否易于理解？ 你的用户正在根据 Claude Code 是否能操作它来评判你的软件。它能做到吗？你是否有一个非常明显的文档 llms.txt (https://exe.dev/llms.txt)？身份验证有效吗？API 再次成为王者。 无意在此大谈克莱顿·克里斯坦森的理论，但一个由中等水平编码智能体操作的更差的产品，正在摧毁那个编码智能体无法使用的更好的产品。