特洛瓦 wrote:
其實UML這種東西就是包含在規格書裡面，也不是說要給主管或著看不懂程式的人進行閱讀，
軟體開發最多成本其實最多是花在維護階段，這種時候規格書就顯得異常重要，
基本上只要受過"基本"資管訓練的人員，觀看與閱讀規格書，就可以大致了解系統的運作，
相對來說，對於後續人員的維護上就會容易些。
說的沒錯
但這跟現實是差很遠的
小弟寫程式十幾年了,進過不少公司,做過不少大project,都沒去寫UML
往往現實的情況是
你完成這個project,老闆就讓你做下一個,補UML?
沒人有空,寫了只有搶你飯碗的人會感激你,上面也看不到績效
那開發前先寫UML? 沒人會這樣,除非是你畫UML,別的team做,通常不會這樣
前端user也根本不懂UML,你懂程式懂UML,可是往往案子就是你在寫,誰會脫褲子放X呢?
結果就是根本不存在UML
你說的沒錯,維護階段,UML的價值非常高
但這個前提在於
1.有完善的UML 文件(正確且真實反應程式現況),只要code有改,UML也要參考與更新
(一般人做完,下個要做的是修bug吧..上線沒事了?! 下一個project在等你,補UML老闆看不到績效)
2.維護階段遇到問題,卻找不到原開發者,但原開發者很佛心都補好了UML 文件
而這兩個前提都不大容易發生,
大部份人會找原開發工程師來做,不會去翻UML,若是in house team就找in house,如果是外包,就會找外包公司,很少有人會找人去翻文件,多半也是直接看code,因為看UML,天曉得是幾百年前的版本? 另外工程師也懶得寫,寫了自己好丟飯碗給別人嗎?
有人會說,專案的專業主管應該要要求工程師寫
我是專案的主管,但我沒要求,why? 因為他們code的架構都是照我規定在寫,我也能直接看懂code
何必看他們的UML呢? 我寧可他們花時間做別的project,這樣team的績效上面才看得見,不是嗎?
寫UML就像當兵把皮鞋擦亮一點,把衣服穿整齊一點,我是覺得真的很閒才去做它
而且這種東西,高階主管根本看不太懂,你皮鞋擦亮,將軍看了還高興些
