本文永久链接 – https://tonybai.com/2025/10/18/revisit-extreme-programming-in-the-age-of-ai

大家好，我是Tony Bai。

AI 编程助手、自动化代码生成、Agentic 开发系统……我们正目睹一场由 AI 引领的软件生产力革命。代码的产出速度正以 5 倍、10 倍甚至更高的倍率疯狂增长。理论上，我们应该能更快、更好地交付软件。但现实却给了我们一记响亮的耳光：我们的软件交付成功率，数十年来几乎毫无寸进，甚至有所倒退。

这就是 AI 时代软件开发的核心悖论：我们获得了前所未有的“产出”速度，却未能将其转化为更高的“成功”概率。最近，一篇题为《我们是否应该在 AI 时代重温极限编程？》的文章深入探讨了这一现象。文章作者尖锐地指出，我们可能正陷入一个“速度陷阱”，用最先进的工具去解决一个早已不是瓶颈的问题。

本文将和大家一起解读一下这篇文章的核心论点，探讨为何“速度”本身无法带来成功，以及为什么作者认为，那条通往高价值交付的道路，可能需要我们重温极限编程（Extreme Programming, XP）的智慧。

产出的幻觉：我们一直在加速，却在原地打转

文章的核心论点始于一个简单而深刻的观察：代码的生成速度，从来就不是软件开发的根本瓶颈。作者回顾了过去几十年的技术演进，从高级语言到 DevOps，再到云原生，每一次变革都极大地提升了代码产出效率，而 AI 只是将这条“加速”之路推向了极致。

为了支撑这一观点，文章引用了多项权威数据，揭示了一个残酷的现实：

• 根据长期运行的 Standish CHAOS 研究报告和麦肯锡的分析，超过 70% 的数字化项目仍以失败告终。
• 从 1994 年到 2020 年，尽管工具链发生了翻天覆地的变化，但项目按时、按预算成功交付的比例净增长微乎其微。

作者由此得出结论：我们只是在更快地制造砖块，却不知道如何用它们建起一座坚固、美观且符合用户需求的房子。当 AI 将制造砖块的成本降至接近于零时，设计的蓝图、工匠的协作和地基的稳固，就成了决定成败的唯一关键。

失控的熵增：AI 如何放大我们最坏的习惯

在文章的分析中，最一针见血的部分莫过于其对 AI 风险的论述。作者认为，当代码生成变得毫不费力时，一个更致命的风险随之而来：我们生产软件垃圾的速度，远远超过了我们验证和清理它的速度。

在没有严格约束的情况下，文章指出 AI 会成为“坏习惯”的放大器：

1. 快速堆积技术债: AI 可以迅速生成大量未经深思熟虑的逻辑，形成一个无人能懂、难以维护的“意大利面条式”代码迷宫。
2. 固化错误的假设: 作者引用了近期研究，表明大语言模型（LLM）的准确性会随着上下文窗口的增长而下降。这意味着 AI 极易在长链条的生成中引入微小错误，并基于这些错误继续构建，最终导致整个系统的脆弱性。
3. 绕过人类协作: 文章还表达了一种担忧，即开发者可能会倾向于“与 AI 结对”，而不是与同事协作，这将严重削弱团队的共享上下文（Shared Context）——这是解决复杂问题、确保软件长期健康的最宝贵资产。

文章的观点是，AI 让我们以前所未有的速度，构建出我们自己都无法理解和控制的复杂系统，而这恰恰是极限编程（XP）从诞生之日起就致力于解决的“失控的熵增”问题。

XP 的反向智慧：唯一的出路是“刻意放慢”

面对这种由 AI 加剧的困境，文章提出了一个看似有悖常理的解决方案：拥抱极限编程（XP）的反向智慧，即通过“刻意的摩擦”来“刻意放慢”。

作者对 XP 的核心实践进行了重新解读：

• 结对编程 (Pair Programming): 它被描述为一种内置的实时代码审查、知识传递和风险对冲机制，其目的不是减慢速度，而是强制建立共享上下文。
• 测试驱动开发 (TDD): 文章强调，TDD 强迫我们将关注点从“实现”拉回到“意图”，在写任何功能代码前，先定义清楚“我们到底想让系统做什么”。
• 持续集成 (CI) 与小批量发布: 这些实践被视为创建短而快的反馈循环的关键，使团队能以最小的成本发现错误、验证假设并调整方向。

在作者看来，XP 的所有实践都在为一个终极目标服务：通过极致的沟通、简约的设计和快速的反馈，来对抗软件开发中固有的不确定性。

小结：答案在人，不在代码

回到最初的问题：AI 带来了 10 倍的速度，为何成功率停滞不前？

