如何反駁 UML 無用論?
相關問題
UML 還有用嗎? - 編程UML 在業界的使用情況如何? - 軟體工程
我只看到團隊敏捷中,稍複雜點的需求,但凡要求團隊上了一點流程圖、序列圖、狀態圖,後續埋坑少一半。
這幫貨都不動腦子的,開始了。。。。眼裡就只有代碼。沒有流程圖保證業務閉環,沒有序列圖來協助系統功能實現劃分,沒有狀態圖協助業務扭轉。。。。。我就表示在敏捷的高效打斷開發中,你是如何在代碼過程同時要考慮代碼上下文、業務流程、系統前後端、多個系統切換開發中做到順利高效的?不提在基本的軟體架構中,如何高效的抽象軟體代碼的基礎。。。所有的圖都是協助大家更高效的理清問題,掌握知識,高效解決問題。。。如果你有比UML圖更好的解決方案,團隊理解通行,可以無視。不管有多少人討厭UML,很簡單,在我這,要我在review格子里簽字,沒UML不成。嫌複雜的都是不懂的,跟老外嫌筷子難用一樣,就是不會用,用不久而已。
好了,現在有敏捷了,更合適你們什麼文檔都不想寫的特點了,中國做敏捷的,說90%可能太多,80%絕對太少,都是借著敏捷名字不寫文檔,不好好設計,編到哪裡是哪裡。這樣的人,在我看來,不是程序員,是翻譯,把自然語言翻譯成高級語言而已。
我 1997 年第一次見到 UML,1998 年正式學的 UML(當時 Rational 公司還未進入中國)。2003 年我發表了《駁 UML 三大硬傷論》,2013 年發表《評潘氏軟體方法》。
18 年來,國內外的各種「UML 無用論」一直不絕於耳,每隔幾年總會時不時地沉渣泛起,但總的趨勢是向好,OOAD、UML 早已進入了國內各大院校的課堂,而理解和支持 UML 的人也越來越多,現在到了該總結的時候。
Cao,UML 居然反人類?
看到樓里有人說:
UML這種反人類的建模「語言」,除了順序圖有點用外其他基本都是垃圾,說有用也是我承認UML順序圖在其適用場景上,算是比較好理解。其他的圖,我隨便畫的一個圖都比他能解釋清楚。
18 年來我還是頭回看到有人說 UML 「反人類」,這是我迄今為止看到的對 UML 最嚴厲的指控,已經上升到如此高度了,真可謂空前絕後。
難道你不知道,用圖形、符號來理解事物(尤其複雜的事物)是人類(進化出來)的本能?圖形的出現比文字還早。沒文化,真可怕!
Wikipedia: Drawing
Drawing as a Form of Communication Drawing is one of the
oldest forms of human expression, with evidence for its existence
preceding that of written communication. It is believed that drawing was used as a specialised form of communication before the invent of the written language, demonstrated by the production of cave and rock paintings created by Homo sapiens sapiens around 30,000 years ago. These drawings, known as pictograms, depicted objects and abstract concepts. The sketches and paintings produced in prehistoric times were eventually stylised and simplified, leading to the development of the written language as we know it today.
最早的人類繪畫至少是 4 萬年以前,這大概就是我們今天 UML 建模的古老起源:
新研究證實迄今最古老岩畫
這個研究小組在新一期美國《科學》雜誌上報告說,他們調查了西班牙北部11個山洞中的岩畫,使用鈾同位素進行年代測定。結果顯示,其中一些岩畫的歷史至少有4.08萬年,這使得它們成為迄今已知最早的岩畫。此前已知最早的岩畫是在法國山洞中發現的,約有3.9萬年曆史。
nature: Spain claims top spot for world』s oldest cave art
Cave of Altamira and Paleolithic Cave Art of Northern Spain:
(Source: http://whc.unesco.org/en/list/310/)再看看 Da Vinci 大師當年的設計圖稿(Crossbow machine 模型):
至於現代科學與工程界,哪一個領域不是廣泛地使用各種標準圖形、符號與模型來表達設計,包括建築工程、機械工程、電子工程、通信工程、網路工程、計算機工程、船舶工程、橋樑工程、航天工程等等,當然也包括軟體工程,相關的例子舉不勝舉,讀過理工科的應該都知道,不必我贅述。
其實,了解了 UML 以及現代軟體工程的進化史你會知道,說什麼「UML 反人類」才是真的反人類。在軟體工程、程序設計中採用各種 UML 圖形來建模,化繁為簡、抽象表達,這本來就是極其自然、符合人類直覺的事,可以說是一種軟體設計學上的返樸歸真。
實踐先看幾個大廠。
Oracle JDeveloper
免費下載
Oracle 2016 年最新發布的 JDeveloper 12c Release 2 (12.2.1.1) 延續了對 UML 的堅定、強大支持,除了標準的 UML 類圖、序列圖、活動圖、用例圖和擴集圖以外,還提供了 4 種額外的 Oracle 擴展圖:- 業務構件圖
- 資料庫圖
- EJB 圖
- Java 類圖
詳細文檔:Developing Applications Using Modeling
JDeveloper 還支持 UML 類圖到 Java 代碼、資料庫以及 ADF 業務構件的雙向轉換,這些應該是 Oracle 的強項。
UML 無用?那為什麼 Oracle 的 JDeveloper 還要繼續支持 UML?這可是最新發布的,而且免費的哦。
微軟
。。。
愛立信與 Papyrus
。。。
IBM
。。。
說完了大廠,再來說說幾個小廠。
StarUML
著名的工具軟體 StarUML(StarUML)在全球已有超過 400 萬的下載量。
同樣來自 StarUML 官網的報告:
EA另一款 UML 工具 Enterprise Architect(http://www.sparxsystems.com.au/)在國內外也有很大的使用量。EA 曾兩次獲得 Jolt 大獎,已賣出了超過 36 萬個許可證。EA 曾經獲得的主要獎項:
以上這些實踐數據可能就是對 UML 無用論最好的反駁。
誤解
用例、序列圖什麼的整理思路還是不錯的,其他的說不上
說這種話的人,應該是沒開發過什麼複雜的系統、軟體吧。複雜的業務流程(活動圖),複雜的運行邏輯(狀態圖)與演算法(活動圖),複雜的程序設計(類圖、對象圖)與架構(包圖)。。。估計這些圖和設計他都沒用過,甚至沒見過。
。。。UML這種反人類的建模「語言」,除了順序圖有點用外其他基本都是垃圾,說有用也是我承認UML順序圖在其適用場景上,算是比較好理解。其他的圖,我隨便畫的一個圖都比他能解釋清楚。為什麼我一定要用他規定的畫圖?他的規定的線條什麼的其他人懂嗎?幾條線幾個框,最多加幾條注釋不行嗎,非要記那種奇怪的實心空心三角形,虛線什麼的表示的意思?設計UML的人的想法就是來自中古時期的,工業標準出來的。初衷也許是好的,但是沒考慮過現實和理想的不同。軟體設計和建築設計的不同。軟體設計不像工業領域,更像藝術領域。想像一下,幾個人搗鼓一個畫畫的標準,規定到了畫畫的顏料牌子,每一筆的顏料用量,又規定畫一個圓形必須要塗上黃顏色,否則他們不承認這個叫圓形。像這樣硬要讓別人按自己的規定來畫畫,豈不可笑?
UML出來之後後面相應的設計軟體開發起來,涉及到經濟利益,自然有了一批擁躉,不斷傳銷這個東西。但是,10幾年前就說可以用UML直接出代碼了。現在有拿得出手的實現出來了嗎?現在業界有多少人用UML?仔細分析一下,不難發現:UML的標準寫法是反人類的---這個圖不是用來給人看的,也不應該讓人類去畫UML自動化生成代碼效率低,不如直接寫代碼---這個圖給機器看毛用也沒有綜上,UML騙了一代又一代人,也養活了一些騙子和騙子公司以此為業。嗚呼哀哉,烏托邦而已。
現如今依然支持UML的,要麼是大學裡啥都不懂混日子的老師,要麼是初出茅廬的學院派,要麼就是UML圈子的利益相關者。實踐是檢驗真理的唯一標準,UML必將漸漸被掃入歷史垃圾堆。遺留下來的,估計也就是其中部分圖的簡化變種版,以及計算機發展歷史上笑話中的一個。也奉勸各位UML圈子裡的從業人員,及早吸取新知識,過幾年忽悠不住了就要轉行啦。=============感謝各位點贊的朋友===================那就容我最後再吐槽一句,知道看到UML讓我想到了啥嘛?沒錯,道爾頓設計的原子符號。^_^1. uml不是給一個角色用的,而是軟體開發周期中的很多角色,甚至包括客戶。2. uml在個人用時是用來整理思路的,多人用時是用來輔助溝通的。如果只看個人用,那麼確實對有些人沒用,或者一目了然或者根本就沒有思路還整理什麼?
3. uml完全可以更漂亮,只是多數場景下沒必要美化而已。
4. 畫個uml符號值一塊錢,知道該畫什麼值十塊錢,知道誰該連接到誰值一千塊錢。首先,沒UML無法理解設計模式的,不管是互聯網上還是各種書籍上,描述設計模式必然是UML的靜態圖,如果有其他更精確的描述方式,請指教。
為什麼會有這樣的現象?關鍵是溝通語言的統一,UML的主要功用不是用來生成代碼的,UML的主要功用不是用來生成代碼的,UML的主要功用不是用來生成代碼的,重要的事情說三遍。
接下來,看看 UML 的各種圖都幹什麼的:用例圖描述系統的外部交互、序列圖描述系統的內部交互、狀態圖描述系統的動態特性、部署圖描述系統的物理節點、類圖與對象圖描述依賴關係。。。。
從上面的各種特性來看,沒有一個是跟生成代碼有關係的,但是如果團隊內部把這些東西用熟了,扯皮倒灶的事情還會有多少?
就像 @蘿魏紫 說的,中國假敏捷太多了,以敏捷為借口少寫甚至不寫文檔,以至於大量項目在本不應出問題的溝通層面出現大量問題,沒有統一的標準,溝通不出問題才怪,UML 不是萬能的,但是在系統研發中的溝通作用,效果還是比較好的。
上面好多人說UML沒用,個人感覺更多是中國大量垃圾UML書籍導致的,我看過很多講解UML的書,大量篇幅在列舉圖例,講如何生成代碼,但是從用例圖到序列圖、狀態圖如何演化的過程,幾乎沒有涉及,所以工具在那裡,理解了,可以成為臂膀,不理解,就是垃圾。
客觀地看待,UML只是一個畫圖的工具而已,用例圖,類圖和序列圖還是有點用處的,畢竟圖片比文字直觀。
個人喜歡先在TDD開發中寫代碼,再將系統中代碼比較複雜部分畫成UML用例圖,類圖和序列圖。
測試用例和源代碼是最好的文檔,配上一些UML圖是可以讓後來的人更好地理解代碼。UML圖並不是無用,而是有時不太好用有時又不夠用。而且還有個前提——它基本上是針對面向對象範式。個人認為它的最大用途就是大家用同一種圖形化的表示,從而有利於交流。
對於大型的複雜系統來說,比如操作系統,肯定是不夠用的。資料庫建模基本用不上。建模並不是只靠UML圖就能做到位。
對於不那麼大的系統,比如一個小型框架,UML用來建模也夠了(怕就怕只因為系統看起來不大就只畫類圖順序圖,一概不涉及狀態圖活動圖等等)。
另外,維護複雜的系統時針對模塊畫一些UML能幫助理解。
說它不好用,是因為,如果要生成代碼,就必須嚴格按照規範來畫,即便如此,生成的代碼也不好。
當然,如果設計開發模式是「快糙猛」,那當然無用。
UML無用論不過是因為它幾乎被宣傳成銀彈後帶來的反彈。說實話我也挺討厭那幫吹鼓手,好端端的一個工具,非要去神化它。屁股決定腦袋,古人誠不欺我。有啥用?
用例,活動圖 順序圖 狀態圖,這些常用。東西都是好東西,估計也不是他首創。按需選擇幾種圖挺好。是設計的共同語言的,是剛需。但是全面系統的用這個,覺得沒有必要
愛用不用,有啥好反駁的。
Use Case 曾經是先進的,現在已經逐漸被更好操作的 User Story 取代。 Class Diagram 什麼的還是很有用,不過不計較細節精確的話,它跟白板上的框圖其實就是一回事兒。
總體看來,互聯網和移動互聯網兩波熱潮,已經讓軟體工程管理徹底倒向了人的能動性,而不是人的風險性。傾向於電路設計圖般規範的 UML 表示法自然也就不那麼討喜了……說清楚UML是拿來幹嘛的,
- 節約時間的- 幫助分析的- 解釋複雜功能- 知識儲備另外還有UML的extension,- 節約時間- 方便管理- 重複利用凡是對設計模式要求比較高的的企業一般都會要求你必須會uml。。
語言語言,就得從用得最多的開始啊,一點一點改進就是了。三大圖還是很有用的,很多人在用而不自知罷了。
對項目負責的人有用,對代碼負責的人無用
UML表達還是方便,但畫出來太複雜了。以後應該是通過代碼生成幾種典型的圖形用來交流用
用UML裡面對你有用的部分。
這個有用的部分對每個人和每個場景下都不一樣,舉個例子:你在畫圖解釋/推演程序邏輯,不管是向自己或是向別人,不用自己發明一堆符號說這個代表類這個寫法代表方法,這條線表明function call,那條線表明繼承或者實現 -- 總的來說至少你可以借鑒UML裡面的規範來建立你自己畫圖的vocabulary。
對我而言UML的作用主要是讓我在更高的抽象層次上思考問題,所以我發現白板和草稿紙上的UML通常都很有用。大學開設了 UML 課程,然後我就發現了新的世界,原來上課睡覺時那麼的美好!
其實UML一開始的設計思路還是不錯的,可以銜接高層抽象和底層實現,是軟體工程的一種嘗試。現在很多人鄙視他最主要是因為現在隨著互聯網的大火,大家比較講究敏捷開發,快速迭代。UML這種體系化形式化的笨重東西就不怎麼討喜了。完整的UML其實是很強大的,不過非常複雜,這樣形式化出來系統,要比直接寫代碼還要難。所以大家一般只選取UML的一小部分來用,那樣就減少了UML形式語義的作用,看起來就還不如隨手畫畫了。個人覺得如果不是做互聯網的,有些大型軟體用UML做設計還是有用的。這玩意現在還活著好好的就證明還是有用的。
UML最早提出的願景還是蠻有野心的。希望建立一門統一的建模語言,讓用戶、諮詢顧問、系統分析師、軟體工程師、測試工程師等都採用同樣的語言進行溝通,以避免多方在溝通時出現誤差。畢竟溝通是軟體開發過程中最大的風險。然而UML並沒有成為Unified Modeling Language,畢竟它也是一門Language,主流人群並不懂這門Language。
推薦閱讀: