为什么需要学UML建模

今天在看《设计模式》的时候，看到了许多的UML模型图，案例中作者用极少的代码却能讲清楚讲好设计模式的背景和思想，抽象成一张张的UML图就能很好的review和复盘，这对于在工作中习惯用代码思考的我来说是一个前所未有的挑战和拔高，譬如练武修行之人，如果长期满足于一招一式的细节中，囿于拳谱和剑招是很难成为真正的武林高手，当然不是说这些不重要，而是时时都要用一种高屋建瓴的工程思想来指导自己，代码江湖上不乏经验丰富的码农，但是却很缺少有良好设计思维和抽象能力的工程师和架构师，以后要注意训练和积累这方面能力。用最接近本质和深刻的思想来认识问题解决问题。

 

 

为什么掌握 UML 建模是成为编程高手的一条捷径？

江湖上最多的是水平一般（平庸）的码农，数量估计超过 2/3，而编程高手在数量上其实属于弱势群体，远不及 1/3。人们常把编程高手称为软件架构师（相当于码师），以区别于一般的软件设计师、程序猿或码农。

那么，普通码农与编程高手，在开发能力和水平上到底有哪些区别？

主要原因

掌握 UML 建模之所以是成为编程高手的一条捷径，主要与 UML 建模的价值和用途有关。

原因一、基于 UML 建模的 OOAD 是 OO 软件架构师的基本功

Visual Modeling（可视化/图形化建模）对于软件开发（尤其拥有大量代码的复杂、大中型系统和产品）非常重要，而利用建模技术有效地进行系统分析与设计，能够有条不紊、从容不迫地应对、解决复杂和棘手的软件设计难题正是编程高手们所擅长的。

软件开发本质上是一种思维游戏（张恂：Software development is a mind game.），程序代码的好坏其实是开发者思维的体现。普通码农与编程高手的主要差别正是在于思维，尤其在抽象思维、空间思维、逻辑思维等方面。编程高手如何编程？拿到一个需求，脑子里一片空白或者乱糟糟的就开始写代码？当然不是。

在思考能力上，针对同一个软件设计问题，架构师常常比一般码农想到的更多，更快，也更正确，而且具有预见性。通过建模来进行系统的分析与设计（如针对 OO 软件的 OOAD，即面向对象分析与设计），在大脑中习惯用高层（high level）、抽象的模型，而不是一行行具体、累赘的代码来进行快速、敏捷地思考和决策，是软件架构师的一项基本功。这不是说代码不再重要，而是因为合格的软件架构师对代码细节、语法技巧等已经烂熟于胸，可以更加超脱、宽广的视野思考一些比代码更为重要的设计。

对于职业的软件工程师与高手们而言，软件不仅仅是平面、具体的源代码，软件还是分层、立体的，具有横向和纵向的抽象多层结构；编程也不仅仅是写代码，还有上层更为重要和关键的系统分析与设计，而代码只不过是分析设计（抽象思考活动）的结果与体现。

而普通码农，由于缺乏思维训练、设计经验和思考能力不足，常常不习惯或不善于抽象思考，难以理解抽象的事物，而更乐于理解低层（low level）细节和具体的事物（如代码），不知道源代码之上其实还有抽象的面向对象设计模型（OOD）、分析模型（OOA）等上层建筑，不知道代码错误常常是由于自己的设计（大脑中的“设计模型”）错误、缺陷所导致的。许多业余和初中级码农不明白，自己的 Java、C# ... 等程序老写不好，老出错，老是要改，其中一个主要原因是因为他们不熟悉或不懂 OOD（包括 OO 程序设计的原则、模式和技巧）。而 OOD 不好，你写的程序 OOP 也不可能好，所谓的精通 OO 编程是假的。

专业程序员学习编程，思维从具体到抽象，从低层到高层，从沉溺实践细节到钻研理论方法，从关心代码实现到关心架构设计，是一个很自然的成长、升级过程。作为 70 后，我是从 1996 年计算机系研究生二年级开始自学的 C++、Java、设计模式，1998 年毕业后又自学的 OOAD 和 UML，当时正是 OOAD 在国外最火的年代，而 OOAD、UML、设计模式这些技术课程在国内大专院校基本普及是 2005 年以后的事吧。

软件开发如何进行 OOAD？最佳手段当然 UML 建模。作为国际标准（ISO、OMG），UML 的一个主要用途正是作为 OOAD 的标准建模语言。如今 20 年过去了，对于一位带领团队负责开发 OO 软件系统的架构师而言，在平时工作中不懂系统分析与设计的方法论，也不会 OOAD，看不懂 UML 图，甚至连在白板上画个规范一点的设计图也画不好，这些都是令人难以想象和接受的。难道作为高级程序员、架构师的他，只会用代码思考？所以我们说，不但建模、系统分析设计是架构师的基本功，OOAD、UML 也是。

