持续集成（CI）失败了。这令人意外。我已经将我的代理工作流程调整到了一个程度，如果我的一个代理提交了有失败测试的分支，我会感到惊讶。也许这是CI不稳定或者环境问题？等等，SonarQube在抱怨App.tsx？我们是不是从npm中拉入了一个可疑的新依赖？不是的。SonarQube标记这个文件是由于圈复杂度。我有一段时间没见过这个了。没错，App.tsx大约包含30行代码，除了其中15行实际上是Codex决定每行写一个完整组件。这样本身没问题，只需通过prettier格式化一下，我们就完成了。但这并不能解释圈复杂度。每个组件都是相当复杂的，包含了大量的显示和业务逻辑。以前的我会仔细重构确保代码可读。另一方面，Codex并不关心整个组件位于单行，并且，更重要的是，它并不在意复杂性。它一直在对该文件进行愉快而可靠的迭代，增加了几个功能。CI工具标记了一个问题，也许是正确的，也许是错误的。但这是一个真实的系统，所以我必须深入研究。在格式化文件后，我检查了组件和逻辑。Codex是否超越了典型开发者在处理边缘情况方面的覆盖，并稍微过度设计了？是的，但这一切都是正确的。我没有任何抱怨。所有的复杂性都是由业务需求所要求的。所以我告诉Codex让SonarQube满意，它通过将内容重构并拆分成10个文件来满足了这一要求。CI通过了；代码交付了。尽管此事件迅速解决，你可以想象这本可以变得更糟。毕竟，这是我从未见过的代码。这是我们行业发展的方向：拥有一个软件系统将与手动编写它（或类似系统）关系不大；相反，最重要的将是了解足够多以知道何时出现问题，并在需要时愿意并能够深入研究。潜水机器人和黄金小块想象一下，你在一艘船上（你决定你喜欢什么类型的船），你的工作是从海洋底部收集黄金小块。直到最近，如果你想要获取你的黄金袋，你需要跳入水中，游到底部，环顾四周，装满你的袋子。如果是在清澈的浅水中，这很简单，但你可以想象这会迅速升级为更困难的事情。因此，当浅水矿开始干涸时，你和同事工程师们建立了各种机器和工具，从越来越深且更危险的水域提取黄金。这在大多数情况下效果良好，你和你的团队会小心地组装、维护、更换机器，并不断潜入海底矿业操作以保持其运行。时不时你会听到一些矿业操作崩溃，有时是由于水下压力过大，其他时候是因为事故，或者操作员无能。挑战在于这是一个地质活动非常频繁的世界，因此海底随着一些矿干涸和新的矿在不同地方冒出而不断变化。好消息是！过去几年发展出了越来越复杂的潜水机器人，能够自己下去建立采矿作业。你只需告诉它们在哪里建造，它们就会潜入，只在给你更新和黄金小块时浮出水面。一切都很好，你现在可以在船上放松，而潜水机器人则在忙碌，你需要担心的只是在船上装多少黄金。这是乐观主义者的阵营。直到……“等你的潜水机器人潜得太深而迷路”。“哈哈你的潜水机器人给你带来的东西看起来像黄金，但实际上是闪亮的章鱼粪便”。随着潜水机器人的激增，你看到越来越多的恐怖故事。潜水机器人迷路并忘记它们应该构建什么。潜水机器人构建出如此复杂和庞大的东西，以至于它们难以维护，最终被下一代潜水机器人抛弃。所有的水下采矿操作都从精心设计和工程的教堂变成了更像杂乱无章的豪宅，里面藏着隐藏的通道和可怕的东西。你与操作的脱节越大，失败就越壮观。这是怀疑主义者的阵营。这里有怪物软件工程行业（我怀疑其他许多行业很快也会这样）正在经历上述场景的一个版本。你可能已经知道怀疑者还是乐观者更能描述你，即使你仍然不确定你想加入哪个阵营。传统的智慧是，为了开发和维护一个非平凡的系统，你需要拥有一个适当的工作模型。我认为很少有人会对此提出异议。