写代码很简单，读懂它才是难事

原文：https://idiallo.com/blog/writing-code-is-easy-reading-is-hard

作者：Ibrahim Diallo, Gil

写代码是件容易事。一旦你脑子里有了解决方案，又掌握了你最喜欢的编程语言的语法，写代码真的不难。让大语言模型（LLM）帮你写出整个函数？那就更容易了。但真正的难点不在于写，而在于读。难的是，你需要花时间在脑海里构建起对整个系统的认知地图。这才是所有成本的真正所在。

心智模型 (mental model) 就是你在阅读代码时构建的东西。它是你对系统如何工作的内部地图，上面标注着哪些地方是雷区，哪些东西依赖于另一些东西。没有这张地图，你看到的就只是一行行毫无生气的文本。

我当外包程序员的时候，大部分工作都是以同样的方式开始的。我会接到一个任务，去修复一个我从未见过的应用程序里的 Bug，或者给它增加一个新功能。一开始，我的心智模型一片空白。为了填充它，我会先去看看网站主页长什么样。然后我会查看页面源代码：这是用 React 写的？还是 jQuery？或者某个第三方插件？我会浏览整个代码库，看看他们要在首页上加的那个轮播组件，在别的地方是不是已经用过了。我还会检查他们的构建流程、测试配置，以及他们依赖的工具。我发现的每一个小细节，都会被添加到我脑海中的那张地图里。

这感觉就像搬到一个新城市。你从公寓楼下开始，在几条街道上闲逛，慢慢注意到哪条路通向高速公路，杂货店在哪里，然后你开始逐渐找到方向感。读代码就是这种感觉：你在绘制一幅心智地图，这样你下次在代码里穿梭时就不会迷路。

比如说，你需要理解一个简单的函数，像 getUserPreferences(userId) 这样。要构建关于它的心智模型，你需要追溯以下这些问题：

  • 这个函数是在哪里定义的？

  • 它返回什么？是一个 Promise 吗？返回的数据结构是什么样的？

  • 它是直接访问数据库，还是通过一个 API？

  • 中间有没有涉及到缓存层？

  • 如果用户不存在，会发生什么？

  • 还有谁在什么场景下调用了这个函数？

  • 它有没有副作用 (side effects)？

要理解这一个函数，就意味着你得在数据库结构、API 定义、错误处理中间件和多个调用点之间来回跳转。只有在构建起这张关系网之后，你才有足够的上下文信息去安全地修改任何东西。

这个过程非常缓慢。读代码比写代码难得多，难太多了。写代码像是在往前走：你在铺设一条崭新的路。而读代码则意味着要追溯别人的脚步，这通常意味着在不同文件间跳来跳去，追踪函数调用，推断副作用，还要揣摩那些没有被白纸黑字写下来的意图。为了理解一个函数，你常常需要查看其他五个文件。做完所有这些之后，你才算有了一张足够让你起步的地图。

这也是为什么调试 (debugging) 比写代码更难。在 Stack Overflow 网站上，一个烂问题下面最常见的评论之一就是：“你能把你的代码贴出来看看吗？” 因为看不到你走过的路，就没人能在脑海里加载正确的模型来帮助你。这也解释了为什么 XY 问题 (XY problem) 总是反复出现。人们只问一个表面症状，却不提供能让别人重建整个问题图景的上下文。

我至今仍对那个在法庭上使用 ChatGPT 的律师感到着迷。他提交了一份法律文件，里面引用了六个根本不存在的案例。所有人都问：他为什么不去读一下这些案例呢？答案是一样的：因为构建心智模型需要时间和精力。他本应去追踪每个案例，阅读它们，然后将它们放入对法律先例的宏观理解中。阅读，才是最难的部分。生成，太容易了。

阅读不仅仅是逐行检查代码。它还包括通读文档、参与代码审查和结对编程。实际上，这些方法都是为了加速我们构建心智模型的过程。但即便如此，你终究还是要亲自去读、去理解。你会发现，程序员总想把东西从头重写一遍，因为他们觉得“旧代码烂透了”。真正烂的，是花时间去读懂它、理解它。

这正是大语言模型在编程领域既强大又危险的地方。无论 AI 生成的代码是完美无瑕还是纯属幻觉，你都必须去读它。你仍然需要追溯它应该做什么，它如何与系统的其他部分交互，以及它的副作用是什么。生成的代码越长，构建心智模型所需的时间就越长。只有当你完成了这个过程，你才能发现问题所在，发现那些生成代码不太适配的地方，或者它在悄悄地破坏其他功能。

当一个大语言模型可以无限量地生成代码或文本时，它诱使我们跳过阅读这个环节。但你无法跳过构建心智模型。就好比你绝不想加载别人的游戏存档，结果一上来就直接被扔进 Boss 战的战场中央。继承或生成一份你根本不理解的代码，就是这种感觉。

这就是为什么软件开发的真正瓶颈不在于“写”，而在于“理解”。

目前，我们还没有能与大语言模型相媲美的“理解工具”——那种能瞬间将整个系统的心智模型从机器灌输到你脑子里的东西。在那一天到来之前，瓶颈依然存在。我们解决了“打字速度”的问题，现在我们能生成的代码，远比我们能读懂的要多得多。但是，除非我们解决了“理解”的问题，否则软件开发的成本依旧没变：它还是取决于一个人需要花多长时间才能搞懂这一切。

这对我们如何使用 AI 工具有着实实在在的影响。与其让 AI 生成大段大段的代码，不如让它帮助我们理解现有的代码。与其用代码行数来衡量生产力，我们或许更应该用团队能多快地为他们的系统建立起准确的心智模型来衡量。

编程的未来，可能不在于更快地生成更多代码，而在于更快地生成“理解”。而这，是一个难得多的问题。

原文链接: https://idiallo.com/blog/writing-code-is-easy-reading-is-hard

See all posts