编译 | 褚杏娟、核子可乐
Martin Fowler 是软件架构乃至整个技术行业中最具影响力的人物之一。这位 62 岁的软件开发专家，是 ThoughtWorks 的首席科学家，也是《重构》《企业应用架构模式》等多本著作的作者。数十年来，他一直在塑造工程师对设计、架构和流程的思考方式，并在他的博客 MartinFowler.com 上持续发表见解。
作为一个见证了互联网时代兴起的资深开发，他也面临新技术带来的变化。在近期的 The Pragmatic Engineer 节目中，Martin 讨论了 AI 如何改变软件开发：从确定性编码向非确定性编码的转变、大模型如何帮助处理遗留代码，以及 vibe coding 那些有限但很有用的应用场景。
Martin 还解释了为什么必须对大模型的输出进行严格测试、为什么重构比以往任何时候都更重要，以及如何把 AI 工具与确定性技术结合，可能正是工程团队所需要的方向。他谈到，尽管工具和工作流程在快速变化，但造就一名优秀工程师的核心能力在很大程度上始终未变。
他认为，今年科技界的大规模裁员是软件开发行业正处于“萧条”状态的一个迹象。Layoffs.ai 数据显示，截至目前，2025 年科技行业的裁员人数已达约 11.4 万，而 2024 年全年的裁员人数则接近 15.3 万。他指出，在当前这个“充满不确定性”的时代，企业不愿投资软件。而且，尽管科技界正大力投资 AI，但这种增长似乎是“另一个独立的领域”，而且“显然存在泡沫”。
我们翻译了这次采访，并在不改变原意基础上进行了删减，以飨读者。
1
个人成长历程
进入软件工程领域
主持人： 能和我们说说你是如何进入软件开发领域的吗？毕竟这已经是几十年前的事了。
Martin： 其实这挺偶然的。我上学时文科特别差，但凡沾写作的科目成绩都一塌糊涂，但数学、物理这类还不错，所以就挺偏向工程类的东西。我本身对电子产品也感兴趣，可动手能力实在太差，那些要体力、讲身体协调性的活儿都干不了，比如车上生锈的螺母我都拧不下来，因此好多工程领域都不适合我。不过电子学还行，顶多需要会个焊接，没别的复杂要求。后来接触到电脑，发现特别顺手，就这么慢慢摸进了计算机领域，这也是我入行软件开发的契机。
上大学前，我还在英国原子能管理局干过一阵子，那会儿用 Fortran 4 写了些程序，觉得这技能挺实用的。大学我学的是电子工程和计算机科学交叉专业，毕业后有两个选择：要么进传统工程领域，薪资和地位都一般；要么闯计算机领域，当时看起来机会明显更多，我就选了后者。
主持人：那时候互联网还没兴起，当时能找到什么样的工作？你的第一份工作是什么？
Martin： 我第一份工作是在 Coopers & Lybrand 这家咨询公司。我所在的小组是做信息战略咨询的，但我的工作不一样，因为我大学学过 Unix，是公司里少数懂 Unix 的人之一，所以我主要负责维护一批工作站，这些机子是用来跑他们做战略工作的一款专用软件的。
后来我慢慢对他们的战略工作也感兴趣了，就慢慢涉猎其中。现在回头想想，当时不少东西其实都挺华而不实的，但这确实是我入行的契机，还让我很早就接触到了面向对象的思维，对我后来的发展很有帮助。
主持人：你是如何接触到面向对象编程的？要知道在当时，面向对象编程可是很前沿的东西，而你所在的咨询公司似乎并不是最前沿的那种。
Martin： 虽说我们公司整体其实不算多前沿，但我待的小组却在在做一些前前沿的事儿。那会儿我们碰到一个人，这人满脑子都是新奇想法，其中不乏一些特别亮眼的观点，当然也有一些略显疯狂的想法。他还特意用“面向对象”这个专业术语来包装这些想法，虽说当时那些内容和真正的面向对象理念其实没完全对上，也算之前说的那种华而不实的东西之一，但平心而论，他的不少想法确实很有价值。
也正因为这个契机，我才开始往这个方向深耕，后来也慢慢摸清了面向对象编程的真正内核，直接奠定了我之后十几年的职业基础。
加入 ThoughtWorks
主持人：你是如何一步步发展，最终加入 ThoughtWorks 的？而且你还开始写书、发表文章，从一个刚入行、充满好奇的新人，慢慢变成了一个能够指导他人的人，这个过程是怎样的？
Martin：说起来，我的职业轨迹里充满了巧合。在 Coopers & Lybrand 工作时，我遇到了一个美国人 Jim Odell，他可以说是我早期职业生涯中最重要的导师。他是信息工程领域的早期实践者，兼具顾问和教师身份。他总能从各种新概念、新理论里，精准识别出真正有价值的部分，并带着我深入理解。
在那家公司工作了几年后，我离职加入了一家叫 PEK 的小公司。那家公司在英国的办公室只有四个人，而这已经是公司最大的办公室了。在那里待了两年后，我决定成为独立顾问。多亏了 Jim Odell 给我介绍了很多工作机会，加上我在英国本地也接到了一些项目，所以一开始发展得相当顺利。当时我还在心里想：“从此以后，再也不会给任何公司打工了。”结果……这句话后来成了“名言”。
整个 90 年代，我做独立顾问做得风生水起，期间还写了我的第一本书。后来我参与了 Chrysler 的 C3 项目，与 Kent Beck 一起工作，亲眼见证了极限编程（XP）和敏捷方法论的诞生。1993 年我搬到了美国，生活也过得很愉快。90 年代末互联网腾飞，行业非常活跃。就在这期间，我开始接触 ThoughtWorks。
最初它只是我的客户。当时他们在做一个大项目，大约 100 人，规模不小，但看起来马上要“炸掉”了。我帮他们梳理问题、止住下滑，最终也确实把项目救了回来。之后，他们向我发出了加入的邀请。
ThoughtWorks 有个很独特的气质：他们从不说“这很难，所以做不了”，他们会说“这确实很难，但我们可以试试”，而且往往还能真的把事情做成。正是这种精神吸引了我。我当时想：加入他们一两年也不错。结果没想到，这一待，就是 25 年。
主持人：你加入 ThoughtWorks 后，十多年来一直担任首席科学家一职，这个职位具体负责什么工作？
Martin： 说实话，我不是任何人的“Chief”，而且我也不做任何科学研究。这个头衔主要是“对外发声”的角色，当时业界流行给思想领袖一个这样听上去很厉害的头衔，比如 Grady Booch 当时就是 Rational 的 Chief Scientist。
更有趣的是，ThoughtWorks 允许每个人自定义自己的职称——但我不能。我不能叫“Flagpole”“Battering Ram”或者我最喜欢的 Loudmouth，只能用“Chief Scientist”。
主持人：ThoughtWorks 每半年会发布一次技术雷达（Technology Radar），具体是如何制作这份技术雷达的？为什么它总能紧跟行业潮流？
Martin： 这说来话长，技术雷达最早能追溯到十多年前。ThoughtWorks 一直就很看重让一线技术人员、实操的同事参与到公司运营里，我们的前 CTO Rebecca Parsons 就一直推动者这个里面。她上任之后，专门成立了一个技术顾问委员会，初衷是能及时掌握各个项目的一线进展。委员会成员每年会碰面两三次，给她汇报工作情况。当时她让我加入这个委员会，更多是我是公司对外形象的代表。
最开始的时候，我们就是凑一块儿聊聊各个项目的近况。后来有一次开会，她的技术助理 Daryl Smith 提了个问题：公司当时就有好几千个项目了，但技术信息在内部流转得太慢，得搞个机制来共享技术趋势。毕竟跟很多公司一样，咱们也面临好想法没法大范围传播的问题，那会儿才几千人都这样，现在公司都扩张到一万人了，这问题就更明显了。我们觉得这个想法很好，Daryl Smith 提出了雷达隐喻和现在看到的雷达象限的概念，我们开了个短会，并制作出了第一份技术雷达。
我们本来是内部用的，但 ThoughtWorks 一贯的文化是：能公开就公开，能开源就开源。这也是我喜欢 ThoughtWorks 的原因：愿意分享我们所做的一切，甚至是核心经验。发布之后行业反响很好，我们就一直坚持做到了今天。
这么些年下来，技术雷达的制作流程也有不少变化。最开始参会的大多是直接做项目、给客户提供咨询的一线人员，但公司规模后来扩大了十倍，再按老办法来就越来越难推进了。于是我们就建立了更规范的流程。
现在任何人都能提交“亮点”（也就是雷达上的技术条目），这些提名会分给专人对接，这些负责人可能是按地域、业务线或者技术领域来划分的，提名者给他们介绍这项技术的情况。之后，这些信息会汇总到现在叫 Doppler 小组的成员那里，我们开会逐条讨论这些亮点，再决定哪些能纳入雷达。这完全是个自下而上的过程，一般会前一两个月就开始收集亮点，一步步筛选，最后再集中讨论敲定。
对我来说，这个过程还挺特别的，我现在已经不怎么参与日常工作了，好多新技术都不太了解，但听他们讨论特别有意思，偶尔还能从中察觉到一些行业趋势。就比如大概十年前的微服务，就是通过这个雷达流程被关注到的，后来我们还和 James Lewis 一起深入研究，写了相关的专业内容。
它之所以能一直紧跟行业潮流，很大程度上是因为 ThoughtWorks 的很多业务本身就会涉及当下最火的技术话题，比如人工智能和大语言模型，我们也会持续关注这些技术在实际场景里的应用效果。
2
技术变革对比：AI 与汇编到高级语言的转变
主持人：在科技领域，您觉得有哪些变革能在影响程度上与 AI 相媲美？
Martin： 就我个人经历来说，AI 是影响最大的一次。如果回顾整个软件开发历程，相似的转折点当数从汇编语言向首批高级语言的转变——那时候我才刚刚入行，也是业界刚刚发布 Cobol、FORTRAN 等语言的阶段。我觉得这两者可以相提并论。
主持人：你职业早期用过 Fortran，那时周围应该还有不少人在写汇编。你从他们那里感受到的“代际转变”是什么？在思维方式、工作方法上有什么不一样？
Martin： 当时确实还有一些汇编语言的工作。汇编的指令是紧贴硬件的，而且每颗芯片的指令都不一样，寄存器、内存访问方式也不同。哪怕是做点最基本的事情，都需要写一堆复杂的底层操作。
我在大学学过一点汇编，说实话，非常有帮助——因为学过之后我再也不想碰它了（笑）。即便是功能有限的 Fortran，我至少可以写条件判断、写循环，虽然 Fortran 最早版本连 if 里都不能写代码块，只能写一句话，再配合大量 goto，但反正还是比纯汇编强得多。
更重要的是，用 Fortran 写程序时，我开始能脱离具体硬件，开始以更抽象的方式思考问题。代码能在不同机器之间迁移，我不必再死盯着芯片和寄存器。这种“从硬件到抽象”的转变，是非常重大的。
Q：你把现在的大模型变化比作从汇编到高级语言的变化，但又说更大的变化不是抽象层级提高，而是从“确定性”走向“非确定性”。能解释一下吗？
A： 是的，大模型当然提升了一点抽象层级，但远不如另一件事重要，那就是从确定性计算，转向非确定性计算。
传统软件都是确定性的：输入一样，输出一定相同。但大模型是非确定性的：同样的输入，每次可能都会给出不同答案。这种思维方式的转变，比抽象层级变化更大，也更颠覆。现在我们面对的是一个非确定性的环境，这完全改变了我们的工作方式。
主持人：有看法是，编程领域有三个层次：汇编语言需要深入了解硬件；高级编程语言（比如 C、Java、JavaScript）不需要了解硬件，只需关注逻辑；而现在有了新的层次，就是用自然语言生成代码。你似乎不认为这只是抽象层次的提升，为什么这么想？
Martin： 我承认人工智能确实带来了一些抽象层次的提升，但这并不是最核心的变化，最核心的还是确定性到非确定性的转变。
高级语言的一个关键优势是能够在语言内部创建自己的抽象，这一点非常重要。比如面向对象编程和更具表达力的函数式语言（如 Lisp），都提供了强大的抽象工具。Fortran 和 Cobol 虽然也能创建一些抽象，但现代语言的抽象能力要强大得多。创建抽象的能力至关重要，你可以在语言中构建基本模块，这也是后来领域驱动设计等理念能够实现的基础。
Lisp 中有句名言：“你应该用 Lisp 创建自己的语言，然后用这个语言解决问题。”我认为这种思维方式适用于任何编程语言：既要解决问题，也要创建一种能够描述问题的语言。如果能平衡好这两点，就能写出易于维护和扩展的代码。
人工智能在一定程度上帮助我们更轻松、更灵活地构建抽象，但问题在于，这些抽象的实现是非确定性的，这给我们带来了新的挑战，我们需要学习一套新的方法来应对这种情况。
我的同事 Unmesh Joshi 在这方面有一些很棒的想法，他一直在探索如何利用大模型共同构建抽象，然后再利用这些抽象更有效地与大模型沟通，我觉得这种思路非常有趣。
我曾在一本书中看到过一个例子：如果你用纯英文向大模型描述大量国际象棋比赛，它并不能真正学会下棋；但如果你用国际象棋记谱法来描述这些比赛，它就能学会。这很有意思，显然，记谱法不仅减少了 token 数量，还提供了一种更严谨的问题描述方式。
这或许是我们使用大模型的一个方向：找到一种严谨的表达方式，才能更好地发挥它的作用。这与领域驱动设计中的通用语言，以及我十几年前研究的领域特定语言和语言工作台有很多相似之处，我觉得这方面的发展前景非常值得期待。
主持人：这是不是软件工程领域第一次出现如此广泛应用的非确定性工具？这是一种全新的思维方式吗？
Martin： 你说得对，这只一种全新的思维方式。很多工程领域都会考虑“容差”。我太太是做结构工程的，她每次算结构承载都会问自己：“我要预留多少安全余量？”我们在 AI 时代也需要类似的思维：我们要接受系统本身的不确定性，不能把架构和逻辑压得太极致，否则某天可能就会“桥塌了”。特别是在安全领域，我几乎可以预见未来会发生一些大的“撞车事故”，因为人们低估了 AI 的非确定性。
主持人：有没有一些新的工作流程或软件工程方法，是借助语言模型实现的，或者至少是可以尝试，而这些在过去使用确定性工具时是不可能实现的？
Martin： 有两个方向非常明显。首先是快速原型开发。现在做一个原型可能只需要几天，这在过去是不可想象的，这也就是所谓的“氛围编码”。但不仅是“快速写个 Demo”，更重要的是我们可以在很短时间内“试错”，可以探索一些之前因为成本太高而不会去探索的想法，而且非开发者也能快速做工具。 只要使用得当，这是一种巨大的价值。
其次，理解遗留系统。我的同事在过去一两年做了很多这方面工作，他们把遗留系统的代码做语义分析，然后导入图数据库，再以类似 RAG 的方式，通过查询图数据库来了解数据在程序中的流向、哪些代码会影响这些数据等情况。这种方法非常有效。我们甚至把“用大模型理解遗留系统”放进了 ThoughtWorks 技术雷达的“强烈建议采用”一栏，那是最少、最重要的类别，说明我们在真实项目中得到的成果很不错。
这对 ThoughtWorks 来说也很有意义，因为我们经常需要做处理遗留系统的现代化。很多大公司都面临遗留系统的问题，员工流动也会导致知识流失，生成式 AI 至少能帮助获得一些进展，这总比毫无进展要好。
主持人：除了这两个方向，还有哪些应用正在探索？
Martin： 还有一些领域我们还在探索中。比如，如何与大模型一对一协作构建高质量的软件。我们发现，关键是要采用小步快跑的方式，将每个任务分解成很小的模块，把每个模块的输出都当作一个“不太可信但非常高产的合作者”提交的 PR，必须仔细审查每一部分。如果使用得当，确实能提高工作效率，虽然可能没有那么夸张，但确实非常显著，值得我们学习如何利用它。
我们知道大模型能帮助我们理解遗留代码，但它能安全地修改遗留代码吗？这是一个未知的问题。我最近和 James Lewis 聊过，他用 Cursor 尝试在一个不算大的程序中修改一个类的名字，结果花了一个半小时，还消耗了他每月 10% 的令牌配额。而在 IDE 中，这种重构功能已经存在了很长时间，比如 20 年前 JetBrains 的 ReSharper 插件就能实现类名和变量名的批量修改，当时人们愿意每年花 200 美元购买这个插件。苹果的 Xcode 在 Swift 刚推出时没有重构功能，还引起了开发者的不满。这说明有些问题我们早就解决了，而大模型在这方面的表现并不理想，效率很低。
另外一个悬而未决的问题是团队协作场景。大多数软件都是由团队开发的，未来也依然如此：即使人工智能能将生产力提升一个数量级，我们仍然需要 10 个人来完成以前 100 个人的工作，而且软件的需求一直在增长，没有下降的迹象，所以团队协作是不可避免的。问题是，如何在团队环境中有效利用 AI，这一点我们还在探索中。总的来说，目前我们有一些答案，也有很多问题有待解决，这是一个非常令人兴奋的时代。
3
氛围编程
主持人：那您如何理解和看待“氛围编程”这个新兴概念？
Martin： 对于“氛围编程”这个术语，我更倾向于回归其本义，即不再关注实际生成的代码。在氛围编程中，产出的代码已经不再重要，用户对于编程也很可能毫无概念，只将其当作自动生成的产物。在我看来，这种方式适合探索性尝试，即开发那种一次性、即抛性质的东西。但千万别用它制作任何需要长期维护的成果，那就太鲁莽了。
前几天我和同事就尝试制作一份随时间变化的伪图表，他对曲线性质做出描述，想让大模型帮忙生成。他把结果提交到代码库后，我看着觉得效果勉强能接受，但还需要稍微调整一下，就是把标签和相应曲线的间距缩小点。于是，我打开大模型生成的 SVG 文件，天哪，简直令人震惊。我之前用 SVG 写过的很多功能只需要十几行，但这次生成的代码却复杂得离谱，令人瞠目结舌。
这就是氛围编程的最大弊端：没人知道最终生成的代码是什么样子，也几乎无法进一步调整，最好的办法就是丢掉重来，祈祷大模型下次能生成我们想要的东西。
另外还有个关键区别，这也是我跟同事讨论得出的核心观点：在用这种方式进行快速编程时，实际上剥离了学习这个重要环节。
我们认为，绝大多数工作模式的本质都是先构思创意，而后在计算机上反复验证，这就形成了计算机输出与思维构想间的持续交互，也就是学习循环的程序化过程。这个过程无法被捷径取代，大模型草草掠过的各个环节根本没办法成为我们的学习素材。当你不学习时，就不知道如何微调、修改和扩展生成的代码，只能彻底抛弃重新开始。
主持人：现在很多公司都在采用这些工具，导致需要审查的代码越来越多，他们都在困惑如何在代码审查时保持严谨。你有没有看到一些有前景的方法，能帮助经验不足和经验丰富的工程师在使用这些工具时继续学习？
Martin： 没有太多。我一直关注 Unmesh 在这方面的探索。他的核心思路是构建一种适合跟大模型直接对话的语言，通过这种协作方式建立起更精准、更细致的表达方式，从而清晰传达我们的需求。我认为这种方法确实很有前景，甚至比其他方案更具潜力。
但要不要创建这种专属语言，实际上又引出了另一个议题，就是大模型在“理解陌生环境”方面的作用。我和 James Lewis 聊过，他最近在 Mac 上用 Godot 游戏引擎开发，使用的是他不太熟悉的 C 语言。借助大模型，他能够快速学习相关知识，尝试各种功能。我自己也有过类似的经历，比如在 R 语言中做一些已经做过很多次的操作，但就是记不住方法，就会向大模型求助。这种在陌生环境下快速获取帮助，支撑探索性工作，进而帮助我们驾驭陌生 API 和编程理念的能力真的非常重要。
主持人：这让我想到十多年前 Stack Overflow 的出现，那是行业内一次重大的生产力提升，我们可以直接复制代码片段使用。很多年轻人和经验不足的开发者（包括我自己）都会直接复制代码尝试运行，而经验丰富的工程师会告诉他们，即使代码能运行，也要先理解原理，要阅读代码。我觉得我们现在似乎又回到了类似的阶段，很多人在盲目使用大模型生成的代码。比如曾经有一个关于电子邮件验证的热门答案并不完全正确，但很多开发者都在使用它。你觉得这两者有相似之处吗？
Martin： 确实有相似之处，但规模要大得多，相当于“升级版”。现在的问题是，有了 AI 直接回答问题，未来谁还会写 Stack Overflow 的答案呢？我并不反对直接使用大模型生成的代码进行测试，但测试通过后，一定要理解它的工作原理，还要审视代码结构是否合理，不要害怕重构。 当然，最重要的是测试，任何能运行的代码都需要有测试用例，而且在使用大模型的过程中，要不断进行测试和迭代。
使用大模型时，测试的重要性
主持人：说到测试，你觉得在使用大模型时，测试有多重要？
Martin： 测试非常重要。Simon Willis 在这方面有很多深入的研究，他一直强调测试的重要性，认为测试是让这些工具发挥作用的关键。Bita 来自 ThoughtWorks，我们公司是一家非常推崇极限编程的公司，所以她也深受测试文化的影响，同样认为测试至关重要。但语言模型在测试方面表现得并不好，比如它会告诉你“所有测试都已运行，没有问题”，但你自己运行 npm test 时，却会发现有五个失败的用例。
不过我注意到，随着 Cursor 等工具的发展，这种情况已经有了一些改善。但问题的核心还是非确定性：大模型有时会“撒谎”，这很奇怪。如果它是一个初级开发者，我可能会找人力资源部门谈谈。
我最近有过一次很奇怪的经历：当时我在某个配置文件里刚刚添加了一个新的 JSON 数据块，并在注释中标记了添加日期，比如“10 月 2 日添加”、“11 月 1 日添加”等等。而在大模型帮助添加配置项时，我特意强调“请添加当前日期”，结果它直接复制了最后一次修改的日期。我说“这不是当前日期啊”，大模型却说“真抱歉，马上修正”，然后把结果改成了昨天的日期。
这件事让我意识到，即使是最简单的事情，大模型也可能出错。这可能和使用的模型、模型的优化目标（比如令牌使用量）等因素有关。所以，专业人士在处理重要工作时，绝对不能信任大模型的输出，必须遵循“不信任，要验证”的原则。
主持人：在 ThoughtWorks 跟开发者和相关人士交流时，他们日常会在哪些领域应用大模型？刚刚我们提到了测试场景，此外还有原型设计，你有没有观察到逐渐步入主流的其他操作领域？
Martin： 除了原型开发和遗留代码理解，还有几个领域也很常见。比如用它探索新的技术领域，甚至是新的业务领域。当然，对它在这些领域提供的信息，信任度要远低于十年前的维基百科。另外，Burgita 正在探索的“规格开发”也很有意思：虽然大模型有其局限性，但如果我们能清晰地定义需求，给出详细的规格说明，它就能在此基础上进行迭代和扩展。
4
规格开发与瀑布开发的对比
主持人：你对这种“规格开发”有什么看法？我感觉有点似曾相识，因为你的职业生涯始于瀑布开发时代。你觉得这次的“规格开发”和瀑布开发有什么相似之处，又有什么不同？
Martin： 要说跟瀑布模式的相似之处，就是人们同样希望制定大量规范说明，但却不太关注代码本身。我认为关键在于要避免瀑布式开发中“先构建完整规范”的弊端。相反，应尽可能采用最低规范推进项目，再以构建功能→测试验证→部署生产环境的循环持续推进。规范文档并不是重点，而仅仅是支撑紧凑迭代循环与细分切片实践的依托。这有点类似“规格驱动开发”，但核心是小步快跑、快速迭代。作为人类，必须全程参与其中，每次都要验证结果，这一点至关重要。
有趣之处在于，它又回到了“构建领域语言”的思路上：我们能否设计出更严谨的规格说明语言，这和我之前提到的 Unmesh 的研究方向一致。本质上，这是利用大模型，以更灵活的方式构建和表达抽象，但这些抽象仍然不能脱离代码库，要遵循“通用语言”的原则：我们脑海中的语言、规格说明中的语言和代码中的语言应该保持一致，名称和结构要相互对应，只是我们的思维方式比代码更灵活。
借助大模型，我们或许可以模糊这两者之间的界限，这是一个很有前景的方向。这种方式的新颖之处在于，我们从未能够如此近距离地用自然语言来表示代码或业务逻辑。
主持人：确实，之前也有人尝试过在编程中融入领域特定语言（DSL）的思想，比如用 Ruby 写业务逻辑并展示给领域专家看，专家虽然不会写，但能理解其中的内容，指出问题所在。你觉得大模型能在这方面取得更大的进展吗？
Martin： 是的，很多人都会将领域特定语言的思想融入编程中。这种思路类似于在编程语言之内构建领域特定语言，当然也可以在外部构建领域特定语言，比如在跟会计合作时，采取对方惯用的术语体系和表达方式。总之，我们的目标就是建立顺畅的沟通渠道，让非程序员至少能理解代码内容、理解问题所在并提出修改建议。有些人已经在某些场景下实现了这个目标，大模型 的出现，或许能让这种方式得到更广泛的应用。
主持人：这在企业中应该尤为重要吧？在大型企业中，软件开发者只占员工总数的 10% 到 20%，还有会计、市场营销等多个业务部门，他们都需要定制软件，也清楚自己的需求。但历史上，需要项目经理、技术专家等多个角色进行需求翻译。你觉得大模型有没有可能为双方提供一个更便捷的沟通方式，或者至少是一个值得尝试的方向？
Martin： 其实这是我最熟悉的领域。你当然深谙科技巨头和初创企业的运作模式，但其他常规业务企业则完全是另一回事，软件开发者在其中的比例相当低，同时面对着极其复杂的业务流程，更别提必然存在的遗留系统问题。此外，还有法规约束、历史包袱、因知识体系产生的特殊例外等状况。
银行领域就是典型：法规不断更迭，机构本身忙着规避未来可能发生的事故，还有 VIP 客户的特殊需求。更重要的是，这些业务单元各自遵循独立的规则框架，而且体系本身比技术形成得还早，某些银行的历史已经超过了百年。要知道，银行在软件技术方面已经比大多数企业先进了。
我还和波士顿联邦储备银行的人聊过，他们目前完全不能使用大模型，因为作为重要的政府金融机构，任何错误都可能带来严重后果，所以必须极其谨慎。这让我想到一句格言：要了解一个组织的软件开发方式，就要看它的核心业务。
我曾参观过波士顿联邦储备银行的货币处理中心，我亲眼看到汇来的纸币被运进处理中心，经过清洗、清点等工序后重新分发。他们实施的管控措施极其严密，远远超乎想象。这种严谨的思维方式也会渗透到他们的软件开发中，因为他们习惯了对每一个细节都保持高度警惕。
很多企业都是如此，比如航空公司非常重视安全，这种理念会影响他们的整个工作方式。这也是为什么不同类型的组织在技术使用上存在差异：初创公司要么刚拿到融资，要么没有融资，没有客户可失去，他们毫无顾虑，唯一的追求就是紧跟最新潮流，因此他们热衷尝试前沿技术，常在现有技术基础之上开发新的方案或者销售工具，本质上是在靠打破规则来生存。而当企业逐渐积累下一定客户之后，他们就会变得越来越谨慎；而五十年甚至七十年之后，当创始人离开、企业蜕变为大型机构时，风险承受度也自然不同。
主持人：我觉得大模型是近年来普及速度最快的技术之一。即使是联邦储备银行这样出于合理原因在技术采用上比较滞后的机构，也在评估它，这说明它已经无处不在了。你觉得大型企业和更灵活的公司在对待 AI 的态度和方法上最大的区别是什么？仅仅是谨慎程度不同，还是有其他特点？
Martin： 任何大型企业需要记住的一点是，企业并非铁板一块。企业内部的不同部门差异很大，有些部门可能非常勇于尝试新事物，而有些部门则极其保守。就像我当初在 Cheetum & Lightum 工作时，我所在的小团队就一直在积极尝试一些看似古怪的前沿事物。在任何大型组织中，你都能找到这样的小团队。所以很多时候，企业内部的差异比企业之间的差异还要大，这一点很重要。
5
关于“重构”
主持人：说到重构，大模型在这方面可谓造诣深厚。而你早在 1999 年就撰写过《重构》一书，并在二十年后发布了第二版修订。这本书非常详尽且系统地梳理了各种代码风格及其对应的重构技术，开篇第一页就列出了重构清单。我特别喜欢这个设计，真不知道出版社是怎么排版的，但出来的效果真是惊艳。您在 1999 年时为什么决定要写这本书？能不能带我们回顾一下当时的时代背景，还有首版书籍产生的影响？
Martin： 没问题，我第一次接触重构是在克莱斯勒公司，当时是跟 Kent Beck 合作。我还记得当时我们窝在旋律的酒店房间还有大堂那边，他给我演示了如何重构一段 smalltalk 代码。其实我自己就经常回头修改自己写过的代码，也一直非常重视代码的可理解性，这种好习惯覆盖了从专业写作到软件编写的整个历程。但 Kent 想得更深，他采用微小步进的重构方式持续推进，凭借精妙的组合取得了惊人的效果，最终依托连续微调实现巨大改进。这种方法彻底颠覆了我的认知，也让我为这个发现而着迷。但 Kent 当时正在全力撰写另外一本编程白皮书，无暇分心于重构方面的专著，于是我决定接手这项工作。
早期探索重构时我也会认真记录，而从中总结出的经验和记录下的步骤都成了《重构》一书中的具体操作指南。我为每个步骤都配上了示例，最终形成了第一版书稿。不过因为 smalltalk 当时已经日薄西山，所以我选择用 Java 来实现。当时的 Java 被视为未来的版本答案，90 年代末的我们坚信未来只要有 Java 就足够了。种种背景共同促成了这本书的诞生。至于影响嘛，我要再次强调——重构的概念也非 Kent 首创，而主要来自伊利诺伊大学香槟分校的 Ralph Johnson 团队。他们用 smalltalk 语言开发了首款重构浏览器，这也是如今各类自动重构工具的雏形。
而最终真正引发执法的当数 JetBrains 团队，他们将重构技术融入了 IntelliJ IDEA 的早期版本并非全力推进，终于让自动化重构成为用户可以仰仗的重要功能。当然，手动重构的能力依然重要，毕竟不是所有语言环境都有对应的重构工具可用。总之在此之后，重构成为流行术语，但也被滥用得相当离谱——有人用“重构”泛指一切程序修改，这显然不准确。我们对重构有着极其严格的定义，必须只是微小的语义变更，强调在保持行为不变的前提下通过极其细微的步骤来实现。我一直认为虽然每个具体步骤看似微不足道，但在将它们串联起来之后就能创造惊人的效果。
主持人：那你为什么会在二十年后的 2019 年发布《重构》的第二版？
Martin： 主要是想更新书中的一些内容，补充一些新的想法。另外, 初版是九十年代末针对 Java 写出来的，很多东西难免过时。虽然核心理念仍然可靠，但我觉得应该让这本书更适应现代环境。而最大的难题就是，继续使用 java 还是换一门语言？最终我决定转向 JavaScript，这样既能覆盖更广泛的读者群体，又能摆脱过度面向对象的描述方式。所以，第二版中采取了提取函数、而非提取方法的思路，这是因为重构不会改变函数的本质。新版本中还引入了很多新的示例，希望能让这本书再延续二十年的生命力。
主持人：那是一定的。这本二十多年前出版的行业著作，让人们对于重构的认知发生了怎样的变化？
Martin： 这个不太好说，因为我的主要交流对象是 ThoughtWorks 的开发者，他们对这类技术肯定比普通开发者更熟悉。当然，我在网上看到过很多让人无语的重构叙事，严重缺乏系统性和我最关注的可控性。相反，我追求的向来是高效快速的重构。这恰恰印证了“受约束的方法反而更高效”的道理，并且已经成为我们团队内部的共识。
不过值得肯定的是，越来越的人讨论重构，越来越多的工具支持重构，而且执行效率相当不错。总之，我觉得我们确实取得了一定进展，虽然没能完全达到预期，但我也没什么可抱怨的。
主持人：AI 工具的发展让快速生成海量代码成为可能。面对代码量激增的现实，你觉得重构思维在梳理底层设计意图方面有多重要？这种重要性是不是已经有所体现？
Martin： 目前还没有看到明显的迹象，但我肯定它的重要性会越来越高。毕竟随着更多质量存疑但还能运行的代码出现，重构将成为让代码既保持功能、又徐徐提升质量的理想途径。现在这些工具还不能独立完成重构，不过 Adam Tornhill 正在尝试将大模型与其他工具结合，探索更有效的重构路径，这种结合方式很有前景。重构的核心思维是把修改拆分成一系列微小且易于组合的步骤，这才是关键所在。将步骤的“小”和“可衔接性”结合起来，就能实现巨大的改进。
有趣的是，目前的重构还离不开 IDE 环境。最快捷的办法要么是使用内置工具，要么手动调整代码。而我发现在 Claude Code 等工具的命令行界面中描述操作时，耗费在解释说明上的时间反而超过相当一部分手动修改。我不确定未来是否会出现更多集成方案，让大模型能够自动完成这些操作。但任何优质软件都遵循这样一条铁律：当函数变得过于复杂、类越来越臃肿，则必须及时进行拆分和重组，否则后续维护将陷入困境。
另外，我也很期待能否出现工具控制接口，比如用大模型描述查询语句来生成 SQL。很多用户是不知道如何编写 SQL 语句的，但只要把需求输入到大模型里，它就能生成 SQL 代码，再由用户试运行来判断效果对不对。重构也是类似的原理，通过快速尝试帮助用户取得进展。记得一年之前，某巨头公司曾表示要推动大规模 API 改造与代码清理项目，并尝试使用某种大模型工具。最终情况是，大模型大概解决了 10% 的工作量，其余 90% 还是要靠其他工具。看似比例不高，但这种组合还是提供了额外杠杆，推动了工作进展。我觉得这类实践还是很有趣的，就是以大模型为起点提供驱力，再观察其上确定性工具的运作机制。这种交互模式中蕴含着独特的价值。
主持人：从重构延伸到软件架构，2002 年你曾出版《企业应用架构模式》一书，其中汇聚了 40 多种模式，包括懒加载、身份映射、模板视图等。那时候我参加技术面试时，面试官们总会询问我这些架构细节，这也让软件架构的概念风靡一时。但 2010 年代起，这一切似乎起了变化，如今我几乎听不到技术人员再讨论模式或者架构了。你会如何看待这段时期及其产生的影响？为什么对软件架构的讨论如此重要，现在为什么大家不再关注了？
Martin： 架构模式的意义在于构建一套术语体系，让大家能更高效地沟通复杂问题。我深切地感受到，这些术语确实能够促进沟通，让人们不再往系统里继续塞新规则，而是使用已有模式描述自己的备选方案并做出适用性权衡。当然，模式本身仅在特定场景下才有价值，因此必须要对相应的情境具备深刻理解。
遗憾的是，机构模式热潮似乎已经消退，或许是有人说得太多太滥，把大家搞烦了。但模式这个概念本身的价值仍然存在，最近我与 Unmesh 合作编写分布式系统设计模式的新书时，就能感受到这种用于描述核心要素的语言体系，会帮助我们更透彻地理解分布式系统的运作机制。
至于为什么它不再那么流行，我也说不好，或许未来会重新热门起来。我一直致力于传播知识、让复杂事物变得易懂，而我确实觉得识别并创建精准的名词来，是实现这一目标的有效方法。
主持人：我发现有些公司会广泛使用架构模式，有些则完全不用，差异似乎和公司规模、态度有关。初创公司更倾向于从零开始，在白板上简单画个框或圈来表示架构，不纠结于严格的规则，就像 UML 曾经有严格的箭头规范，甚至能生成代码，但初创公司根本不关注这些，他们觉得不该被现有方式束缚，而且掌握这些模式需要学习成本和共同认知，这可能也是原因之一，或许还有代际差异？
Martin： 确实是这样。任何行业都需要简化沟通的术语，总不能每次都从最基础的原理开始解释，所以人们自然会创造自己的行话。初创公司内部也会形成自己的架构沟通语言，只是这些语言没有写成书籍，只能在公司内部或有共同背景的人之间传播。
Grady Booch 对这个问题有个很有意思的观点，他认为架构模式在主流行业的热度下降，和云计算的兴起有关。那个时期，AWS、谷歌云等云服务提供商崛起，很多公司开始使用这些架构良好的云服务，比如 DynamoDB 或托管 PostgreSQL 服务，不用再自己从头构建数据存储等基础组件，所以架构的重要性似乎被削弱了，大家更多是在组合使用这些现成的构建块。但我觉得，使用这些云服务依然存在模式可循，只是我还没深入研究这方面的内容。
其实每个公司都会给系统命名，不管是古怪的名字还是逻辑化的名字，内部沟通时都会围绕这些名字展开，讨论它们的功能、规模和关联方式，这本质上也是一种行业用语。越是历史悠久的公司，这种内部用语越根深蒂固，新人可能需要好几年才能搞懂所有系统及其关联。
主持人：多年之前我曾与美国运通的高层有过一次对话，当时他负责将公司系统重构为新一代架构。我问他这活已经做了多久了，他说三年。我惊讶地回道：“那现在进展到哪一步，快完成了吧？”他说：“没有，还在规划阶段，但规划工作快要收尾了。”当时我完全无法理解——整整三年还在做规划？但随着我对他们的业务规模、涉及的资金量还有遗留系统的数量有所了解后，才明白他很大一部分时间都在说服业务相关方。这种情况在多数企业中都会发生，除非是 2010 年之后创立的年轻公司，或者是数字 / 技术优先类的企业。而即便如此，这些尚未经历转型的企业在未来十年也会遇到类似的困境。
Martin： 是的，我还记得曾跟某位加入传统银行的创业者聊天，他的任务是帮助银行推动流程现代化。他感慨道，“入职三年之后，我才真正理解问题所在。我大概知道自己该做什么，但透彻把控这个新领域非常困难，它体量庞大、历史悠久、极其复杂且缺乏逻辑。”
大型组织的系统复杂且不那么“逻辑化”，因为它们是人类逐步构建的，包含了各种历史因素，比如不同时期的供应商选择、人员变动带来的决策变化等，这些都会慢慢积累成复杂的体系，任何大公司最终都可能面临这种情况。
6
敏捷生涯
主持人：说起敏捷，你曾是参与制定《敏捷宣言》的 17 位元老之一，前面提到的 Kent Beck 也在其中。能不能回忆一下当时的情况？你们是怎么聚集在一起，宣言得到的反响如何？
Martin： 那大概是在 2001 年，起源应该是 Kent 在一年之前主持的一场会议。敏捷宣言的制定者是一群从事极限编程的人员，我们在会上讨论的核心议题是：极端编程到底只适用于 Kent 在白皮书中描述的狭窄范畴，还是可以拓展为更广泛的主流实践？Kent 最终选择了后者，于是问题转向我们该如何处理更广泛的主流实践与 Scrum 等方法的重叠部分。正是这些因素，让我们萌生了召集不同立场的人士共同商议的构想。
当时大家还为会议地点争论过，Alistair 想在犹他州，Dave Thomas 想在加勒比海的安圭拉岛，最后定在了犹他州，不记得原因了，我们还一起滑雪。参与的人都是各方邀请来的，也有很多人受邀但没来。我对会议的具体组织过程记忆不太深，Bob Martin 说我参与过芝加哥的一次午餐讨论，我大概率是去了，但没什么印象。至于会议本身，我记不清太多细节了，真后悔没有把那几天的详细经历记录下来。
我隐约记得 Bob Martin 坚持要我做一份“宣言”。我当时对这样的宣言没有抱太大希望，觉得大概率无人理会，只要讨论和创作得开心就够了。但后来它竟然产生了些许影响，着实令我们震惊。但就像 Alistair Cockburn 说的：“你绝妙的想法要么被无视，要么被误解，你别无选择”，敏捷宣言大部分时间被滥用了。
主持人：宣言中列出的 12 条原则也助长了这种现象，很多人总会挑拣自己最认可、最想强调的部分。
Martin： 是的，其实我们在宣言开往就声明“仍在探索”，强调这应该是个持续进程，宣传本身也只是对阶段性成果的记录。这些成果的来源，就是我们渴望以某种方式为 ThoughtWorks 客户编写软件，但对方却不愿意接受我们的工作方式。我们主张投入大量精力编写测试代码，推行专业化的构建流程，建立自动化构建体系等等。我们还希望能以小步迭代的方式推进工作。
但这些理念在当时简直是大逆不道，因为当时客户认为必须制定未来五年的宏大计划：其中用两年设计方案，再花一年左右来实现，最后才开始测试。这就是他们认定的正确流程，也确实是那时候的共识。但我们认为不对，我们希望只关注其中一部分需求，然后把整个流程压缩到一个月内完成、甚至最好能在一周内完成。
主持人：现在企业客户对敏捷的接受度是不是比二十多年前高多了？比如与客户协作、增量交付、摒弃冗长的工作模式，这些是不是已经很普遍了？
Martin： 我们确实取得了显著进步，但和我们的愿景相比还有很大差距，我想其他还在世的“宣言”签署者大概也会有同样的感受。我们依然可以做得更好，只是进步速度比预期的慢。
主持人：敏捷理念的核心在于通过快速迭代实现渐进式改进，周期越短越好。但如今 AI 的普及让客户已经不愿等待渐进式改进，他们希望立即看到高质量成果。在这样的背景下，你认为敏捷方法在 AI 领域仍能奏效吗？未来的迭代周期会进一步缩短，还是说我们需要探索新的模式，比如在开发初期就聚焦质量保证，把 AI 的产出优势转化成卓越软件产品？
Martin：AI 的未来尚不明朗，毕竟我们还处于早期发展阶段。所以我仍然认为，以人类可审查的小片段形式构建产品才是最佳选择。AI 当然有可能帮助我们加快这些片段的产出，或者两袖清风能在每个片段中实现更多功能，但我更倾向于增强片段的迭代频率。这就是通过加速流程循环来实现效率提升。我向来认为，最大的进步一定来源于：寻求提速途径，审视工作环节，从海口寻找阻滞点并设法消除。我曾与顶尖 AI 实验室探讨过他们的实践方式。
以 Anthropic 的 Claude Code 团队为例，他们就在两天之内并行构建并测试了 20 种不同的原型，收集反馈并敲定了最终方案。现在有了大模型，他们可以通过提示词和输出结果并行构建起 20 个真正运行在系统中的原型。AI 在本质上仍然是在加快迭代频率，其中很多原型直接被丢弃了，余下比较好的会逐步开放给小团队和大团队。总之，我们还远没有触及快速验证的极限，反馈周期和信息获取的效率仍有提高的空间。
7
如何掌握 AI
主持人：说到学习和保持领先认知，你是如何掌握 AI 发展趋势的？你和同事们会用哪些方式来保持对行业动态的关注？
Martin：我最近主要通过编辑工作来获取优质内容。我会替网站筛选高水平文章，并借此机会了解各种趋势和想法。老实讲，我已经很久没做生产开发了，近期唯一编写的生产代码就是网站运行代码。对我来说，跟一线开发的同行们合作，帮助他们将理念和经验传递给更多人才是更适合自己的工作内容。而这种将他人理念转化为文字的过程，对应一种非常独特的学习体验，也成为目前我最喜欢的学习方式。虽然偶尔也会抽空做些实验，但我始终将这种合作式学习置于优先级首位。
另外，我会关注一些可靠的信息来源，比如 Bita（和我合作过）、Simon Willis（他的产出效率很高，我很佩服），还有 Kent，我的很多职业生涯都受益于他的想法，现在也依然如此。有时候，我也会通过新出的书获取灵感，偶尔甚至会看视频。但老实讲，我真的超讨厌看视频。
主持人：你如何判断一个信息来源是否可靠？尤其是在当下这个信息繁杂、难以分辨真假的环境中。
Martin：我觉得整个行业乃至整个世界都处于认识论的危机当中，人们越来越难以理解世界的真相。这是个宏大的话题，总结一下，我的核心标准是：要以坦诚的态度面对不确定性。因此相较于“我很肯定就是这样”，我觉得“这只是我目前的理解，且不敢断定”的态度更值得欣赏。
记得早期写关于软件架构的书时，我曾疯狂寻找微软阵营的文献支持，毕竟 Java 这边的文献浩如烟海，但那会微软阵营则鲜有著作。后来我看到了瑞典技术作家 Jimmy Nilsson 写的书，他始终用“这只是我目前的理解，且不敢断定”这种审慎的态度讨论问题，给我留下了深刻印象。后来我们成了好朋友，而且我很清楚地知道，正是他这份既明确表达当下感受、也承认情况随时可能改变的立场，让他成为我眼中真正值得信赖的人。他会更热衷于探究细节上的差异，据此确定“这套方案适用于特定场景”，而不像很多大嘴巴那样宣称“永远别碰微服务”或者“必须无脑上微服务”。
这些经历再次证明，权衡取舍才是软件工程中的永恒母题。比如最常见的“还要多久”的问题，答案永远是“具体要看……”——要看是否构建原型、要看技术掌握程度等。所以参考资料中那些“在我的案例中”，就是作者希望你能知晓的具体情境。只有这样，方案的成功或者失败才能在未来转化为可参考的经验。毕竟在一家历史悠久、受到高度监管的零售企业担任软件工程师，跟在初创公司里自由发挥的开发经历根本就不是一回事。
别嫌我啰嗦，很多客户都会要求我们提供现成的解决方案，想得到一份可以粗暴照搬的“食谱”。千万别执着于这种标准答案，任何声称存在标准答案的家伙要么是蠢、要么是坏。
给初级工程师的建议
主持人：有观众线上提问说，面对当前 AI 浪潮席卷行业的情况，新手软件工程师们如果过度依赖 AI 会不会阻碍自己的成长进程？比如说有位新手工程师，希望能逐步成长为资深工程师，那到底该采取哪些策略？要不要刻意避免使用 AI 工具？
Martin：我们当然应该多用 AI 工具并探索其适用场景。但对新手工程师来讲，最难的地方在于大家缺乏判断力：大模型给我的输出结果到底可不可靠？在这个时候，最好找位优秀的资深工程师担任导师，这永远是掌握开发技能的最佳途径。
我自己就很幸运，不光在职业生涯早期遇到了 Jim Odell，还有被我视为导师的同龄人 Kent Beck，因为他的思维总是领先我一步。总之，认真寻找自己的领路人。AI 虽然方便，但它容易出错并误导我们。记得在提问时多深入探究，比如为什么给出这样的建议、依据是什么？不光是对 AI，对人也是如此。要搞清楚对方怎么得出的结论、所处的情境是什么样。
主持人：那面对当前大模型掀起的变革浪潮，你会如何看待科技行业的整体发展？
Martin： 从宏观角度讲，我持乐观态度，技术与软件领域仍有巨大的潜力可挖。我们仍处于需求量高于想象力极限的阶段。当然，这是长远视角下的结论，短期内的生活则处于一种相当怪异的阶段。
全球经济正陷入严重衰退，大规模裁员潮袭来，据说消失的岗位数量达到 25 万至 50 万之巨。这种现象在 ThoughtWorks 也有体现：我们曾保持着年均 20% 的增长执行，但从 2021 年以来我们开始遭遇瓶颈，客户明显缩减了相关支出。AI 领域虽然一枝独秀地保持发展，但也形成了极其恐怖的价值泡沫，我们不知道它还能胀多大、什么时候会爆。
不过，我可以肯定地讲，AI 确实具有价值，这跟之前的区块链和加密货币不一样。至于 AI 技术中蕴藏着多大的机遇，这个我说不好。我亲历过九十年代和 2000 年初的互联网技术周期，如今是当时的重演，只不过规模扩大了十倍。所有这些都在发生，但真正冲击我们的并不是 AI，而是零利率时代的终结。失业潮早在 AI 兴起之前就因为零利率政策的结束而爆发，我们也无法预知这样的宏观经济变局会通向何方。
巨大的不确定性让企业不愿投资，软件行业自然难以取得实质性进展。于是，我们陷入了奇特的矛盾境地：软件行业拿不到应有的投入，AI 领域却形成大到畸形的泡沫。现在的情况就是，跟 AI 沾边的企业都活得还可以，但初创公司或者非 AI 领域的企业则举步维艰。 但我还是觉得这个行业拥有巨大潜力，值得进入。虽然现在的时机不如 2005 年，但作为职业选择肯定还是优质的。
我觉得 AI 不会彻底取代软件开发，它更像是汇编语言向着高级语言的转变，在显而易见的变革下仍然保留了核心技能的价值。在我看来，优秀软件开发者最重要的能力并不是编写代码，而是明白哪些东西有写出来的价值——这本质上是一种沟通能力。谁能掌握这种沟通能力，谁才会成为最强的专家型通才。
其实这个问题并不新鲜啦，很多人都在关注：怎样才能成为杰出的软件工程师？但答案似乎从来没变过，关键是好奇心、对深度的钻研和对广度的拓展。但更重要的是，要掌握良好的沟通能力——能够高效协作的人，才有机会成为顶尖开发者。这一点在企业领域体现得尤其突出。因为我们编写的软件和服务对象所从事的，是跟我们完全不同的工作。记得在医疗系统工作时，我就常说：我对医疗概念建模和医疗流程的理解很深，但完全不知道该怎么看病。那我的理解是怎么来的？当然是跟医生交流得来的，他们也得参与整个流程。
快问快答
主持人：你最喜欢的编程语言是什么？
Martin：我目前最喜欢的 Ruby，因为我最熟悉、用得也很久。但最早让我痴迷的无疑是 smalltalk，九十年代用它编程时的那种乐趣简直无可比拟。
主持人：那能不能给大家推荐几本书？
Martin： 第一本是 Daniel Kahneman 的《思考，快与慢》。它能帮助读者建立起对数字的直觉，并揭示出我们在概率和统计思维中常犯的各种谬误。这种能力在软件开发中至关重要，毕竟我们的工作成效很大程度上取决于能否理解所见事物的统计效应。现在很多学校更关注微积分，但我真心觉得如果能更侧重统计学知识就好了。我特别喜欢玩桌游，就是因为这种游戏要求玩家随时进行概率判断。而这本书正是入门此道的绝佳途径，堪称我近年来读过的最棒书籍之一。
另一本让我着迷的书叫《权力掮客》，讲述了 Robert Moses 这位鲜为人知的纽约巨头在 1920 至 1960 这近四十年间，如何掌控纽约市大权。他从未通过选举上任，却支配着比市长和州长更庞大的资金。全书剖析了他如何一步步成长为权势滔天的幕后操盘手。更妙的是，这本书文笔极佳、引人入胜。我在读的时候经常会翻回上一个段落再次体验，舍不得就这么跨过那段弥足珍贵的文字。虽然这本书有 1200 页厚，但却是本让我读得如此沉醉、丝毫不觉冗长的巨著。
我认为要想理解当今世界的运行逻辑，这类著作有着无可替代的价值。
主持人：最后能不能给大家推荐款桌游？
Martin： 这个就有点为难了，就像有人要求推荐部电影一样。桌游类型丰富，差别巨大。但如果非要选一款门槛不高又具有深度的作品，那我会推荐《Concordia》。这是一款规则不难，过程中又蕴含丰富决策空间的抽象策略类桌游。