然而，15 年来中国的软件江湖上为什么老有一批人强烈地反对 OOAD、UML，甚至一度还成为江湖上程序猿群体的主流意识？原因是多方面的。

原因二、UML 帮你对软件架构和设计进行抽象、全面、敏捷地分析与思考

UML 建模方法通过多种图形（Diagram）和视图（View）提供了多个层次、多个角度分析、观察软件架构的丰富手段和灵活表现形式，例如著名的“4+1 视图”（Use Case View, Logical/Design View, Process View, Implementation View, Deployment View）等。基于这样的思考，软件架构的设计才是全方位、系统化和高质量的。

我认为 UML 最大的价值，在于帮助开发者对软件设计进行敏捷的思考（Agile thinking in UML）。针对一个具体、复杂的软件设计问题，编程高手在开始编码之前常常善于利用各种模型、图形与方法论在自己的大脑中进行深入思考和建模（Mind Modeling），明确需求，评估方案的可行性和有效性，衡量各种可选方案的利弊，必要时也会利用白板、图纸等建模工具进行设计，做到胸有成竹后才动手，结果往往效率高、质量高而差错和返工少。这就是专家们常说的 Quality Before Code。

而普通码农，由于缺乏设计经验和思维训练，常常对一个问题的需求和方案还没想明白就习惯性地、急匆匆地开始编码，思维不成熟、考虑失误的结果必然导致代码错误一大堆，改来改去还老改不对（俗称 code and fix），因此浪费了不少时间和精力，还美其名曰“重构”。

每天动手编码前或在编码过程中进行少量、必要（just enough）的 UML 建模、方案设计与思考，可以避免后期许多的折腾和浪费，这无疑是一种非常敏捷的优秀工程实践。其实像 Scott Ambler、Craig Larman、Martin Fowler 等敏捷大师都一直鼓励和提倡敏捷建模（Agile Modeling）如 UML Sketch（UML 素描）。可惜在敏捷运动的前十年时间里这并未引起大家的足够重视，因此我把 UML 建模（包括敏捷建模、太极建模等）列为 Agile 2.0 的一个重要实践。

原因三、UML 帮你快速、形象、牢固地记忆设计模式和方案

20 多年来，大量成熟的软件设计最佳经验已经被国内外专家与大师们保存在设计模式（Design Pattern）当中。编程高手与普通码农的一大区别就在于掌握软件设计经验和知识的多少，而高手精通大量的软件设计模式，不但脑存储量大，可以信手拈来、随用随取，而且往往能用得恰到好处。

设计模式中蕴涵的软件设计经验都是抽象的知识，它们高于代码，不是代码，所以用 UML 来表现设计模式常常是最佳方式，两者是绝配。当有人念到一个设计模式的名称，如 Observer，你的脑海中是否能很快浮现出这个设计模式的具体结构，有哪几个类或对象，它们之间的静动态关系如何，是如何执行运转的？为了记住一个经典好用的设计，有了 UML 这些抽象、简单的图形符号，我们就没必要再死背一行行的代码，而只需要轻松、有效地记住一个抽象的设计框架和实现重点。

编程高手最厌恶死记硬背，而普通码农常常习惯、依赖于死记硬背。通过 UML 图（如类图、交互图等）来分析、记忆许多设计模式和其他成熟的设计方案，是提升个人软件设计能力的一条捷径。有通过背代码来死记设计模式的吗？这么做是不是有点笨？

原因四、UML 帮你直观、形象、准确地与队友沟通、探讨软件设计

编程高手通常有很强的技术沟通能力。

原因五、画 UML 图是阅读、理解、学习源码的高效手段

编程高手常常通过阅读、学习别人的（开放）源码来提高自己。

你从来都只是干巴巴地阅读源码，靠绞尽脑汁来理解，靠死记硬背来记忆，从来都不画图？这么做有点笨吧。

画什么图？怎么画？

当然最好是用国际标准符号（UML）了。

小结

为什么掌握 UML 建模是成为编程高手的一条捷径？

简单回答，因为 UML 建模是进行 OOAD，学习运用设计模式，精读源代码，敏捷地思考和沟通软件设计方案的一把利剑，也是成为软件架构师的必要条件和技能，而这些是普通码农所不掌握或不屑掌握的。一旦熟练掌握了 UML 建模技术，恭喜你，你已超越了江湖上 70% 的码农！