UML的兴衰：程序员的“噩梦”与历史的教训

你见过这些图吗？你画过这些图吗？如果你的回答是没有，那么恭喜你，躲过了软件开发历史上最“坑”程序员的一段时间。这种叫做UML（Unified Modeling Language: 一种图形化的软件建模语言）的图，曾经是每个程序员的必修课。然而，绘制UML图比编写文档和单元测试（Unit Test: 对软件中的最小可测试单元进行检查和验证）还要折磨人。

UML本质上是一种图形化的建模语言，拥有一套完整的语法规则。但与由字母和符号组成的编程语言相比，UML因其图案化的特性，熟练掌握的难度完全不在一个量级上。我已记不清UML具体是何时退出历史舞台的了，只记得渐渐地，人们发现所绘制的图纸只是机械地按要求完成，实际上却鲜有人问津。随后，大家便默契地不再使用这种工具。作为一门曾叱咤江湖的手艺，UML的兴衰成败能给我们留下不少教训。从这个角度看，UML确实值得我们为其立一块墓志铭。

UML的诞生：寻找“大统一理论”

许多人可能不知道，UML并非独立出现。进入20世纪90年代，随着计算机的普及，软件开发开始在各行各业中流行起来。与此同时，如何科学地管理软件开发项目，也成为企业亟需解决的问题。当时，业界热衷于寻找那个能解决所有问题的“大统一理论”。在此期间，涌现出许多软件开发框架，例如大家熟悉的瀑布模型（Waterfall Model: 一种线性的、顺序的软件开发流程）和敏捷开发（Agile Development: 一种迭代的、增量的软件开发方法）等。它们的主要区别在于如何看待软件开发生命周期（SDLC: Software Development Life Cycle，描述软件从构思到退役的全过程）。

瀑布模型认为软件开发应是一个大型的、线性的周期，而敏捷开发则主张通过不断重复的小周期进行迭代。1994年，一家名为Rational Software的小公司，专注于设计各种软件流程框架，他们也创建了自己的理论框架，即统一过程（RUP: Rational Unified Process，一种迭代式、以用例为驱动的软件开发过程）。宏观来看，RUP与瀑布模型有些相似，都是在一个大的周期内相对线性地推进项目，涵盖从策划、设计、开发到最终验收、交付的各个阶段。然而，RUP在细节上更为丰富，例如需求、设计、测试等步骤贯穿整个项目周期，几乎同步进行并互相配合，而非像瀑布模型那样，完成一个阶段再进入下一个。

鉴于所有步骤都会同步推进，各参与方之间的沟通变得至关重要。在RUP框架中，前期准备占据了极大的比重。因此，如何促使负责策划和设计的管理团队，以及负责开发和测试的技术团队进行深入交流，将对项目效率产生决定性影响。RUP为此提供的解决方案，便是创造了一套完全以图案表达的语言。这些用图案描述的宏观或微观技术内容，对应了RUP中各个阶段、各参与方所需了解的关键信息。对于非技术人员而言，相比于代码和充斥专业术语的文档，图案的学习门槛显然更低。这套图形语言正是统一建模语言（UML）。尽管UML是为了配合RUP流程而设计的，但它具有非常广泛的通用性，自然也比RUP更早地获得了普及。

1996年，UML从RUP中独立出来，并成立了标准委员会。包括惠普（HP）、IBM和微软（Microsoft）在内的计算机巨头都第一时间加入了该委员会。IBM更是在2003年大手笔耗资21亿美元，直接收购了Rational Software。借助IBM的巨大影响力，RUP和UML获得了更大范围的传播。一时间，UML似乎就是人们一直在寻找的那个能够完美解决软件开发流程的“大统一理论”。然而，时间证明了它并非如此。

UML的没落：实用性下降与时代脱节

在2005年发布UML 2.0并重构了底层代码之后，UML标准便基本没有再进行大的更新。到了2015年底，IBM也悄然终止了RUP专家和UML专家证书的发放。如果连曾将证书发放发展成一门大生意的“亲爹”IBM都不再愿意提供支持，那么我认为，没有什么比这更能宣告UML的“死刑”了。

