爲何掌握 UML 建模是成爲編程高手的一條捷徑？

爲何掌握 UML 建模是成爲編程高手的一條捷徑？

---

 

做者： 張恂
保留全部權利，禁止轉載
知乎同問

江湖上最多的是水平通常（平庸）的碼農，數量估計超過 2/3，而編程高手在數量上其實屬於弱勢羣體，遠不及 1/3。人們常把編程高手稱爲軟件架構師（至關於碼師），以區別於通常的軟件設計師、程序猿或碼農。

那麼，普通碼農與編程高手，在開發能力和水平上到底有哪些區別？

主要緣由

掌握 UML 建模之因此是成爲編程高手的一條捷徑，主要與 UML 建模的價值和用途有關。

緣由1、基於 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，甚至一度還成爲江湖上程序猿羣體的主流意識？緣由是多方面的。

緣由2、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 的一個重要實踐。

緣由3、UML 幫你快速、形象、牢固地記憶設計模式和方案

20 多年來，大量成熟的軟件設計最佳經驗已經被國內外專家與大師們保存在設計模式（Design Pattern）當中。編程高手與普通碼農的一大區別就在於掌握軟件設計經驗和知識的多少，而高手精通大量的軟件設計模式，不但腦存儲量大，能夠信手拈來、隨用隨取，並且每每能用得恰到好處。

設計模式中蘊涵的軟件設計經驗都是抽象的知識，它們高於代碼，不是代碼，因此用 UML 來表現設計模式經常是最佳方式，二者是絕配。當有人唸到一個設計模式的名稱，如 Observer，你的腦海中是否能很快浮現出這個設計模式的具體結構，有哪幾個類或對象，它們之間的靜動態關係如何，是如何執行運轉的？爲了記住一個經典好用的設計，有了 UML 這些抽象、簡單的圖形符號，咱們就不必再死背一行行的代碼，而只須要輕鬆、有效地記住一個抽象的設計框架和實現重點。

編程高手最厭惡死記硬背，而普通碼農經常習慣、依賴於死記硬背。經過 UML 圖（如類圖、交互圖等）來分析、記憶許多設計模式和其餘成熟的設計方案，是提高我的軟件設計能力的一條捷徑。有經過背代碼來死記設計模式的嗎？這麼作是否是有點笨？

緣由4、UML 幫你直觀、形象、準確地與隊友溝通、探討軟件設計

編程高手一般有很強的技術溝通能力。

緣由5、畫 UML 圖是閱讀、理解、學習源碼的高效手段

編程高手經常經過閱讀、學習別人的（開放）源碼來提升本身。

你歷來都只是乾巴巴地閱讀源碼，靠絞盡腦汁來理解，靠死記硬背來記憶，歷來都不畫圖？這麼作有點笨吧。

畫什麼圖？怎麼畫？

固然最好是用國際標準符號（UML）了。

小結

爲何掌握 UML 建模是成爲編程高手的一條捷徑？

簡單回答，由於 UML 建模是進行 OOAD，學習運用設計模式，精讀源代碼，敏捷地思考和溝通軟件設計方案的一把利劍，也是成爲軟件架構師的必要條件和技能，而這些是普通碼農所不掌握或不屑掌握的。一旦熟練掌握了 UML 建模技術，恭喜你，你已超越了江湖上 70% 的碼農！

參考

。。。