小議uml

    最近讀了潘加宇的《軟件方法-業務建模和需求》，首先毋庸置疑的是其詼諧幽默的比喻着實讓我對軟件工程了理解加深了一些。從字裏行間能夠讀出其對建模帶來的效益大加確定。

    但是，仔細一想，在我最近作的兩個項目中，我用到了建模了嗎？沒用到。軟件着實已經出來了，我不能保證這個軟件往後維護的成本有多高，我就關注一個問題，建模能不能對軟件工程有很大的幫助，或者說建模與否對咱們真正提升了效率嗎？這個問題值得商榷。（本人目前沒作過服務於超大量用戶的軟件，如下僅是我的觀點，想到哪寫到哪）

    記得大二的時候上《軟件工程》這門課的時候，有一個完整設計一個項目流程的實驗。記得當時作的是植物養分檢測系統，畫用例圖，類圖什麼的所有用了rational rose，當時在畫圖上真的很費功夫和時間，但是最後收到的效益並不大（也是一直在反覆修改圖），比較前幾個月作的項目（沒有畫用例圖什麼的），軟件最終產品感受也沒有巨大的缺陷。

    最近盛行敏捷開發，敏捷意味着快速迭代，別人有沒有建模不曉得，咱們的敏捷沒有建模。衆所周知，真正畫好建模圖容易嗎？真心不容易，修改到讓其完美，沒有幾個小時拿不下來。並且uml規範真的是不二法寶嗎？我感受不像，我用一個白板，上面列出各類元素，同時給你們講解思路，遠比本身畫了建模圖，反覆修改之，再認認真真對他人講，來的更有效率。我本人很是贊同敏捷開發，與其畫幾個星期建模，而後所有按照要求來實現，真的比多讓程序員親身操做，而後論證結論有效嗎？在咱們小組中，採用的就是後者，快速試錯，快速總結，從新再來。對軟件工程領悟的最深的一點是「沒有銀彈」，真真正正完完美美的搞出一個軟件，目前本人沒有了解到相關的方法。

    本人不反對建模，在學習《設計模式》的時候，類圖讓我很清晰的看到了如何設計軟件，怎麼更好的實現高內聚低耦合，只是我感受，uml並不適合所有人，儘管這是個國際規範，在小型的公司，出活快速變現維持公司運轉，遠比那些深邃的理論來的更實際吧。