许多人认为UML或RUP的消亡，是由于敏捷开发体系后来横扫全球、一统江湖所致。但我认为这种理论并不完全正确，因为如果真是这样，我下一期关于“敏捷之死”的视频就不好展开了。UML的没落，更多是源于自身的问题。UML的尴尬之处在于它未能跟上软件项目发展的步伐。

时代发展的第一个趋势是复杂度的不断增加。以UML中的状态机图（State Machine Diagram: 描述对象在不同事件作用下状态变化的图形）为例，状态机本身并不复杂，但随着软件的发展，状态切换的逻辑会变得越来越复杂。对于代码和技术文档这类文本形式，新增的复杂度可以很容易地添加进去，或者通过超链接指向其他相关内容。然而，状态机图在设计上没有预留足够的空间来容纳这些信息，因此只能使用一些缩写来传达额外信息。这些缩写有时是某个枚举值，有时是某个函数的名称，但无论如何，它们都是不完整的。由于图片空间有限，许多UML图都面临着类似的难以扩展、难以包含更多信息的问题。而UML标准的升级也只围绕着底层数据结构的语法问题，很少考虑这些实际应用中的挑战。这导致UML图的实用性一步步下降，最终沦为“鸡肋”。

时代发展的另一个趋势是各种工具和流程的整合。GitHub（一个基于Git的代码托管平台，用于版本控制和协作开发）就是一个典型的例子。如今的GitHub上只有一个搜索框，其搜索结果同时包含了代码、提交记录（Commit: 代码版本控制中的一次保存）、问题（Issue: 用于跟踪任务、缺陷或增强功能的记录）、拉取请求（PR: Pull Request，用于合并代码分支的协作机制）、开发中的讨论以及技术文档等。这体现了GitHub对开发者习惯的深刻理解。在日常工作中，我们经常需要翻阅旧代码、文档、工单等参考资料，以补充前因后果，辅助决策。键盘快捷键“Ctrl+F”的使用频率，可以说仅次于“Ctrl+C”和“Ctrl+V”。然而，在项目中包含的所有可参考资料中，以图片形式存在的UML图就显得格格不入了。因为图中的内容基本无法被搜索，也就很难融入到日常工作中。例如，当我要确认某个对象（Object: 编程中类的实例）是否已被定义时，我无法在类图（Class Diagram: 描述系统中类、接口以及它们之间关系的UML图）中搜索，而只能在代码中查找。

这里我用了“基本”这个词，是因为UML本质上也是文本，从其名称就能猜到，它的底层其实是可扩展标记语言（XML: Extensible Markup Language，一种用于编码文档的标记语言）。只不过，它们犯了与【让编程再次伟大#25】视频中吐槽的图数据库（Graph DB）同样的错误：缺乏统一的语法，存在太多各种各样的格式，导致渲染逻辑、查询方法和接口都五花八门。像Visual Paradigm或Enterprise Architect之类的UML软件确实可以提供搜索功能，但我相信没有多少人会愿意专门打开一个UML专属软件，仅仅是为了再搜索一遍关键词。

一些意识到这个问题的人开始尝试对UML进行更彻底的文本化改造。例如，Mermaid框架在GitHub上获得了原生支持，它没有使用XML定义，而是参照了Markdown（一种轻量级标记语言，用于创建格式化文本）的语法。这样一来，UML图便完美融入了以Markdown为核心的GitHub文本体系，可以与其他资源一同被检索。然而，我使用GitHub这么多年，却鲜少见到有仓库中出现UML图。这也很容易理解，毕竟在这个时代，愿意将代码上传到GitHub的人，与愿意花费时间绘制UML图的人，两者之间至少隔了一个辈分。

UML的真正价值：总结与沟通的工具

当然，UML并非一无是处，我认为它只是出现在了错误的地方。古语有云：“一图胜千言”（a picture is worth a thousand words）。在软件工程的“圣经”**《人月神话》**中，弗雷德·布鲁克斯（Fred Brooks: 著名计算机科学家，著有《人月神话》）也有一句名言：“给我看你的流程图，隐藏你的数据表，我将继续困惑不解。给我看你的数据表，我通常就不需要你的流程图了，一切都会显而易见。”这句话的大意是，如果只看流程图，我会一头雾水；但如果你直接给我看底层的数据表结构，我甚至不需要流程图就能理解你的系统功能。

