IT 应该停止 Cork-Sniffing 工具，回归工程基础

Source: Dev.to

抱歉，我需要您提供要翻译的具体文本内容（除代码块和 URL 之外）。请粘贴文章的正文，我会按照要求将其翻译成简体中文并保留原有的格式。

现代 IT 面临一个奇怪的问题：它不停地谈论工具，却日益在工程上捉襟见肘。

框架、平台、技术栈、云、编排器、模式以及“最佳实践”主导了讨论。成功往往以采用曲线、生态系统规模和简历关键词来衡量。与此同时，系统变得更加复杂、难以推理、在故障时更脆弱，而且寿命比以往任何时候都更短。

这不是进步。 这是一种从工程学到消费主义的文化倒退。

工程不是工具的应用

在每一个成熟的工程学科中，工具都是从属的。

• 土木工程师并不是由 AutoCAD 定义的。
• 机械工程师并不是由 CNC 机床定义的。
• 航空航天工程师并不是由 CFD 软件定义的。

工具帮助计算和执行。它们 不 定义解决方案。

工程在使用工具之前就已经开始，涉及以下问题：

• 存在什么问题？
• 哪些约束是真实的？
• 哪些失效模式是可以接受的？
• 满足正确性的最简结构是什么？
• 这个系统必须活多久？

在 IT 领域，这一顺序常常被颠倒：“我们在使用 [X 框架] ——现在我们能用它解决什么问题？”
这种倒置是许多现代架构功能失调的根源。

我们忘记的工程定义

跨学科来看，共识是明确的。工程是创建系统的学科，这些系统：

• 在定义的约束下能够正确工作。
• 能够可预测地失效。
• 能被未来的工程师理解。
• 在变化中保持稳健。

注意 不 在该定义中的内容：

• 新奇性。
• 为了灵活性而灵活。
• 工具的复杂程度。

工程优化的是正确性、清晰度和寿命，而不是迎合潮流。

简单即风险控制

“最简解”常被误解。它并不意味着最少的代码、最快的原型或最少的文件。
它指的是 为推理正确性所需的最少概念。

在软件中，简洁通过以下方式实现：

• 直接建模业务领域。
• 在局部强制不变量。
• 保持控制流显式。
• 除非能自我抵消，否则避免间接层。

复杂性不是中性的。每一个抽象都会引入失效模式。每一个框架都会添加你未设计的行为。除非你在解决分布式系统问题，否则分布式架构不是特性，而是 bug。

工具掩盖了责任

以工具为中心的 IT 文化制造了一种危险的幻觉：“只要我们正确遵循框架，正确性就会自然出现。”

事实并非如此。框架并不理解你的业务领域、你的不变量或你的经济约束。它们编码的是为广泛适用而优化的通用假设，而非特定的正确性。

当故障发生时，工具优先的系统往往以模糊的方式失败：超时却没有状态确定性、部分成功却缺乏可视性、补偿操作却没有保证。

真正的工程系统会以响亮且确定的方式失败。

单例现实

一个关键观察常被忽视：每个 IT 系统都是单例。

没有真正的 A/B 对比——没有相同的流量、用户或运营环境来比较 “工具 A” 与 “工具 B”。因为没有对照组，工具几乎从未被证伪。它们是通过关联而非证明被采纳的。

• 如果系统工作，工具获得功劳。
• 如果系统失败，业务领域或执行过程被指责。

成熟的工程学科通过形式化推理、保守设计和明确假设来缓解这种不可证伪性。IT 往往用轶事和流行度来取代这些手段。

经济成本：意外复杂性

失去工程纪律的代价并非抽象的，而是经济性的。

在过去的几十年里，价值可观的企业系统往往由小团队（5–15 名工程师）构建并维护，能够持续运行数十年。如今，功能相同的系统往往需要更大的团队、更频繁的重构，寿命也大幅缩短。

Source: …

可比的系统——被编排层、微服务蔓延以及持续的重新平台化所臃肿——往往需要团队规模是原来的三到四倍，仅仅是为了“保持灯光亮起”。

这就是 Accidental Complexity 的爆炸。

我们用认知约束取代了硬件约束。我们并没有获得 5 倍的业务价值；我们却要为我们自己因抛弃基础而引入的复杂性付出 5 倍的代价。

为什么工具占据主导地位

对工具的痴迷并非偶然产生。它解决的是 组织 问题，而不是工程问题：

• 入职速度。
• 开发者可互换性。
• 供应商对齐。
• 招聘渠道。

公司常常用 运营效率（系统稳定性和低维护成本）换取 招聘效率（能够随时插入一个 “Spring Developer”）。

然而，这是一种错误的经济学。招聘上获得的效率在维护的沉重负担以及周期性的整体重建成本面前会被多次抵消。净回报是深度负面的。然而，单例幻觉产生了盲点：没有对照组来展示系统本可以有多么稳定，组织便把混乱视为常态，误把自招的复杂性当作软件固有的难度。

回归基础

“回归基础” 不 意味着拒绝工具。它意味着：

• 减法工程（Subtractive Engineering）： 成熟的工程通过去除不必要的部件和投机性的抽象来进步。
• 主权领域模型（Sovereign Domain Models）： 业务逻辑决定工具，而不是相反。
• 显式状态（Explicit State）： 更倾向于确定性而非神奇的编排。
• 为失败而设计（Design for Failure）： 假设系统的部分会失败，并在代码中显式处理。

结论

IT 并不是缺少工具，而是缺乏工程约束。

只要软件工程师停止盲目追逐工具、回归工程基础，意外复杂性的循环就会持续。

tals — 简单性、正确性、明确性和责任感 —— 系统将继续变得更加复杂，同时可信度下降。

解决方案不是另一个框架。

而是判断。