小议uml

    最近读了潘加宇的《软件方法-业务建模和需求》，首先毋庸置疑的是其诙谐幽默的比喻着实让我对软件工程了理解加深了一些。从字里行间能够读出其对建模带来的效益大加确定。

    但是，仔细一想，在我最近作的两个项目中，我用到了建模了吗？没用到。软件着实已经出来了，我不能保证这个软件往后维护的成本有多高，我就关注一个问题，建模能不能对软件工程有很大的帮助，或者说建模与否对咱们真正提升了效率吗？这个问题值得商榷。（本人目前没作过服务于超大量用户的软件，如下仅是我的观点，想到哪写到哪）

    记得大二的时候上《软件工程》这门课的时候，有一个完整设计一个项目流程的实验。记得当时作的是植物养分检测系统，画用例图，类图什么的所有用了rational rose，当时在画图上真的很费功夫和时间，但是最后收到的效益并不大（也是一直在反复修改图），比较前几个月作的项目（没有画用例图什么的），软件最终产品感受也没有巨大的缺陷。

    最近盛行敏捷开发，敏捷意味着快速迭代，别人有没有建模不晓得，咱们的敏捷没有建模。众所周知，真正画好建模图容易吗？真心不容易，修改到让其完美，没有几个小时拿不下来。并且uml规范真的是不二法宝吗？我感受不像，我用一个白板，上面列出各类元素，同时给你们讲解思路，远比本身画了建模图，反复修改之，再认认真真对他人讲，来的更有效率。我本人很是赞同敏捷开发，与其画几个星期建模，而后所有按照要求来实现，真的比多让程序员亲身操做，而后论证结论有效吗？在咱们小组中，采用的就是后者，快速试错，快速总结，从新再来。对软件工程领悟的最深的一点是“没有银弹”，真真正正完完美美的搞出一个软件，目前本人没有了解到相关的方法。

    本人不反对建模，在学习《设计模式》的时候，类图让我很清晰的看到了如何设计软件，怎么更好的实现高内聚低耦合，只是我感受，uml并不适合所有人，尽管这是个国际规范，在小型的公司，出活快速变现维持公司运转，远比那些深邃的理论来的更实际吧。