反脆性编程与AI为何不会抢走你的工作

每当我表示不喜欢调试，并围绕避免调试来组织我的编程习惯时，总会遇到反驳：“你一定是没用过好用的调试器。”

概括一下我的观点：我希望我的软件是反脆弱的（这个概念归功于纳西姆·塔勒布）。我在一个代码库上工作的时间越长，修复错误就应该变得越容易。

对一段代码的每一次添加都可以看作是一种压力。如果什么都不做，代码会稍微变差，更难维护，更容易出问题。值得庆幸的是，你可以避免这种结果。

这并不自然。对于大多数缺乏深厚专业知识的开发者来说，随着代码库的增长，错误会变得难以修复：你需要在层层代码中追踪症状，追捕那些在调试器中消失的海森堡错误，或者修复了一个错误却引发了另一个。代码越多，情况就越糟。这样的代码是脆弱的。添加一个新功能可能破坏旧的、看似无关的部分。

在我看来，无法产出反脆弱代码的现象解释了编程中极端的幂律分布：我们日常所依赖的大部分代码，都是由一小部分掌握了反脆弱性的程序员所写的。

如何扭转这一点？如何确保你在代码上工作的时间越长，错误就越浅表？

有一些众所周知的技术，添加大量的测试和检查肯定有帮助。你也可以在不写测试或调试时检查的情况下编写反脆弱代码……但你需要功能上等价的东西。

那些大而化之的处方（“你必须使用X语言、Y工具、Z方法”）通常是货船崇拜式的胡扯。模仿林纳斯·托瓦兹的工具或咒骂风格并不能保证成功。但反脆弱性不是处方，而是一个期望的结果。

防御性编程本身并无争议——但在20世纪80年代它并不常见，即使今天对许多人来说也仍非默认选项。

当然，完全的防御性方法并不总是适用或值得付出成本。

例如，如果我正在“氛围编码”一个快速网络应用，其JavaScript代码多到我懒得细读，我就直接让它在浏览器的调试器中运行。这没问题。我不是在用这段代码来控制心脏起搏器，也不指望在圣诞节凌晨被叫醒去修复它。

如果你的程序只有500行，并且一年只运行20次，那么追求反脆弱性就不值得。

大型语言模型可以生成防御性代码，但如果你自己从未写过防御性代码，并且主要依靠AI辅助来学习编程，你的软件很可能仍然是脆弱的。

你可以快速添加代码，但添加得越多，问题就越大。

这就是问题的关键。写代码从来都不是最难的部分——我12岁时就会写代码，今天无数12岁的孩子也能写简单的游戏和应用。同样，一个12岁的孩子可以用锤子、钉子和木头搭一个狗窝。做到80%的程度一直都是容易的。

扩展复杂性而不至于让一切崩溃——这才是困难的部分。