《我们是否应该在 AI 时代重温极限编程？》这篇文章给出的答案清晰而坚定：因为我们错误地将“代码产出”等同于“价值交付”。作者在文末总结道，软件开发的真正瓶颈，从来都不是写代码的速度，而是：

• 我们是否在构建正确的东西？（目标对齐）
• 团队成员是否对目标和现状有共同的理解？（共享上下文）
• 我们能否快速、低成本地验证我们的想法？（反馈循环）

AI 无法自动解决这些问题，甚至可能使它们恶化。因此，文章的最终呼吁是，在 AI 时代，最具竞争力的团队，不是那些使用 AI 写代码最快的团队，而是那些能将 AI 的强大生产力，置于一个高度纪律化、以人为本的协作框架之下的团队。

这篇充满洞察力的文章提醒我们：软件的终点是为人服务，它的过程也必须围绕人来构建。这或许才是打破“速度陷阱”，实现真正成功的唯一途径。

资料链接：https://www.hyperact.co.uk/blog/should-we-revisit-xp-in-the-age-of-ai

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/10/18/lessons-from-java-26-years-evolution

大家好，我是Tony Bai。

历史不会简单重复，但总是惊人地相似。编程语言的演化，如同一部波澜壮阔的史诗，充满了智慧的闪光、艰难的抉择与深刻的教训。

上月，资深工程师 Neil Madden 发表了一篇引人入胜的文章《点评 26 年的 Java 变更》，以一位亲历者的视角，犀利地回顾了这门“常青”语言的演进之路。

注：Neil Madden口中的Java 26年是指自他1999年学习Java编程开始到2025年的今天。

从Gopher视角来看，这并非一篇简单的技术评论，而是一次宝贵的以史为鉴的机会。

Java 作为企业级开发的“前浪”，其三十年的漫长的发展历程就像一本厚重的教科书，记录了在引入泛型、改进 I/O、简化并发等几乎所有重大议题上的探索与挣扎。

对于 Go 语言乃至整个软件工程领域而言，这其中蕴含着超越语言本身的普适性启示。本文并非旨在对比 Go 与 Java 的优劣，而是希望作为一部“技术沉思录”，通过 Java 这个案例，与各位一同探寻编程语言演进的内在规律。

启示一：核心特性的引入，时机与设计的艺术

Java 5 (2004) – 泛型 (Generics)

“as Go discovered on its attempt to speed-run Java’s mistakes all over again, if you don’t add generics from the start then you’ll have to retrofit them later, badly.”
（正如 Go 在其“快速重蹈 Java 覆辙”的尝试中发现的那样，如果你不从一开始就加入泛型，那么日后就不得不糟糕地进行弥补。）

Java 直到发布 8 年后才引入泛型。为了保持对海量存量代码的向后兼容性，它做出了一个影响深远的妥协：类型擦除 (type erasure)。这个决定虽然在当时解决了燃眉之急，却也带来了诸多“粗糙的边缘”，如反射处理困难、无法对泛型类型进行 instanceof 判断等，至今仍是 Java 开发者的痛点。

由此看来，语言核心特性的引入，是一场关于时机与设计的精妙艺术。过早引入，可能因设计不成熟而留下历史包袱；过晚引入，则必然会受到向后兼容性的掣肘，导致实现上的妥协。Java 的经验深刻地揭示了“后补”式设计的代价。

Go 语言在发布 12 年后才于1.18 版本引入泛型，同样面临巨大的兼容性压力。幸运的是，Go 团队得以借鉴 Java 的教训，选择了一条更艰难但更正确的道路——结合”Stenciling方案”和”Dictionaries方案”的“GC Shape Stenciling 方案”，在编译时间(二进制文件膨胀)以及运行时开销方面做了一个折中，并且没有类型擦除。这为 Go 泛型的未来发展奠定了更坚实的基础，也印证了一个原则：对于动摇语言根基的核心特性，宁愿慢，也要做对。

注：关于Go泛型实现机制的详细说明，请参见极客时间《Go语言第一课》的第41讲《驯服泛型：明确使用时机》。

启示二：API 是语言的“遗产”，其影响远超想象

Java 1.4 (2002) – “New” I/O (NIO)

“Provided non-blocking I/O for the first time, but really just a horrible API… Has barely improved in 2 and a half decades.”
（首次提供了非阻塞 I/O，但 API 简直糟透了……在 25 年里几乎没有任何改进。）

Neil 对 Java NIO 的评价毫不留情。他吐槽其 API 令人困惑，并且 inexplicably（莫名其妙地）使用 32 位有符号整数表示文件大小，将文件限制在 2GB 以内，这成为了 Java I/O 长期以来的一个“历史污点”。

