与Grady Booch谈软件架构
2026-07-21 04:25:33 · chineseheadlinenews.com · 来源: Lenny Podcast公众号
与 Grady Booch 谈软件架构
与软件工程领域仍然活跃的传奇人物 Grady Booch 展开对话。我们深入讨论软件架构的演变、UML 为什么以及怎样被创造出来、他对大语言模型的看法，以及更多内容。
Gergely Orosz
开始之前先介绍一本新书：Alex Xu 的 《编程面试模式》现已出版。这本书帮助读者理解技术面试中常见的编程题。Alex 也是畅销书《系统设计面试》的作者。我们此前曾完整介绍过这本新书中的一章：设计支付系统。Alex 花了一年半时间写作，并为书中配备了超过一千幅说明图。
—
欢迎来到《务实工程师》！今天，我非常激动地邀请到了 Grady Booch——软件开发领域真正的传奇人物。
Grady 是 IBM 软件工程首席科学家，领导具身认知领域的前沿研究。
他提出了多个面向对象设计概念，是统一建模语言的共同作者，也是 Agile Alliance 和 Hillside Group 的创始成员。
Grady 写过六本书和数百篇文章，拥有 IBM、ACM 与 IEEE 会士等荣誉，也曾获得 Lovelace Medal——这一奖项授予为计算机领域发展作出杰出贡献的人。
本期我们讨论：
成为 IBM 会士意味着什么
软件开发领域怎样演变
UML 是怎样产生的、最初目标是什么，以及为什么 Grady 不同意后来版本的发展方向
软件开发历史上的关键转折点
软件架构师这一角色在过去五十年中怎样变化
为什么 Grady 拒绝担任 Microsoft 首席架构师——也就是对 Bill Gates 说“不”
Grady 对大语言模型的看法
给经验较少的软件工程师的建议
……以及更多内容
核心收获
这场精彩对话中，我最大的几个收获是：
1. 令人意外：20 世纪 70 年代和 80 年代，美国国防部与军方构建了当时世界上最复杂的一批软件系统。
在 70 年代，这些机构很可能拥有全球最大规模的代码。分布式计算等技术，也正是在这些使用场景推动下率先发展。
2. 软件架构的三个坐标轴。
Grady 认为，谈软件架构时，应从三个维度观察：
仪式程度： 构建软件时，应该遵循多少流程和正式程序？
风险： 这个系统会产生什么影响？如果出错，会发生什么？
复杂度： 系统有多复杂？其中有多少部分需要从零构建？
3. 软件与软件架构的经济学始终相互连接。
20 世纪 60 年代和 70 年代，机器时间非常昂贵，软件又几乎都必须从零编写。好的架构意味着写出高性能代码，充分利用能力有限的机器。
如今，机器时间变得非常便宜，而且我们手里有大量“积木”，从框架到云服务都有。软件架构仍然经常与成本相连：选择服务和技术时，必须把经济因素一并考虑。
4. 软件工程历史上也出现过与今天大语言模型类似的巨大变化。
Grady 提出了两个他认为甚至比今天的大语言模型更加颠覆的例子：
从单体系统转向分布式系统，始于 20 世纪 80 年代。 这是一次重大转变。习惯旧方法的工程师——例如依靠低级技术从硬件中榨出更多性能——很难适应。Grady 举例说，20 世纪 60 年代和 70 年代，创建子程序，也就是今天所谓函数，都曾因性能开销而充满争议。
图形处理器在游戏行业中的兴起。 它为更广泛的行业带来了并行计算这一新范式，而图形处理器后来也恰好成为大语言模型应用的关键基础。
5. 软件工程的前两个“黄金时代”都发生在 1990 年以前。
Grady 把 20 世纪 70 年代末和 80 年代初称为“软件工程第一个黄金时代”，当时重点是用算法解决问题，系统大多是单体结构。
他把 20 世纪 80 年代末称为“第二个黄金时代”。这一时期，系统工程成为重点，可读性开始比纯性能更受重视，面向对象编程也在此时迅速兴起。
时间目录
(00:00) 开场
(01:56) 成为 IBM 会士意味着什么
(03:27) Grady 与遗留系统的工作
(09:25) Grady 曾参与过的一些领域
(11:27) 软件开发领域的演变
(16:23) Booch 方法概览
(20:00) Booch 方法出现之前的软件开发
(22:40) 与 Paul 和 Mike 创办 Rational Machines
(25:35) Grady 与 Bjarne Stroustrup 的合作
(26:41) ROSE 与商业市场
(30:19) Grady 怎样与 Ivar Jacobson、James Rumbaugh 共同创造 UML
(36:08) UML 是什么，以及为什么把它变成编程语言是个错误
(40:25) IBM 收购，以及 Grady 为什么拒绝 Bill Gates 的工作邀请
(43:38) 为什么 UML 今天不再被行业广泛使用
(52:04) Grady 对形式化方法的看法
(53:33) 软件架构师角色怎样随时间变化
(1:01:46) 软件开发中的颠覆性变化与重大跃迁
(1:07:26) Grady 早期的 AI 工作
(1:12:47) Grady 与 Johnson Space Center 的合作
(1:16:41) Grady 对大语言模型的看法
(1:19:47) 为什么 Grady 认为有感知能力的 AI 仍然非常遥远
(1:25:18) Grady 给经验较少的软件工程师的建议
(1:27:20) Grady 接下来要做什么
(1:29:39) 快问快答
Grady Booch： 软件工程的整部历史，就是抽象层次不断上升的历史。我们现在看到的，是又一个抽象层的兴起。它给了我们极其强大的框架，可以在其上构建系统。
正如我刚才暗示的，过去那些摆在我们面前、必须亲自作出的架构决策，如今已经被封装进这些框架。
所以，今天的决策变成：
我要使用哪一种云服务？
我要使用哪一种消息系统？
我要使用哪一个平台？
这些决策不仅是软件决策，也带有大量经济决策。
因此，我认为架构师的角色实际上已经改变，因为今天处理的是系统性问题，而不只是软件本身的问题。
Gergely Orosz： Grady Booch 是软件工程领域的先驱。
五十七年前，他十二岁时就造出了自己的第一台计算机。几十年来，他一直推动软件工程和软件架构发展。
他是 UML 的共同作者，也是“面向对象分析与设计”这一术语和实践的提出者。
他是 IBM 会士、ACM 会士，也因软件架构方面的贡献获得过多个重要奖项。
他写过六本书，以及一百多篇软件工程技术论文。
在这次对话中，我们会讨论软件工程的前两个黄金时代，UML 是怎样诞生的，以及为什么 Grady 不认同它在 1.0 之后的发展方向；软件架构实践怎样演变；他对大语言模型的看法；以及一些有意思的故事，例如 Microsoft 曾邀请他担任首席架构师，而他拒绝了 Bill Gates。
如果你喜欢本节目，请在常用播客平台和 YouTube 上订阅。
可以毫不夸张地说，我今天正在和软件工程领域一位仍然活跃的传奇人物对话。
欢迎来到节目。
Grady Booch： 重点是“仍然活着”。我还没做完呢。
Gergely Orosz： 当然。
先从你的职位说起。
你是 IBM 的首席科学家，这个头衔听起来很厉害。
它具体意味着什么？你平时做什么？
Grady Booch： 曾经有一段时间，我的名片上写的是“自由基”。
但高层管理者不喜欢，所以我不得不换一个温和一点的说法。
实际上，更重要的头衔和职位是 IBM 会士。
我想，目前仍然活跃的会士大概有六十八位——不，应该是八十九位。
IBM 历史上总共大概有三百五十位会士，所以这是一个非常稀有的群体。
2003 年 IBM 收购我们公司 Rational Software 时，我被直接任命为会士。
成为会士最好的地方，是它有点像大学里的终身教职。
意思是：“我们相信你过去做过很好的事情，也希望你继续做下去，所以给你足够自由。”
因此，作为 IBM 会士，我先专注软件工程，后来又转向 AI。IBM 给了我很大自由度，让我去追求自己认为有意义的方向，尝试像 Alan Kay 所说的那样，发明未来。
2003 年加入 IBM 后，我最初留在 Rational 部门，但很快转到研究院。
IBM 的官僚体系意识到，我是一个担心未来五到十年的人，而不是只担心下一个季度。
我在研究院早期的一项工作，是寻找自动发现遗留软件系统中模式的方法。
这是神经网络时代之前的事情。
我们试图判断，能不能从代码中辨认出“四人帮”设计模式等结构。
这项工作最终没有真正发展起来，因为问题实在太难。
在架构方面，我曾与大量客户合作，而且这种工作我其实已经做了几十年。
我会像被空投进去一样。
客户说：
“魔法师先生，请来帮我解决这个架构问题。”
对我来说，令人兴奋的是，几十年来，我参与过几乎所有能想象到的领域中的项目。
大概到 2010 年前后，我又开始被 AI 领域吸引回来。
Gergely Orosz： 你说自己处理遗留系统。
对你来说，什么叫遗留系统？
Grady Booch： 你写下第一行代码的那一刻，它就已经成为遗留系统，直到你把它扔掉。
所以，所有代码在某种程度上都是遗留系统。
Facebook 是遗留系统。
Google 是遗留系统。
天哪，甚至 OpenAI 都已经有遗留问题。
现实是，正如我经常说的，旧代码永远不会自然死亡，你必须杀死它。
只要你构建了有用的东西，它就会继续活下去。
除非代码完全一次性使用，否则手里总会存在某个代码体，代表某些不可轻易改变的东西。
它有成本，也有某种程度的技术债。
技术债可能很小，但总会存在。
很多大型金融机构从 20 世纪 60 年代起就一直维护同一个代码库。
我曾经参与过美国 Internal Revenue Service 的项目，因为它们从 60 年代起就一直试图现代化系统。
我们回到当时。
60 年代发生了什么？
人口增长，Social Security 体系扩大，越来越多机构制造大量纸质文件。
到 60 年代中后期，银行和政府意识到，工作量已经大到无法纯靠人工处理。
银行过去为什么下午三点就关门？
因为员工需要剩余时间人工核对账户。
IRS 也类似。
所以，60 年代出现了一波人类流程自动化。
其中大部分程序都用 IBM 360 汇编语言编写。
回到今天，IRS 系统里仍然有 IBM 360 汇编代码，运行在一层又一层模拟器之上。
这会造成非常困难的问题，因为一部分代码把业务规则直接埋在汇编语言里。
那你怎样修改？
你面对的是一个真正的人类问题：
怎样把 COBOL 和汇编语言中的旧代码变形，使它能在现代技术上运行？
模拟技术能做的事情有限。
与此同时，政府每年都会制定新业务规则。
系统怎样持续跟上？
这就是现实存在的遗留问题。
Facebook 也有，只是它的代码没那么老。
Google 也有。
OpenAI 很快也会有。
WorkOS 赞助商口播
Gergely Orosz： 本期节目由 WorkOS 赞助。
如果你正在构建软件服务应用，总有一天，客户会开始要求企业功能，例如单点登录、SCIM 用户配置和细粒度授权。
WorkOS 正是为此而生，它能让你快速、轻松地把企业功能加入应用。
它的应用程序接口容易理解，你可以迅速发布，然后继续开发其他功能。
WorkOS 还提供名为 AuthKit 的免费用户管理方案，每月活跃用户不超过一百万都可免费使用。
它可以直接替代 Auth0，默认包含域名验证、基于规则的访问控制、机器人防护和多因素认证等实用功能。
AuthKit 基于 Radix 组件构建，因此设计上不需要妥协。
你可以无限定制，也可以使用为快速集成准备的模块化模板。
今天，数百家快速增长的初创公司都在使用 WorkOS，其中包括 Cursor、Vercel 和 Perplexity 等你可能听过的公司。
访问 workos.com 了解更多。
再次强调，网址是 workos.com。
Sevalla 赞助商口播
本期节目也由 Sevalla 赞助。
它是真正的 Heroku 替代方案，可以免费部署应用、管理数据库和托管静态网站。
Sevalla 是为团队设计的平台。
通过预览和流水线功能，开发者可以围绕任何技术栈协作，并确保从预发布到生产环境的工作负载安全。
Sevalla 拥有企业通常要求的主要安全认证。
它的应用托管提供自动 Git 集成、Docker 镜像部署、休眠节省成本、垂直和水平自动扩缩、TCP 代理支持，以及可选的数据库私有网络连接。
免费静态网站托管非常适合落地页、文档网站等场景。
它还包括预览部署，便于快速迭代和无缝协作。
Sevalla 界面易用、不限制席位、没有隐藏套路，并采用透明的按使用量计费模式，同时提供企业级云端分布式拒绝服务攻击防护，适合任何规模的工作负载。
现在就注册并部署。
访问 sevalla.com。
Sevalla 中有两个字母 L。
你刚才说，自己会被空投去帮助不同公司。
能不能举例说说，过去几十年里，你帮助过哪些类型的公司，处理架构、遗留代码和技术债？
Grady Booch： 几乎所有能想象到的领域。
我当然和金融机构合作过很多。
也在国防领域做过大量工作。
事实上，如果把时间拉得很远，复杂系统最早并不是从商业领域起步，而是在国防世界里发展起来的。
我经常说，现代计算的全部历史，都是在一台由悲伤织成的织机上编织出来的。
现代计算诞生于 World War II 和 Cold War。
其中一个关键系统叫 SAGE，也就是半自动地面环境。
它在 20 世纪 50 年代出现，一直运行到 80 年代。
这个系统是为了应对 Soviet Union 的威胁而构建的。
当时还没有卫星和普遍雷达，美国担心 Soviet 轰炸机会穿越 Arctic 进入本土。
SAGE 的建设，促成了我们后来所说的“软件危机”。
也正是它推动了那个十年后期的 NATO 会议。
世界各地一群人聚在一起问：
“我们怎样解决软件问题？”
那正是我所谓软件工程第一个黄金时代的高峰。
所以，国防系统是一类。
我也做过大量实时系统。
从心脏起搏器、地铁系统，到 CT 扫描设备等。
几乎任何领域，你说得出名字，我大概都参与过。
James Webb Space Telescope 目前的设计也使用 UML。
仔细想想，这真的非常酷。
Gergely Orosz： 把时间快速拉到今天。
你已经与很多公司合作，参与过大量项目，也广泛影响了软件架构领域。
你会怎样描述这个领域几十年来的演变？
你显然参与了一些关键技术的发明，并看着它们成为常识。
这段过程是什么样？
Grady Booch： 我刚才提到一个阶段，叫软件工程第一个黄金时代。
那是 Fortran、COBOL、APL、Lisp 等语言的时代。
Lisp 某种程度上是一种多范式语言。
当时，我们分解系统的主导方式是算法。
因此，结构化分析与设计技术迅速发展，而且在当时非常合理。
Yourdon、DeMarco、Constantine 等人都出现在那个时期。
因为软件系统面临的核心问题是：
它们通常不是分布式的，而是大型单体。
我们怎样构建越来越大、又能长期维持且在经济上有意义的系统？
第一个黄金时代后来开始变化，因为分布式系统兴起。
这次兴起仍然不是最先发生在商业世界，而是国防领域。
ARPANET 由政府和 DARPA 资助。
我之前提到过，1979 年我拿到第一个电子邮件地址。
那时世界上的电子邮件地址并不多。
讲一个小笔事。
当时我在 Air Force Academy 教书。
我们有一份油印文档，上面列着全世界所有人的电子邮件地址。
我想当时一共只有几千人。
所以，大家几乎知道网络上的每一个人是谁。
回头看，非常有意思。
最早的分布式系统就出现在那个领域。
在 Vandenberg，我参与过一个叫“遥测集成处理系统”的项目。
它由三十二台小型计算机组成一个封闭网络。
小型计算机当时是一种新事物。
于是，一个新问题出现了：
怎样把一个大系统拆成多个分布式部分？
这个问题还没真正进入商业领域，但行业已经开始意识到，纯算法分解有局限。
各种压力汇聚起来，迫使人们思考下一代软件：
分布式软件、实时软件、多语言软件、运行在多种计算机上的软件。
我们还必须处理分布式系统的所有常见问题：
部分组件会在不同时间失败；
通信会出问题；
等等。
于是，人们意识到，必须以完全不同的方式思考软件。
研究领域也出现了 Simula 和 Smalltalk 等语言，它们用截然不同的视角看世界。
这里大概是 70 年代末，我二十多岁。
Air Force Academy 的一位老师问我：
“Grady，你能不能帮助 Department of Defense 理解，怎样使用一种叫 Ada 的新编程语言，并把它应用到现代软件工程？”
为什么政府会担心这件事？
因为到那时，软件已经成为国防部乃至整个联邦政府的严重问题。
当时使用中的编程语言多达数千种。
原因是，Fortran 和 COBOL 对某些事情有用，但并不能解决所有问题。
于是，政府决定构建“一种统治所有语言的语言”，也就是 Ada。
Ada 远远领先于时代。
它受到 Simula、Smalltalk 等语言影响，也使用了 Liskov、Guttag 等人提出的抽象数据类型思想，以及 David Parnas 的信息隐藏思想。
这些概念当时都很新，但今天已经成为我们呼吸的空气。
然而，当时整个行业并不理解怎样以方法论把这些东西真正用起来。
于是，Booch 方法诞生了。
1979 年到 1981 年左右，我在美国各地来回奔波，帮助联邦政府和承包商，用新方式应用这种新语言。
这构成软件工程第二个黄金时代的开端。
核心问题不再只是算法复杂度，而变成系统工程问题，尤其是当时非常新的分布式系统问题。
这就是 Booch 方法的本质：
把我帮助组织为新领域、新语言设计系统时学到的经验，整理成一种方法。
Gergely Orosz： 你能解释一下 Booch 方法是什么吗？
我知道它与面向对象编程有关，但由发明者本人来解释它为什么重要，会非常有价值。
Grady Booch： 那我们先回到 Plato。
这可真是回得够远。
我当时当然不在场，不过读过他的一些作品。
Plato 有一篇很精彩的对话，讨论人应该怎样看世界：
应该把世界看成原子，还是看成过程？
软件工程第一个黄金时代更关注过程，也就是算法。
但还有一种平行视角：
通过原子看世界，也就是通过类和对象看世界。
所以，我受到抽象数据类型理论、Plato，以及当时很多哲学思想影响。
这些思想汇聚起来，帮助我们以根本不同的方式看世界。
Booch 方法就是试图把这种视角系统化。
怎样不以算法分解系统，而是以类和对象分解系统？
Liskov、Parnas、Dijkstra、Hoare 等人都影响了我。
今天的学生可能不熟悉这些名字，但他们代表了第一代和第二代软件工程的理论基础。
Booch 方法基本是在说：“看，这是一种新的世界观。”
不要只看算法，而要把数据与处理数据的过程结合进同一个东西，也就是类。
我们有些地方做对了，也有些地方做错了。
做对的是，类作为抽象非常有意义。
做错的是，我们过度强调继承。
继承背后的想法是：
通过建立一般化关系复用代码。
但后来证明，这种方式并不总是合理，因为现实中经常需要构建彼此差异很大的抽象。
不过没关系。
快进到今天，人们会问：
“这到底有什么区别？”
答案是，它已经成为你呼吸的空气，所以根本不会再刻意思考。
你使用 Redis，在上面构建系统。
但仔细看，Redis 提供的是一组抽象，而这些抽象本质上就是基于类的。
这套思维已经被烘焙进系统设计。
简而言之，Booch 方法就是：
不要只通过算法看世界，而要通过对象和类看世界。
还有一点。
Booch 方法曾经暗示了一个后来在 UML 中没有完全成形的思想：
从多个视角观察系统。
之后我们还会回到这一点。
Gergely Orosz： 为了确认我理解正确。
我和大多数听众开始职业生涯时，Booch 方法早就已经出现。
对我们来说，类、变量、继承都是日常概念。
但当时完全不是这样，对吗？
能不能解释一下当时的技术环境是什么样，以及 Booch 方法为什么显得如此新颖？
Grady Booch： 我们再往前回到 20 世纪 50 年代，讲一个平行故事。
算法编程语言发展早期，子程序这个想法本身都很有争议。
为什么？
因为函数调用会增加至少两三条指令，而那在当时是昂贵的计算开销。
所以，把代码分解成子程序甚至被看作一种架构异常。
有人反对它，因为它效率低。
今天我们会想：“这太荒谬了。为了管理复杂度，函数显然必不可少。”
早期面向对象也经历了类似情况。
实际上，人们当时已经在算法语言里做某种面向对象设计。
例如 COBOL 里有所谓公共数据区。
人们会维护一组共享数据，并通过实践约定：
“这些数据由这些算法使用，这些算法也只处理这些数据。”
回到我在 Vandenberg Air Force Base 参与的三十二台计算机项目。
每天，每台计算机旁边都会打印出当天的公共数据池。
抽象就直接摆在你面前，因为它不断变化。
所以，人们已经试图做对象式分解，但语言并不支持。
现实有这种需要，但在语言能力出现之前，人们无法高效地把思想真正组织起来。
因此，Booch 方法确实是对软件密集型系统建设压力的一种回应：
用类思考；
把它应用到现代语言；
围绕它建立方法论。
今天我们觉得理所当然，是因为语言让这一切很容易。
Gergely Orosz： 很有意思。
当时它如此革命性，而今天如此普通。
也会让人想到，我们今天发明的革命性事物，二十年后可能也会被人说：“哦，那不是常识吗？”
Grady Booch： 完全正确。
Gergely Orosz： 你最著名的贡献之一是 UML。
能不能讲讲它怎样产生？
当时目标是什么？
谁参与了？
它要解决什么问题？
Grady Booch： 1982 年，我在 Air Force Academy 的两位同学 Paul Levy 和 Mike Devlin 来找我。
Paul 曾是我的室友，主修经济学。
Mike 主修计算机科学，我和他一起上过几门课。
我第一次见 Mike，是在一门徒手格斗课上。
这不是普通大学会有的课程，但我毕竟接受的是战士训练。
如果没记错，在格斗比赛里他把我打得很惨。
当时我在 Vandenberg Air Force Base，Mike 和 Paul 在 Bay Area 的卫星控制设施工作。
他们有一个当时规模最大的 Ada 项目之一，于是我去帮助那个项目。
他们两人也都在 Stanford 学习。
我发誓，Stanford 的水里一定有什么东西。
他们后来接触到了 Art Rock 和 Hambrecht & Quist——当时最重要的两家风险投资方。
Art Rock 和 Hambrecht & Quist 是 Apple 的关键早期投资者，也参与资助了后来成为 Rational Software 的公司。
1982 年，Mike 和 Paul 找到我说：
“我们一起创办公司吧。”
于是我们真的做了。
公司叫 Rational Machines Incorporated。
目标是为即将到来的 Ada 编程语言构建软件开发环境。
我们觉得这里有机会赚很多钱。
一开始，我们甚至自己造硬件。
当时个人计算机开始变得可负担，Sun 也逐渐出现。
但现有机器还不够强，无法完成我们想做的工作。
所以 Mike 设计了一套系统，我帮助围绕它建立方法论。
它叫 R1000。
当时，它成为全球最主流的 Ada 开发系统。
时间再向前跳十年，来到 90 年代中期。
我有点厌倦原来的工作，开始探索其他方向。
我发现 Booch 方法在商业市场中越来越有吸引力。
那时我经常演讲。
有一次，一位听众提出一个非常深刻的问题。
演讲结束后，我们见了面。
他叫 Bjarne Stroustrup。
原来 Bjarne 当时正在研究一种叫“带类的 C”的东西，也就是 C++ 的前身。
我们很快投缘，发现彼此正在做非常相似的事情。
后来，我们一起在美国各地做了一系列讲座，我也因此非常了解他。
那正是他写第一本 C++ 书的时候。
如果你看第一版，会发现里面多次引用我的思想。
而我写《面向对象设计》时，也大量引用他的工作。
Booch 方法与 C++ 某种意义上是一起长大的。
我觉得这很有意思。
有一次，我和 Mike、Paul 在 Denver 的 United Airlines Red Carpet Club 开了一个很重要的会。
他们说：“Grady，我们想把公司转向嵌入式系统。”
我回答：“很好，但我认为这是个愚蠢想法，因为你们完全错过了商业市场。你们自己玩吧，我要去做别的事情。”
这让他们停下来重新思考。
我想，他们意识到，商业领域也许真的有机会。
那时，我们只在国防市场继续增长已经越来越困难，这也是他们为什么想转向嵌入式。
后来，他们决定：“那就把 Booch 方法真正做成产品。”
于是，Rational Object-Oriented Software Engineering，也就是 ROSE，诞生了。
这是我们的第一款工具。
第一个原型是我用 Smalltalk 写的，是一个非常棒的系统。
真希望当时保留了源代码。
我记得，在第一次演示前几分钟，我还在修改它。
这就是我们从国防领域突破进商业领域的起点。
产品非常成功。
因为那个时期，越来越多人意识到，面向对象是观察世界的好方法，而 C++ 真正支持这种方法。
这带来两件事。
第一，商业上成功。
第二，我们开始收购其他公司，逐步覆盖软件工程完整生命周期。
Gergely Orosz： 能不能简单解释一下 Rational Software 的商业产品具体做什么？
Grady Booch： Rational Software 的 ROSE，是一个运行在 IBM PC 上的个人生产力工具。
后来也移植到其他设备。
第一版运行在 Windows 下。
它允许用户绘制图表。
那时还不是 UML 图，而是 Booch 图。
用户可以借此推理和思考设计。
我们做过一点代码生成，但它主要是一款设计工具，帮助组织思考系统设计。
人们用它记录、说明和构建系统。
产品赚了很多钱，于是我们开始收购公司。
我们买了一家需求管理公司。
Ed Yourdon 找到我说：“去看看那家公司。”
我们就去看了。
还收购了 Cambridge 的一家小鲍司 Pure Atria。
它由 Reed Hastings 领导。
Gergely Orosz： 你说的是 Netflix 创始人，对吧？
Grady Booch： 对。
我们收购了他的公司。
Gergely Orosz： 世界真小。
Grady Booch： Reed 发现自己是一个很糟糕的首席执行官。
于是拿着收购所得，在我们这里待了几年，思考下一步做什么。
那笔钱后来成为创办 Netflix 的重要种子资本。
从这个角度看，世界确实很小。
到 90 年代末的高峰期，IBM Rational 几乎主导了软件工程工具市场，因为我们覆盖开发生命周期的每一部分。
增量式、迭代式开发也在那时真正形成。
早在今天所谓持续集成和持续部署之前，我们已经在 Rational 机器和工具里做类似事情。
我们率先提出这些思想，因为已经构建了增量编译工具等能力。
到了 90 年代，我们拥有完整工具集。
但市场明显在增长，所以我们不是唯一参与者。
当时出现了数百甚至数千家公司，尝试做面向对象相关产品。
这构成软件工程第二个黄金时代。
Pete Coad、Constantine、Yourdon、Martin，以及 Ivar Jacobson、Jim Rumbaugh 等人都在活跃。
那是一个非常有生命力的时期。
组织都在问：“我们有这些强大的工具，有 ARPANET，有个人计算机，究竟应该怎样构建软件？”
软件领域面临的核心问题变成：
怎样利用手中极其强大的工具，以最好的方式设计系统？
Rational 处在一个很有意思的位置。
我们说：“我们正在主导市场，那就继续向前。”
于是，我们聘请 Jim Rumbaugh。
我和 Jim 的任务，是把他的 OMT，也就是对象建模技术，与 Booch 方法结合。
当时，这两套方法大概是最主流的两种。
后来我们又收购 Ivar Jacobson 的公司。
因为我和 Jim 都在使用“用例”概念。
今天，用例也已经成为空气一样的常识，但在 90 年代还是新概念。
它是 Ivar 在 Ericsson 工作时提出的，主要用于蜂窝通信基站软件建设。
于是，Rational 把我们三个人聚到一起，任务是统一方法。
你很难找到三个差异更大的人。
我很惊讶，最后居然没有一个人进医院、一个人进监狱。
我们真的太不一样了。
细节我就不讲了。
但我非常为最终成果感到骄傲。
UML 就这样诞生。
我们决定：
这不应该只属于我们，而应该成为全世界都能使用的东西。
所以，我们把它提交给 Object Management Group。
UML 1.0 就此出现。
我大体上主导了这项工作，同时与 Jim、Ivar 合作。
主要标准文档由我撰写。
当然，整个成果是三个人共同完成的，我完全认可他们的贡献。
但 UML 1.0 完成后，我在情绪上已经筋疲力尽，想去做新的事情，所以离开了这个项目。
这里还要提另外两位重要人物。
第一位是 Philippe Kruchten。
我们意识到，工作规模太大，不可能同时由三个人完成方法论和符号体系。
于是，我、Jim、Ivar 主要负责符号体系，也就是 UML。
Philippe 则主要与 Ivar 的一些同事负责方法论。
由此诞生 Rational Unified Process。
注意“统一”这个词。
Philippe 带来了一个极其重要的思想，Booch 方法里已经有过一些暗示：
从多个视角观察世界。
Philippe 提出了 4+1 视图模型。
它来自他构建 Canada 空中交通控制系统的经历。
那同样是一个非常复杂的分布式系统。
这些思想后来体现在 IEEE、IEC、ISO 42010 架构描述标准中。
标准基本上说：
观察一个架构时，必须从多个视角出发：
用例视图；
逻辑视图；
进程视图；
实现视图；
部署视图。
这是一项非常重要、非常深刻的贡献。
另一位重要人物是 Walker Royce。
Walker 很有意思。
他的父亲 Winston Royce，我有幸在他任职 Lockheed 时合作过。
Winston Royce 写过那篇著名的瀑布生命周期论文。
而他的儿子，却在 Booch 方法里研究螺旋模型。
Winston 经常被误解。
他并不是在支持瀑布方法。
恰恰相反，他说那是个愚蠢想法。
你也可以看 Parnas 的论文《一种理性的设计过程：为什么以及怎样伪装它》。
顺便说一句，Rational Software 这个名字就受到这篇文章影响。
文章的意思是：
从外部看，过程也许像瀑布；
但内部并不是，内部更接近今天所谓敏捷。
所以，到了 90 年代末、2000 年初，UML 1.0 已经完成。
那就是当时 Grady 的生活。
Chronosphere 赞助商口播
Gergely Orosz： 开发者们，我们都经历过这种时刻：
凌晨三点，手机突然响起，把你从睡梦中惊醒——又来了一个告警。
你急忙排查，但微服务环境极其复杂，几乎不可能快速定位问题。
这就是 Chronosphere 为什么要帮助你重新获得控制权。
它推出了一项新的分布式追踪功能，叫作差异诊断，可以把故障排查中的猜测去掉。
只需点击一次，DDX 就会自动分析与某项服务相关的所有跨度和维度，指出最可能的问题原因。
不要再让故障排查把你拖到凌晨。
直接使用 DDX，更快解决问题。
Chronosphere 被评为 2024 年 Gartner 可观测性平台魔力象限领导者。
访问 chronosphere.io/pragmatic 了解更多。
再次强调，网址是 chronosphere.io/pragmatic。
回到 UML。
我理解得对吗？
UML 的目标，是描述一个系统。
我在大学学 UML 时，会画不同类的方框，再用不同箭头表示它们之间的关系。
看到完整图后，就能大体理解正在构建的软件结构。
Grady Booch： 对。
如果看 UML 1.0 标准第一行，我记得大意是：“UML 是一种视觉语言，用于推理、可视化、说明和记录软件密集型系统中的制品。”
其中没有任何一句说它是一种编程语言。
事实上，我非常强烈地反对把它变成编程语言。
UML 的本意，是帮助人思考和推理系统，以面向对象方式观察世界，尤其从多个视角观察。
顺便说一句，今天的 DevOps，本质上只是部署视图和实现视图的合并。
当然，当时我们不这样称呼。
UML 1.0 就是为了帮助人思考：
我怎样理解这些东西？
怎样围绕它们推理？
我一直认为，人们画出 UML 图后，大部分应该直接扔掉。
很遗憾，很多人没有这样做。
从 UML 1.0 走向 2.0 时，出现了一派个人和公司，说：
“不，我们要让 UML 极其精确，要把它变成一种编程语言。”
我认为，这是一个深刻错误。
我从来没打算把 UML 变成编程语言。
结果是，UML 变得更复杂、更庞大。
重点也从帮助人推理，转向代码生成和逆向工程。
逆向工程我可以理解，那很有意义。
但把它变成编程语言，是错误。
我认为，UML 的衰落就是从这里开始，因为人们开始用错误方式使用它。
在高峰期，UML 在市场中的渗透率大概达到 20% 到 30%。
仔细想想，这已经非常了不起。
我为它被应用到很多系统感到骄傲。
但我最骄傲的是，它帮助人们以不同方式思考软件建设。
Gergely Orosz： 你说高峰期使用率达到 20% 到 30%。
这是否意味着，当时大约 20% 到 30% 的商业软件开发者都在使用 UML？
那大概是什么时间？
Grady Booch： 大约是 2000 年前后，可能上下浮动几年。
别忘了，当时 Microsoft 也深度参与。
它们和我们合作，把 ROSE 产品集成进 Visual Studio。
我们有一支团队在 Seattle 做这件事。
这在当时成为 Microsoft 的重要卖点，因为它能帮助客户构建更复杂的软件。
所以，时间大概就在 2000 年左右。
不过，那段时期还发生了什么？
ARPANET 已经演变成互联网。
90 年代末，越来越多公司开始迁移到互联网。
这当然很好，但也带来挑战：
怎样为分布式网络构建系统？
怎样从中赚钱？
系统应该长什么样？
Microsoft 对我们感兴趣，是因为我们帮助客户从个人计算机时代转向分布式系统。
但另一方面，市场炒作也非常夸张。
人们会说：
“互联网会改善你的性生活。”
“互联网会解决所有事情。”
这个领域出现了严重过度投资。
世纪之交后，市场开始反弹。
人们建立了很多东西，后来发现它们未必在经济上可持续。
到 2003 年，IBM 和 Microsoft 仍然大量使用我们的工具，因为对客户很重要。
两家公司都竞购 Rational。
最后，我想 IBM 以 27 亿美元左右的价格获胜。
于是，我们被 IBM 收购。
当时 Rational 有三千五百人，分布在十四个国家，年收入接近十亿美元。
对那个年代的公司来说，这是很惊人的规模。
但公司也确实到了应该被更大组织吸收的时候。
在停下来之前，我再讲一个故事。
IBM 收购我们后，立即把我任命为会士。
这以前几乎没有发生过。
通常要在 IBM 工作多年才可能成为会士。
几个月后，我接到一个电话：
“Grady，我是 Bill，过来见我。”
于是我飞去了——
Gergely Orosz： Bill Gates，对吧？
Grady Booch： 对，Bill Gates。
Gergely Orosz： 哇。
Grady Booch： 以前我和 Bill 也合作过一些事情。
当时他仍然是 Microsoft 首席执行官。
我到了他的办公室，说：
“你好，Bill。”
原计划会议只有三十分钟，结果我们聊了两个小时，他的工作人员非常恼火。
他坐下来对我说：
“Grady，现在还没有公开，但我准备逐渐离开 Microsoft 当前职位，因为我想做其他事情。”
“我现在有两个角色，一个是首席执行官，一个是 Microsoft 首席架构师。”
“我想把企业业务首席架构师这个职位给你。”
我回答：
“Bill，这很有意思。”
我请他给我一点时间。
随后，我去见了他的主要直属高管。
最重要的是，Ballmer 从来没有见我。
这是一个危险信号。
我也逐渐意识到，当时的 Microsoft 是一家特别恶劣、特别内耗的公司。
Office 团队和 Windows 团队彼此厌恶，简直无法忍受对方。
最终，我通过招聘团队回复 Bill：
“我非常荣幸，但你们的公司功能严重失调，而我不是那个能够修复它的人。”
“所以，谢谢，但我拒绝。”
我想，当时还说了一句类似：
“如果我接受，这件事最后只会让我们两个人都流泪，所以还是继续各走各路吧。”
于是，我留在 IBM。
这是正确决定。
去 Microsoft 对我来说会是个糟糕选择。
Gergely Orosz： 有一幅很有名的 Microsoft 组织结构漫画，由软件工程漫画作者 Manu Cornet 画的。
画面里，Microsoft 的不同部门互相举枪瞄准。
Grady Booch： 对，就是那样。
它们需要一个愿意打破局面的人。
而我是一个爱人，不是战士。
我不适合去拆散那些东西。
Gergely Orosz： 太精彩了。
我在大学里学过 UML。
直到今天，它仍然存在于很多大学课程中。
但有意思的是，在行业里，我几乎没见过真正使用它。
至少在我工作过的初创公司、成长型公司、大公司，以及接触过的其他企业中，情况都是如此。
只要有人提出 UML，往往会遭到抵触，理由是它太正式。
当然，我们仍然做架构。
我们会画方框和箭头，也会做各种图。
UML 曾经被行业 20% 到 30% 的人使用。
在你看来，后来发生了什么？
Grady Booch： 这会把我们带到当代架构。
我有整整一书架关于软件架构的书，既有旧书，也有新书。
今天很多人谈的软件架构，我认为总体合理，也有很多好内容。
但它们讨论的很多系统，架构决策其实已经被别人替你做好了。
我要构建一个需要消息传递的系统。
那就去找 RabbitMQ、Redis 或其他现成工具。
架构决定已经被封装在里面。
所以，当代架构师大量工作，就是把大型框架和组件编织在一起。
这是一项高尚、也很有价值的工作。
像 Meta 等公司，其架构经过几十年逐步成长。
今天在它上面构建的东西，往往只是围绕既有应用程序接口演化，并不总需要过去那种更深层架构思考。
我常用一个三轴坐标来说明。
第一个轴是仪式程度。
如果我是一家初创公司，烧的是别人的钱，失败后大不了再找另一个风险投资人。
我甚至可以写一次性软件。
那当然不会使用太多正式程序。
直接做就行。
招几个聪明人，把东西做出来。
很好。
但如果要构建下一代洲际弹道导弹系统，花费可能是数千亿美元，就一定会有更多仪式和问责程序。
这是第一条轴。
第二条轴是风险。
如果系统失败，只意味着某个人找不到自己的 Grindr 配对对象，可能没什么大不了。
但如果系统失败会死人，那就是严重问题。
这时，你会采用更有纪律的架构方法。
第三条轴是复杂度。
如果构建的系统，别人已经反复做过很多次，那可能什么正式方法都不需要。
甚至只靠提示就能做出一个应用。
这种东西根本不需要 UML。
但如果我要构建一个从没出现过的系统，例如不是单个大语言模型，而是一组协作的大语言模型，还要把它们与非神经系统编织起来，那么就需要认真考虑架构。
这正是 UML 可以发挥作用的地方。
大量普通软件开发都位于一个甜蜜点，不需要 UML，也不需要类似形式化工具。
但如果在这三个维度上继续向外走，当然仍有大量人在使用 UML。
我提过 James Webb Space Telescope。
我现在仍与一些金融机构合作。
当风险、复杂度和仪式程度足够高时，系统确实需要更多形式化表达。
Gergely Orosz： 我理解的是：
从 90 年代和 2000 年代到今天，软件架构发生了变化。
当时系统和架构本身都很新，软件架构也更加前沿。
而今天，如果看风险投资支持的初创公司和大型科技公司：
第一，它们往往没有那么高风险。失败了也不是什么世界末日。
第二，我们能使用大量已经存在、已经被别人设计好的软件。
例如直接用 Redis 做缓存，不需要重新思考整个架构。
第三，很多初创公司不需要仪式，不需要审计和正式流程，可以按自己方式快速推进。
这些是不是形式化方法不再受初创公司和成长型公司欢迎的主要原因？
Grady Booch： 对。
这其实触及软件开发经济学的根本。
回到软件第一个黄金时代。
机器比人昂贵得多。
所以，在真正使用机器之前，必须先认真思考，因为机器时间非常贵。
算法分解、结构化分析与设计方法都很有意义，因为必须尽可能优化。
到了今天，计算资源就像鱼周围的水，几乎所有人都能获得。
我身后桌上放着四台 Nvidia 单板计算机，组成自己的个人云。
它们拥有的计算能力，比 20 世纪 70 年代全世界所有计算机加起来还强。
而总成本不过几千美元。
经济条件发生了巨大变化。
你不必再提前思考那么多，因为很多东西可以直接抛弃。
AI 也在改变这一点。
它让我构建一些东西时，甚至不必思考设计，乃至不必思考软件。
只要用提示让系统生成，用一次，然后扔掉。
从这个意义上说，问题仍然回到经济学。
但永远会有一类软件是新的、独特的、在开辟未知领域。
这类系统仍然需要真正的架构思考。
Gergely Orosz： 最近我读到 Amazon 怎样为 AWS S3 使用形式化方法。
它们发表了文章，详细说明怎样捕捉十亿分之一、万亿分之一才发生的极端边缘情况。
在 Amazon 的规模下，这类事件反而会定期出现。
我觉得很有意思，一些老方法又重新出现。
Grady Booch： 先暂时把形式化方法单独放一边，因为那是另一个我有经验、有看法的话题。
先谈 Amazon。
去看它们的网站，会发现它们自己有一整套架构语言。
Microsoft Azure 也一样。
在 Amazon 里描述架构时，会画那些块状图：“我要构建这种系统，这是对应符号。”
而且网站会给出示例。
所以，即使 Amazon 和 Microsoft 没有明确承认，它们仍然认为架构很重要。
只是很多系统已经被做过足够多次。
它们可以直接告诉你：
“想构建这种系统，就使用这些服务。”
“这里还有现成示例。”
这代表行业成熟。
我们从所有人都要自己实现的算法，发展到设计模式，再发展到 Amazon 和 Microsoft 已经编码并产品化的架构模式。
现在回到形式化方法。
形式化方法一直存在。
但以我的经验，它始终只是软件密集型系统中的一个小众部分，因为它能覆盖的领域有限。
例如 Microsoft 曾开始对硬件驱动程序使用形式化方法，验证正确性。
Gergely Orosz： 你指硬件驱动程序？
Grady Booch： 对，硬件驱动。
这是重要进步。
我也参与过一些项目：
系统失败可能导致人员死亡，所以要对某些部分做形式化分析。
不过，这些形式化方法通常无法完整处理现实世界，因为它们很难处理空间和时间，更多处理功能逻辑。
因此，我一直认为形式化方法有用，但只适合系统中的某些部分，从未成为整个架构的唯一驱动力。
Gergely Orosz： 说到软件架构，如今“软件架构师”这个角色已经不那么流行，至少在初创公司和大型科技公司是这样。
架构工作仍然存在，但承担者更多叫资深工程师、首席工程师或者杰出工程师。
他们仍然做架构，只是重点不同。
你见证了软件架构师角色的产生。
你能不能讲讲，它怎样形成，又怎样演变？
Grady Booch： 有两件事影响了我对这个领域的理解。
当时我并不真正自称架构师，但会帮助别人设计系统。
第一位重要影响者是我的好友 Mary Shaw，Carnegie Mellon 的教授。
如果没记错，她在 Obama 任期内获得过 National Medal of Science。
她写过一本影响深远的《软件架构》，首次系统阐述了架构模式。
Mary 是一个非常令人愉快的人。
通过她的工作，我开始理解架构能够被怎样形式化。
第二个影响来自其他领域的架构，尤其是土木工程。
国防领域还有舰船架构、飞机架构等。
“架构”这个词在软件工程之外一直非常受尊重。
先忽略职位名称，回到第一性原理：
架构究竟是什么？
你可能听我说过：
所有架构都是设计，但并非所有设计都是架构。
架构代表一组重要设计决策，这些决策塑造系统的形式和功能。
而“重要”的衡量标准，是改变它的成本。
软件架构和架构师这两个词带有很多糟糕的情绪包袱。
所以，可以简单理解为：
架构就是做决策。
哪些决策塑造系统？
作为架构师，你在做决策。
项目经理也在做决策。
细微区别在于：
今天的架构决策不再只是软件形状，还包括整个系统怎样嵌入物理世界，怎样与其他系统、人与组织互动。
这就是现代架构。
它本质上是一个决策过程。
Gergely Orosz： 你有没有看到这个角色发生变化？
过去是否有一个黄金时代，公司大量雇用软件架构师，授权他们设计系统？
今天我看到这种角色少了一些。
这是普遍趋势，还是我所处环境的泡沫？
你接触的公司非常广泛。
Grady Booch： 我再给你一句简洁的话：
软件工程的整部历史，就是抽象层次不断上升的历史。
今天，我们又进入了更高抽象层。
它给了我们极其强大的框架，可以直接用来构建系统。
过去必须由架构师正面处理的很多决定，如今已经被封装进去。
所以，问题变成：
使用哪个云服务？
使用哪个消息系统？
选择哪个平台？
这些决策不仅涉及软件，也涉及大量经济因素。
因此，架构师角色事实上已经变化。
今天处理的是系统性问题，而不只是软件内部问题。
Gergely Orosz： 你听说过“解决方案架构师”这个职位吗？
它可能是十年前左右出现的，主要做云架构。
这很有意思，是一个专门围绕云诞生的角色。
正如你说的，他们做的是经济决策：
使用 AWS 还是 GCP？
如果用 AWS，是用 EC2，还是其他服务？
Grady Booch： 这正说明它是系统性问题。
如果你是一家初创公司，通常会招聘做过类似事情的人。
他们知道坑在哪里，也知道不同方案成本。
招聘这种人，可以显著加速公司，因为他们已经做过这些决定。
根据你现在要构建的系统形状，他们大体知道下一步该做什么。
这些都是系统性决策，因为包含经济后果和长期后果。
Gergely Orosz： 软件架构还经常和迁移联系在一起。
我注意到，大多数大公司都被长期迁移折磨。
迁移往往由架构变化引发，例如从单体转微服务，或者更换技术，例如从 Node 迁移到 Go，或者升级框架大版本，例如从 Angular 一个版本迁到另一个版本。
软件架构和迁移怎样连接？
为什么软件迁移如此困难，而且似乎永远不会消失？
Grady Booch： 我相信，迁移会一直折磨我们，直到宇宙热寂。
Gergely Orosz： 它们确实太难了。
Grady Booch： 你总是在构建经济上可行的软件。
但技术会不断从脚下变化，迫使你考虑迁移。
想想 60、70、80 年代的单体系统，后来小型计算机和分布式系统在经济上可行。
今天你不会拿一台 iPhone，却把所有处理仍放在大型主机上。
这些变化迫使你重新平衡处理发生的位置。
如果设备突然能够执行边缘推理，架构也会随之改变。
所以，硬件变化和社会变化都会影响系统结构，推动迁移。
为什么迁移难？
再给你一句话：
代码是真相，但代码不是全部真相。
代码之外，还有大量东西：
设计决策；
决策理由；
为什么选这个而不选那个；
为什么这样命名；
一些曾经被人长期理解、后来又被误解的微妙背景。
所以，代码虽然是真相，但迁移过程中会丢失大量信息。
仅从代码重新构建设计决策非常困难。
写下最初代码的人，可能早已套现离开，甚至已经去世。
你不知道当初为什么那样做。
所以只能在黑暗中摸索。
Gergely Orosz： 你说人可能已经去世。
我们通常不会想到这一点。
但如果系统已经四五十年，那确实是现实。
Grady Booch： Linus 最终退休后，Linux 内核会怎样？
它会怎样漂移？
他一直为系统的概念完整性提供坚定而必要的控制。
这就是首席决策者的作用。
这个人提供概念完整性。
当他离开后，系统自然会漂移。
这是不可避免的，也是熵。
如果没有持续施加保持完整性的力量，所有软件都会表现出某种程度的熵。
Gergely Orosz： 今天与技术和架构最相关的话题之一是 AI。
它已经出现，具有革命性，也充满颠覆性。
你在行业里工作接近五十年。
回头看，大语言模型和 AI 与过去的创新、事件相比怎样？
对从业二三十年的人来说，大语言模型像是软件行业最大的变化。
你是否见过影响和变化速度相近的事情？
Grady Booch： 这是个好问题。
我想到的第一件事，是人们意识到可以构建分布式系统，而不是把所有处理放在一台机器上。
这彻底震动了系统构建方式。
小型计算机网络出现后，后来又扩展到微型计算机和手机等边缘设备。
小型计算机兴起带来的转变，是一次地震级变化。
我认为，当时人们很久以后才真正理解全部影响，因为它迫使我们重新思考怎样组织系统。
那个时期也充满不确定性。
我们不知道怎样构建分布式系统。
跨机器通信该怎样做？
使用远程过程调用？
使用别的方法？
共享内存？
大家进行了长时间探索，最后才逐渐发现常见有效模式。
Gergely Orosz： 那大概是什么年代？
80 年代，还是 90 年代？
Grady Booch： 70 年代末。
不过，再往前回。
60 年代末、70 年代初，大型主机统治世界。
但人们已经发现，大型机器经常没有被充分利用。
于是，最早的分时系统出现。
同期还出现了 Whirlwind 等系统，来自 Lincoln Laboratory。
它们开始让计算机真正接触物理世界。
实时计算由此出现。
两股力量汇聚：
一边是大型机器以及分时操作系统；
另一边是与现实世界交互的计算机。
它们后来在小型计算机兴起时汇合。
Digital Equipment Corporation 等公司推动小型计算机发展。
而小型化之所以在经济上可行，很大程度上来自 Department of Defense 对半导体的投资。
终于，一台计算机可以放在桌上，供一两个人全职使用。
再把 Whirlwind 的具身思想和分布式系统结合，就能开始把多台机器编织起来。
这就是 70 年代中后期发生的事情。
还有一个变化是客户机—服务器系统。
IBM 当时有绿色屏幕哑终端连接大型主机。
新机器出现后，部分处理终于可以移动到边缘，而不是全部留在主机上。
正是这些力量，迫使我们重新思考系统。
Gergely Orosz： 所以，当时程序员习惯在大型计算机上工作，分布式计算突然出现，彻底改变了动态？
Grady Booch： 完全正确。
Gergely Orosz： 年轻人开始拥抱分布式计算，而原有程序员仍坚持大型主机时代的高效方法，大概是这种情形吗？
Grady Booch： 是的。
后来又出现 TCP/IP、HTML 等技术。
突然之间，我们有了共同词汇，也有了真正把系统连接起来的机制。
所以，我不会说大语言模型像分布式系统兴起那样普遍重要，但两者确实存在相似之处。
第二个可类比的变化，是图形处理器兴起。
它来自游戏行业。
游戏公司面对的问题是：
怎样让画面更接近照片真实感？
答案大量涉及矩阵乘法。
Nvidia 因此进入市场，图形处理器逐渐主导这个领域。
后来 Andrew Ng 意识到：
游戏使用的图形处理器，所执行的数学，与深度学习需要的数学是同一种。
砰的一下，海量数据、强大硬件和反向传播等算法汇聚成一场完美风暴。
所以，今天确实令人兴奋。
大语言模型毫无疑问很有意思。
但我们必须谨慎。
接下来可以详细谈。
Gergely Orosz： 那就谈谈。
我很想听你对大语言模型的坦率看法，包括适用场景、创新价值和权衡。
Grady Booch： 先交代背景，免得有人认为我只是对不了解的东西随口评论。
我很早就对后来逐渐形成的 AI 领域感兴趣。
十二岁、十四岁时，这种兴趣就已经出现，而且一直伴随我。
后来 IBM 在 Watson 时期把我重新拉回 AI，我才把它变成全职方向。
Watson 开发负责人 David Ferrucci 曾打电话说：
“Grady，我要做一场讲座，但临时无法出席。你能替我讲吗？”
我说：
“David，当然可以，但前提是主题由我决定。”
我选择的主题是：
Watson Jeopardy 的架构究竟是什么？
结果发现，当时根本没有人完整记录过。
作为架构领域专家，我与 David 团队合作了几个月，记录 Watson Jeopardy 的实际建成架构。
它并不是神经网络系统。
它是一种流水线架构，通过流水线把多种统计系统组合起来。
当时 AI 主要是预测统计方法、知识工程，而不是今天的神经网络。
我记录的架构引起 IBM 管理层注意。
这是我第一次完整记录 AI 系统架构。
Gergely Orosz： 对不熟悉的人解释一下。
Watson Jeopardy 是 IBM 的计算机，参加电视问答节目 Jeopardy，并且赢了，对吗？
Grady Booch： 对，它击败了所有人类选手。
Gergely Orosz： 当时这件事登上所有主流媒体，被宣传为 AI 在非常人类化的任务上超越人类的例子。
Grady Booch： 没错。
它延续了 IBM 在这个方向上的轨迹。
更早之前，我们有 Deep Blue，击败了当时最强国际象棋棋手。
Gergely Orosz： Garry Kasparov。
Grady Booch： 对，Kasparov。
Deep Blue 主要靠暴力计算。
后来 Watson Jeopardy 出现，在当时的自然语言处理任务中击败人类。
IBM 在自然语言处理领域已经做过很多统计系统。
我们后来把部分业务卖给 Nuance，但当时确实是这个领域的主导者。
Watson Jeopardy 是高峰。
IBM 对我说：
“这东西很酷，我们准备把它商业化。你能不能研究 IBM 应该怎样做？”
我领导了一项持续大约一年的认知系统研究。
那大约是 2010 年代前期。
我研究 Watson，也观察市场。
我非常明确地告诉 IBM 管理层：
“这确实很酷，但要小心，因为有些事情它做不到。”
我明确警告不要过度炒作。
有一次，我向当时的首席执行官 Ginni Rometty 汇报。
她问了我一个问题。
一位副总裁插话，开始越过我回答。
我礼貌地说：“谢谢，但我认为你错了。”
然后继续解释。
如果我不是 IBM 会士，大概会当场被开除。
但作为会士，我有资格说这种话。
当然，后来 Watson 团队没有邀请我加入，我对此很满意。
我继续在旁边做自己的事情。
后来事实证明，Watson 确实有做不到的事情。
某种意义上，这是一次“我早就说过”。
我在 IBM 内部的地下状态持续了几年。
接下来会回到你的问题，但这些背景说明，我为什么有资格发表看法。
Austin 有一支团队，Hilton Hotels 找到他们，希望为酒店构建机器人礼宾员。
我们选择法国南部公司 Aldebaran 的机器人。
它们有三英尺高的 Pepper，也有更小的 NAO。
团队构建了一个机器人系统。
它基于 Watson 技术，可以问答，挺有意思。
但还缺一些东西。
团队来找我：
“Grady，你能帮忙吗？”
于是我帮助改善架构。
我们确实把它安装进几家 Hilton 酒店。
而且，那支团队离 Johnson Space Center 很近。
于是，我们开始和 NASA 合作。
我很高兴，因为能回到自己的太空根源。
NASA 当时有一个叫 Robonaut 2 的系统，是一个类人机器人，曾经在 International Space Station 上运行。
工程质量非常漂亮。
NASA 正在为 Mars 任务探索人与机器人互动。
我们坐下来问：
什么样的设计问题足够困难，能够推动我们解决真正有挑战的问题？
答案是 Mars 任务。
那里有两个重要使用场景。
第一，由于光速延迟，不能依赖地面 Mission Control，必须把控制能力带在身边。
这就是 HAL 问题。
我们需要构建一个 HAL，只是去掉“杀死所有人类”的使用场景。
不知道为什么，NASA 不想要那个功能，但那是它们的选择。
第二，NASA 当时希望先把机器人送到 Mars 表面，帮助宇航员搭建科学实验和栖息地。
我记得有一天下午坐下来，突然想明白：
我知道该怎样设计它。
那大概是 2014 年。
我构建了一套神经—符号架构，叫 SELPH。
它结合了三套思想：
Marvin Minsky 的心智社会；
Rodney Brooks 的包容架构；
Douglas Hofstadter 的怪圈。
三者共同形成 SELPH。
我们把它真正构建出来，并与 NASA 一起实验了一段时间。
它让 Robonaut 能执行这样的任务：“机器人，这是一个科学流程，去完成它。”
或者：“去清理过滤器。”
清理过滤器是空间站上常见的维护活动。
我们构建软件，让人类可以与机器人互动，也让系统回答问题。
这又把我们带到 New Zealand 的 Soul Machines。
那家公司来自 James Cameron 电影技术的延伸。
他们会在演员脸上安装摄像头，捕捉肌肉运动。
后来，他们构建了人类肌肉系统的神经模型。
硬件很好，但缺乏软件。
我们帮助了它们。
还与 Australia 的石油天然气公司 Woodside 合作。
它面对的问题与 NASA 类似。
海上钻井平台非常危险，它们希望构建协作机器人。
所以，我们有了 SELPH。
它是神经—符号系统，既有神经部分，也有符号部分，并建立在刚才三个架构决策上。
非常有意思。
高峰时，我有三十五个人参与项目，分布在 IBM 全球六个实验室。
这也让我可以住在 Hawaii 的 Maui 远程工作，我今天仍住在那里。
但后来，IBM 意识到 Watson 一直在烧钱，于是把所有人都裁掉。
因为我是会士，没有被裁。
所以，我继续留在这个领域。
这就是我接触第一批新型 AI 架构的过程。
过去六年左右，我一直与一群神经科学家合作，尝试理解有机大脑架构。
我不只研究软件，而是研究皮层柱、下丘脑中的回路等。
我用软件架构师视角观察有机系统。
现在终于回到你的问题：
我怎样看大语言模型？
答案是：
它们真的非常酷。
但从架构本质上说，它们是不可靠的叙述者。
这是我比较礼貌的说法。
如果不礼貌，我会说：
它们让我们构建了全球规模的胡说生成器。
因为它们显然是随机鹦鹉。
它们不会推理，也不理解。
但它们确实可以产生高度连贯的结果，因为它们让我们在一个潜在空间中导航，而这个潜在空间通过互联网语料训练变得极其复杂。
这正是完美风暴：
数据、算法和硬件结合，让我们能够构建连贯输出。
但必须谨慎。
Gary Marcus 和我一直强烈、一贯地批评 Sam Altman 等人所谓“我们正站在通用人工智能门槛上”的说法。
这会贬低人类通用智能的优雅，也贬低人类智能本身的美。
坦率说，单靠扩大规模无法到达那里。
我们已经看到规模化开始触及限制。
Elon Musk 也一直相信只要继续扩大规模就可以达到通用人工智能。
我在互联网上多次批评过他的观点。
他已经承诺全自动驾驶很多年了。
之所以迟迟无法实现，是因为这些模型本身使用了错误架构。
如果为了运行系统必须建一座核电站，大概说明架构有问题。
大语言模型确实有有效使用场景。
但必须小心，因为它们也确实危险。
Yann LeCun 在 Twitter 上把我拉黑了。
因为 Meta 最初发布 Galactica 时，我就公开提醒：
“Yann，这项工作很棒，但你意识到它的后果了吗？”
他直接不理会。
我继续批评。
最后他受够了，把我拉黑。
这又是一次“我早说过”。
今天，我们同时看到了大语言模型的乐趣和危险。
Gergely Orosz： 再确认一下。
你是在说，大语言模型本身无法带我们到通用人工智能。
但如果把它和其他工具结合，例如其他神经网络或神经—符号系统，我们也许能更接近真正的智能系统？
回到 Mars 机器人例子。
如果希望机器人能清理过滤器、理解并执行指令，我们还需要什么？
Grady Booch： 我再增加一个场景。
看看 Japan 等人口老龄化、人口萎缩的社会。
United States 也正在走向类似状态。
这些社会有巨大的老人照护需求。
机器人场景会越来越重要，而且不一定非要完全类人。
所以，确实存在明确、现实的需求。
也确实有很多优秀使用场景。
我一直认为，这是一个系统工程问题。
这也是为什么在架构层面，我长期专注神经—符号系统。
稍微哲学一点。
我相当确信你有感知能力。
当然，我无法百分之百保证。
也许你只是一个极其出色的大语言模型。
Gergely Orosz： 这是一个合理猜测。
Grady Booch： 为什么我相信你有感知能力？
因为我拥有一套关于你的心智理论。
通过多模态互动，我形成了一个判断：
你是有自身能动性、感受、行为和需求的主体。
你不是机器人。
人类心智经过漫长演化，形成了这种能力。
它本质上确实是神经系统，但人工神经元与有机神经元相比，只能说是“耳语的回声”，甚至还不如影子。
它只是极小的一部分。
而且，大语言模型架构相对简单，基本是层叠结构。
它忽略了人类心智精致得多的复杂度。
人类大脑皮层中有数千万个皮层柱。
在人类身上，它们大概有七层。
爬行动物也有，只是规模更小。
它们似乎是我们构建世界预测模型的地方。
但除此之外，情绪与其他决策过程还发生在与丘脑等结构相互缠绕的架构中。
激素系统似乎还提供另一种神经网络消息传递方式。
因此，大语言模型很有意思，但与现实心智相比，也只是影子的耳语。
Gary Marcus 和我都认为，只靠规模已经接近收益递减。
OpenAI 和 Elon Musk 等人相信规模化还能持续很久。
我们则认为：
不，你正在触碰极限，必须换一种架构思路。
这会把我们带回具身认知。
一开始，你提到我的工作与具身认知有关。
具身是什么意思？
就是构建存在于世界之中、属于世界、能够回应世界并在世界中行动的系统。
大语言模型基本是单模态的。
它们主要通过文本工作，也可能加入静态图像、视频等，但总体感官极其稀疏。
人类心智和智能之所以成长，是因为它们具身于世界。
我认为存在多种不同智能。
而人类智能是通过具身发展出来的。
要实现类似能力，需要相当复杂的架构。
这就是为什么我花六年研究人类大脑架构。
我知道自己了解得还不够。
我想看看，这些知识能否影响我设计软件架构的方式。
Gergely Orosz： 作为收尾，你以前发过一条很有意思的帖子。
我引用一下：“我们需要一种标准方式，可视化大语言模型以及更广义人工神经网络的架构和活动——某种面向 AI 的 UML。”
这是大约一年前说的。
你看到这方面有什么进展吗？
为什么大语言模型架构如此重要？
Grady Booch： 我既有想法，也确实看到了一些进展。
在 IBM 内部，我一直为大语言模型工作提供一点“架构成年人监督”。
我在尝试找到最适合可视化这些系统的方法。
事实证明，它仍然很像 UML：
现在每个方框本身就是一个系统，方框之间通过消息传递连接。
我还在探索最佳表达方式。
就在本周，AlphaFold 公布了源代码和权重。
我准备立刻研究它，把它当作一个案例：
能否使用某种 UML 表达，描述 AlphaFold 3 的架构？
敬请关注。
这里还有很多工作值得做。
Gergely Orosz： 对刚进入软件行业的工程师，你有什么建议？
很多应届毕业生正面对寒冷的就业市场。
AI 工具似乎也正在改变软件工程方式。
你经历过很多轮创新周期。
怎样做，能为成功的软件工程职业生涯打好基础？
Grady Booch： Copilot 和 ChatGPT 刚出现时，我收到大量消息：
“天哪，我是不是选错职业了？”
“以后根本不需要开发者了。”
无论编程语言变成什么，我们始终需要能够作出有根据决策的人。
软件工程仍然是抽象层次不断上升的历史。
改变的只是工具。
我最初学的是汇编语言。
今天的人会使用抽象层次高得多的语言编程。
我给年轻人的建议有几条。
第一，不要担心，不要害怕。
永远都会有非常有意思的工作等着你。
事实上，我甚至认为情况恰恰相反。
今天是一个令人兴奋的时代。
机会如此之多，工具如此之酷，计算资源如此丰富。
很多时候，唯一限制你的只是想象力。
第二，尽可能多学习。
第三，不要把自己困在单一领域。
当然，你需要在某个空间成为专家。
但计算世界非常辽阔。
找到一个目前还没有很多人进入的地方，在那里建立自己的名字。
这样的地方还有很多。
第四，去享受乐趣。
天哪，我们拥有的玩具实在太棒了，而且价格便宜。
单个人可以用极低成本做很多事情，甚至改变世界。
最后，我也想说：
我还没做完。
我仍然玩得非常开心。
除了研究人类大脑和大语言模型，我还有两个已经持续很久的项目。
第一个是写一本软件架构书。
我很庆幸自己还没有完成，因为今天知道的远比过去多。
这会是一本不同的架构书。
它不是告诉你：
“架构应该这样做。”
而是与许多公司合作，记录系统实际建成后的架构。
我希望把 AlphaFold 放进去。
Photoshop 也在里面。
Photoshop 的架构是什么？
气候监测系统是什么架构？
Wikipedia 是什么架构？
我想记录人们今天每天使用、却可能从没认真思考过的系统架构。
核心想法是：
世界上存在很多不同架构风格。
也许你只学过一种。
我要把更广阔世界展示给你。
Gergely Orosz： 确认一下，这本书叫《软件架构指南》，对吗？
Grady Booch： 《软件架构手册》。
Gergely Orosz： 手册。
Grady Booch： 对，《软件架构手册》。
我那位长期受苦的编辑，已经耐心等了我整整十年。
我希望死前能完成。
第二个项目是：
我曾在 Computer History Museum 的董事会任职大约十年。
我们聘请了一位新首席执行官，他以前在 PBS 工作。
有一次我对他说：
“John，你为什么不制作一部像 Carl Sagan《Cosmos》那样的纪录片？”
他停了一下说：
“Grady，那为什么你不来做我们的 Carl？”
我回答：
“我不是 Sagan，但这个想法很有意思。”
于是，我开始制作一部关于计算与人类经验的纪录片，也在写一本相关书。
它观察计算历史，也思考作为人类意味着什么。
什么是计算思维？
计算怎样改变个人、社会和国家？
怎样改变科学、艺术、宗教？
最终，它会提出一个问题：
在计算存在的时代，成为人类意味着什么？
这是我当前正在做的更大项目。
我也希望死前完成。
Gergely Orosz： 最后做几个快问快答。
我问问题，你直接回答，不需要想太久。
你使用的第一种编程语言是什么？
Grady Booch： Fortran。
Gergely Orosz： 最近一次提交的是哪个项目？用了什么语言？
Grady Booch： 我自己的项目 SELPH，用 Python。
Gergely Orosz： 做完软件工程相关工作后，你怎样恢复精力？
Grady Booch： 我住在 Maui。
早上醒来就够了。
Gergely Orosz： 令人羡慕的地点，也是令人羡慕的答案。
如果有人想进一步理解软件架构，你会推荐哪两本书？
Grady Booch： Mary Shaw 的《软件架构》。
先读那本。
其他书相比之下都有点黯淡。
所以，从它开始。
Gergely Orosz： Grady，非常感谢你来到节目。
这次对话既有趣，又令人着迷。
Grady Booch： 是我的荣幸。
谢谢邀请。
Gergely Orosz： 感谢 Grady 带来这场精彩对话。
你可以在下方节目说明中找到联系 Grady 的方式。
如果你喜欢本播客，请在常用播客平台和 YouTube 上订阅。
更多对话收获，也请查看节目说明。