这两句名言结合起来，恰好解释了UML的定位问题。正因为一张图浓缩了千言万语，它也必然会丢失大量的细节。对于需要精准到每一个字符的软件开发而言，将UML图作为指导文件，还不如直接查阅源代码。如果围绕着如此模棱两可的要求进行开发，项目组恐怕会天天争吵不休。

然而，这并不意味着所有UML图都毫无价值。正因为其浓缩信息的能力，图表是一个完美的总结工具，能够高效地向读者传递重要信息。例如，在每个应用程序编程接口（API: Application Programming Interface，软件组件之间进行通信的一组定义）文档上都能看到的序列图（Sequence Diagram: 描述对象之间如何通过消息进行交互的UML图）。作为展示API调用宏观过程的UML图，它能快速地让用户获得一个大致方向，了解整个调用流程有多少步骤、涉及多少参与方、哪些地方有循环、哪些地方有分支等。这些信息能使用户更有针对性地阅读具体的API接口文档，从而更高效地进行后续开发。资深程序员甚至能从中看出哪里可能是性能瓶颈，哪里可能需要更多的开发和维护成本等；这才是真正做到了一图胜千言。只可惜，序列图这类图在UML中真是凤毛麟角，我甚至觉得它们只是歪打正着地做了一个非常适合面向用户的图。毕竟，整个UML从设计之初就只考虑了开发前和开发中的内部交流，而没有考虑过开发后的对外交流。

瀑布模型的没落与UML的终结

我认为压倒UML的最后一根稻草，是RUP这种瀑布流项目管理模式在传统行业的没落。在互联网行业，这已是无需多言的事实，快速迭代风格的敏捷开发流派几乎就是为互联网而生的。而在传统行业，RUP也陆续失去了吸引力。例如，制造业曾是RUP的“自留地”，因为制造业只有一次机会：软件一旦安装在电路板上、装配到机器上并销售出去，便没有回头路可言。一次召回事件就可能毁掉一家公司。当年财大气粗的英特尔（Intel: 全球最大的半导体芯片制造商之一）也差点被奔腾CPU（Pentium CPU: 英特尔公司生产的一系列微处理器）的除法错误所导致的全球召回事件折腾掉半条命。因此，对于这些行业，再长的开发周期也是可以接受的。

然而，进入21世纪后，大众的消费习惯发生了改变。尤其是互联网大厂的各种软件产品，已将消费者“调教”到对“半成品”习以为常的程度。经历了数字化和网络化升级的传统行业，现在也具备了同样的开发能力。关注电动车行业的人，应该对各大车厂的各种空中下载技术（OTA: Over-The-Air，通过无线网络远程更新软件和固件的技术）新闻见怪不怪了。不少消费者对此颇有怨言，认为还是以前一手交钱一手交货的传统燃油车更好。但不可否认的是，OTA技术大大缩短了车厂的研发周期，消费者也能更早地享受到新技术。因此，“先上架、后优化”的风气传播到各行各业也就不足为奇了，毕竟这种互联网方案带来的“降维打击”真的让人“谁用谁上瘾”。那么，当传统行业都不再愿意进行冗长的一次性交付项目时，RUP这种项目管理模式还有谁会买单呢？或许只剩下那些不追求盈利的政府项目了吧。

UML的历史使命与遗产

我认为UML已经完成了自己的历史使命。在软件工程分工已相对成熟的今天，负责规划的产品经理、负责协调的项目经理、负责设计的架构师、负责主导开发的技术主管（Tech Lead）以及负责编写代码的程序员，各司其职。管理团队与技术细节之间的距离越来越远。即使现在某个产品经理有新的想法，在每天开完8小时的会议之后，他/她也已没有精力去审核某个数据表的结构设计了。

然而，回溯到30年前，当时人们仍在摸索软件工程的最佳实践：管理团队应该多深入参与项目的设计和开发？需要参与敲定多少技术细节？一开始没有人知道最佳的平衡点。因此，如果我们换个角度，不将UML视为对程序员自上而下的开发要求，而是将其看作是给管理团队自下而上的汇报工具，那么在那个迷茫的年代，它无疑是一个合理的存在。当然，这个定位在后来的实践中走偏了，那是企业自身的问题。而作为一个以图案形式表达软件概念的工具，UML帮助许多行业和企业完成了数字化转型，享受到了计算机技术带来的红利。就这一点而言，我认为它这一趟，没白来。