不被阅读的代码时代
Source: NHN Cloud Tech Blog
此内容是作者对在公司内部公告板上分享的文章进行加工的，为了忠实传达作者的意图和语境，保留了原文的句子风格。
前言
我长期以来一直梦想着优美的代码。
那种代码中，纯函数像水流一样组合，类型系统从根本上使 bug 不可能出现，逻辑像数学证明一样坚固。我们把它称为 ‘工匠精神’，为了达到这种境界，我们学习范畴论，努力理解类型层编程。
然而有一天，我突然意识到 再也没有人阅读代码。
可读性的定义正在改变
“可读性”这个词的意义正在悄然但根本地改变。
过去的可读性是为了 人类的认知。
- 开发者能在脑中追踪逻辑吗
- 同事在代码审查时能发现错误吗
- 6个月后我还能理解这段代码吗
为了回答这些问题，我们讨论了 Clean Code（干净代码），制定了 SOLID 原则，并创建了 设计模式 这一共同语言。这都是在人类有限的工作记忆容量内处理复杂性的努力。
但现在，可读性正逐渐成为 机器的模式识别 的需求。
- AI 是否在训练数据中见过这段代码的模式
- AI 在收到修改请求时能否定位到准确位置
- AI 在进行局部修改时，整个系统是否仍然保持完整
两种可读性有时会重叠，但本质上优化的目标不同。
- 为人类服务的可读性追求 抽象和压缩。
- 为机器服务的可读性追求 明确性和可预测性。
工匠精神的悲剧性位置
函数式编程所承诺的很明确：用代码克服人类的认知局限。
- 引用透明性：代码的任何部分都可以独立推理
- 不可变性：减少在脑中追踪随时间变化的状态的负担
- 强类型系统：编译器帮助捕获错误
所有这些都是为了补足人类的局限的工具。
然而对 AI 来说，没有需要补足的局限。AI 已经学习了数百万个代码库，并装备了原始的模式匹配能力。为减轻人类认知负担而设计的优雅抽象对 AI 来说更像是噪音。AI 更习惯于普通且重复的命令式代码。
“学习起来很困难，但有长期收益。” – 函数式编程支持者
AI 打破了命令式编程的入门壁垒。现在任何人都可以借助 AI 快速编写命令式代码。相反，函数式编程的学习曲线仍然陡峭。更令人感到凄凉的是，即使是能够欣赏函数式编程之美的人也不再亲自阅读代码。他们的 Claude Code 取而代之地进行阅读。
Claude >> @PureFunctional OrderService::doStuff의 로직을 분석해서 설명해 줘退化为媒介的代码
代码的本体论地位正在改变。
过去，代码是人类的领域。我们生活在其中。每天阅读、修改、扩展。为一个变量名纠结，为函数的位置争论。代码是我们思想的物化，因此我们关注它的美感。
现在代码正成为连接人类意图与机器执行之间的媒介。
인간의 의도 → 자연어 명세 → AI → 코드(누가 신경이나 쓰는가) → 실행在这个模型中，函数式 vs 面向对象的争论类似于 x86 vs ARM 的争论。虽然在特定情境下可能存在性能差异，但它已不再是人类居住的层面。我们正从木匠转变为建筑主。
新的美学的出现
AI 时代的‘好代码’是什么？需要新的美学。
习惯表达胜过优化
// AI 友好：数百万次见过的模式
users.stream().filter(User::isActive).toList();
// AI 不友好：这是什么代码？
users.stream().reduce(new ArrayList<>(),
(acc, u) -> { if(u.isActive()) acc.add(u); return acc; },
(a, b) -> { a.addAll(b); return a; });AI 擅长处理熟悉的事物。相比创造性的优化，普通的惯用表达更安全。
推理的局部性
理解函数所需的一切要么可见，要么能够一次跳转到达。Action at a distance 是禁忌。Dependency injection技巧、aspect weaving、runtime proxy 等隐式机制会妨碍 AI 的推理。
可预测的结构
/order
OrderController.java
OrderService.java
OrderRepository.java
Order.javaAI 从惯例中推断上下文。如果能够预测文件位置，搜索成本会降低。惯例是压缩的信息。
明确的状态转移
// AI 友好：可能的状态被显式枚举
enum Status { DRAFT, SUBMITTED, FULFILLED }
// AI 不友好：需要通过标志组合推断状态
boolean isSubmitted;
boolean isFulfilled;
boolean isDraft;使用枚举声明状态时，AI 能够一目了然地把握整体图景。需要组合多个 boolean 标志的代码会让 AI 也迷失方向。
冗长但明确的名称
// AI 友好：仅凭名称即可明确意图
public boolean isEligibleForRefundBasedOnPurchaseDateAndMembershipStatus()
// AI 不友好：依赖注释
/** 依据购买日期和会员状态判断是否可退款 */
public boolean canRefund()对人类而言，简洁的名称加上详细的注释可能更易阅读。然而 AI 更信任 代码本身而非注释。如果函数名本身就包含意图，就可以在没有额外上下文的情况下准确使用。
小文件，单一职责
100 行的文件 10 个胜过 1000 行的单个文件。AI 的上下文窗口是实际的限制。小文件更容易整体替换或局部修改。
以测试为规范
@Test
void shouldRejectOrderWhenInventoryInsufficient() { /* ... */ }AI 通过读取测试来逆向推断代码意图。测试名称即是需求，测试主体即是示例。
讽刺：函数式的回归
有一个有趣的反转。AI 友好代码的原则——不可变性、显式状态、小而纯粹的函数——与 函数式编程 的原则高度重合。函数式编程将会存活下来。不是因为它美，而是因为 机器更容易阅读。
即使高层次的抽象和理论的优雅消失，不可变数据、纯函数、显式类型仍然存在。美学已经改变，但核心原则因其他原因获得了新生。
结论
我们站在美好时代的尾声。
- 以代码为媒介，人类之间相互交流的时代
- 将意图写入变量名，用函数结构表达思维流程的时代
那个时代正在逝去。代码正逐渐进入不经过人类眼睛的领域。正因为我们曾在代码中生活，才在意其美感；一旦走出代码，那美感便失去意义。工匠精神将像 LP 唱片或 机械表一样——成为热爱过程者的领域。市场不识别优雅，市场只要 速度。AI 已将命令式代码的速度几乎提升到无限。
尽管如此，我们偶尔仍记得下班后在安静的办公室里，完成的纯函数链通过测试，绿灯亮起的瞬间。类型系统在编译时捕获 bug 的快感。代码不仅仅是运行，更成为 证明 时的满足感。
美好的回忆。
