學老半天(真的很久)
後來發現,被一堆人問了到底為何用 UML 圖,自己也疑惑了好久,最後發現他的價值
古代人狀況一:
以前都自己做程式,跟2-3個二人快速建製程式,效率又快又好,幹嘛那東西,太慢了~!
古代人狀況二:
所有的東西我有screen shot, input/output 都可以跟 user 需求到,幹嘛畫啥 UML
input/output 正確,中間邏輯我自己解決就好啦,甚麼 UML??
古代人狀況三:
有 SA/SD 規格都弄好了給我寫程式,我照本宣科就好,幹嘛學那?反正資訊人員工作挺好找的,換個工作又容易,又可加薪水,學那幹嘛?
古代人狀況四:
我好優秀喔,我一下就學會 UML, 也都畫得出來,也會分析,也會 coding, 工作也做得出來,然後呢?Domain know-how 不用了解啦,很會問、會畫圖,然後給下面人做 coding 就好啦。但是網站卻不賺錢。。。。。業務的錯啦,公司的錯啦。。。。
以上狀況
狀況一:
中小型企業公司商業邏輯簡單,當然這樣就夠了,但如果沒有乖乖的做好顯示層/邏輯層/商業邏輯層分開,以後要 refactor 你就很難了。如果架構開始變複雜,那就開始爆掉了,沒人想維護,離職開始
狀況二:
這跟一很像,中間邏輯自己解決,然後呢?沒分層好,你一直在增加自己的 "技術債務",然後離職潮開始。
狀況三:
大公司分工清楚,這很好,但台灣以後直接跟對岸競爭,不會畫沒關係,先學會看吧
狀況四:
優秀的資訊人員應該像是名醫,你的病人(需求者或是老闆)跟你說他的症狀,你可以替他解決現在的問題和未來的問題(撇開道德風險不談)。
你有過去看名醫生排很久,然後他1分鐘就看完嗎?因為他看太多了,一眼看出問題在哪。
喔,that is great。
但是,你有時會不會覺得還是醫不好,他一直在症狀治療
或是告訴你他多懂,但你的病一直不好
你有看過 Doctor House 這部美國影片嗎?他最主要是說很多病因是由家中環境影起
所以他都會去派他的手下去看病患的家中去採集狀況。
不去了解 domain know-how 的自負工程師,就像不去真的了解病患家中實際環近狀況的醫生
一直用儀器治療,然後症狀治療,醫不好反正也不是我的問題,我又不是神。
但這樣真的是優秀的工程師嗎?
你可能會想。。。我又沒多拿錢。。。。我在公司地位很高了(或還不夠高),還是忙內鬥或向上管理等事務吧
但這樣真的是優秀的工程師嗎?
圖案來源:http://stuffkit.com/wp-content/uploads/2012/10/amazing-photos-2012-27.jpg