这也印证了这样一条结论：标准库的 API 一旦发布，就成为语言最宝贵也最沉重的“遗产”。

一个设计精良的 API 可以赋能一代又一代的开发者，而一个糟糕的 API 则可能成为数十年都难以摆脱的枷锁。它定义了开发者与语言交互的方式，深刻地影响着生产力、代码质量和开发者的心智模型。

Go 语言从诞生之初就拥有一个设计极其精良的 I/O 模型。io.Reader 和 io.Writer 接口的简洁与强大，至今仍是语言设计的典范。Go 的网络库 net 基于操作系统提供的非阻塞 I/O（如 epoll），并通过 goroutine 将其巧妙地封装为同步阻塞的编程模型。这使得 Go 开发者既能享受非阻塞 I/O 的高性能，又无需陷入复杂的回调地狱。Java NIO 的“失误”深刻地提醒我们，在 API 设计上投入再多的思考也不为过。

启示三：将正确的并发模型内置于语言，是生产力的巨大飞跃

Java 5 (2004) – java.util.concurrent
Java 19 (2022) – 虚拟线程 (Virtual Threads)

Neil 对 Doug Lea 的 java.util.concurrent (J.U.C) 包给予了满分盛赞，认为其设计极其出色。然而，他也指出，在苦苦挣扎于各种复杂的异步编程模型多年后，Java 才终于通过 Project Loom 引入了虚拟线程，试图在 JVM 层面实现 M:N 的轻量级并发模型。

并发是现代软件开发的基石。一种语言如何处理并发，直接决定了其生产力的上限。Java 的演进路径——先提供一套强大的、专家级的底层并发工具（J.U.C），然后在多年后才引入一个更高层次、更易于大众使用的并发模型（虚拟线程）——揭示了一条从“提供工具”到“提供模型”的演进规律。

Go 语言在这一点上扮演了“预言家”的角色。它从诞生之初就将轻量级并发 (goroutine) 和 通信 (channel) 作为语言的一等公民内置于运行时。这种 CSP (Communicating Sequential Processes) 模型，极大地简化了并发编程的心智负担。Go 的成功雄辩地证明了，将一个简单、强大的并发模型作为语言的核心特性，其带来的生产力飞跃，远非一个复杂的工具箱所能比拟。

启示四：警惕范围蔓延，敬畏生态兼容性

Java 8 (2014) – Streams API
Java 9 (2017) – 模块系统 (Modules)

Neil 对 Java Streams API 和模块系统给出了惊人的低分。他认为，Streams API 为了实现“看似简单”的并行计算而过度设计，变得复杂难用。而模块系统（Project Jigsaw）虽然初衷是解决 JAR 地狱，但其引入的巨大动荡和对现有生态的破坏性，使其得不偿失。

语言的演进充满了诱惑。一个好的特性，可能会因为被赋予了过多不相关的目标（范围蔓延）而变得臃肿不堪。任何试图“修正”语言底层生态的重大变革，都必须对生态兼容性抱有最大的敬畏。因为语言的生命力，最终源于其繁荣的社区和生态。

Go 在这方面也并非一帆风順。Go Modules 在诞生之初也曾引发巨大争议，但最终凭借其相对简洁的设计和 go 命令的强大集成能力，成功地统一了 Go 的依赖管理生态，其过程虽然有阵痛，但避免了 Java 模块系统那样的“大分裂”。Java 的这两个案例，为 Go 未来的任何重大变革都敲响了警钟。

小结：在巨人的肩膀上，继续沉思

回顾 Java 26 年的演进史，我们看到的不是一个失败者，而是一个不断自我革新、虽有失误但仍充满生命力的“巨人”。它的每一步探索，无论是成功还是失败，都为后来的语言（尤其是 Go）提供了宝贵的“启示录”。

Go 的幸运在于，它诞生得更晚，可以在“巨人的肩膀上”看得更远，从而在泛型、I/O 模型和并发等核心问题上，做出了更符合时代需求的设计。

然而，历史的镜子也照向未来。Go 如今也面临着自己的“沉思时刻”：如何平衡语言的简洁性与日益增长的表达力需求？如何演进标准库以适应新的挑战（这方面math/v2、json/v2做出了表率）？如何引入下一个可能具有破坏性的重大变革？

Java 的故事告诉我们，语言的演进是一场永无止境的马拉松。唯有保持谦逊，以史为鉴，并始终将开发者的真实需求和语言的内在哲学放在首位，才能在这场长跑中行稳致远。

资料链接：https://neilmadden.blog/2025/09/12/rating-26-years-of-java-changes/

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。