最近换了一家公司, 名字就不说了. 这家公司规模还是很大的.
他们比较强调管理, 我这里说的是设计的管理.
大家都知道UML, 里面有Class Diagram, Sequence, User Case等等我们经常会用到的设计图形, 用图形的方式来描述一些问题, UML提供了一些标准, 在这些标准上UML成为大家能够理解, 或者说比较少出现歧义的 一个工具.
不过我想说的问题是UML能够带来什么?
我做的是架构师的工作, 因此上面3个图形成为比较关心的内容. 这里想单独谈谈Class Diagram. 所谓类图, 就是描述类之间的关系的图形. 但是类图是怎么产生的呢? 首先要有想法, 要有设计. 当设计者觉得类的关系应该是这样的时候那么类图自然而然就产生了. UML只是提供一个通用的, 大家都能理解的平台来把这个图描述出来. 但是如果设计者没有充分理解需求, 那么他所设计的类图也注定是错误的. 即使使用UML, 或者更高级的工具来体现设计意图, 也只能体现出错误的设计意图. 那么这个时候UML也就失去了其意义. 当然在这个层面上, UML或许能够更好的反应出设计者错误的设计理念, 以便能够让其他人去发现他, 修正他.
所以我的观点就是UML是次要的, optional的. 设计理念才是主要的, 必须的. 如果设计理念上有问题, 那么使用什么工具都是白搭. 只能浪费更多的时间去制作这些精美的图片(这些东西我认为只能称为图片, 没有什么具体意义). 如果本末倒置, 那么对系统的影响是致命的, 不可修复的.
现在这家公司就是这样, 为了UML而UML, 没有任何意义, 一堆所谓的精英抱着N年前的想法说要设计framework. 有新的想法出来, 大家要做的事情就是打压下去. 因为历年沉积下来的代码已经变得没有办法重构和维护, 或者是根本就没有想法去更新技术? 我不得而知. 所谓的架构只是一纸空文, code才是硬道理. 4年前我离开这里, 4年后回来原来以为这几年应该有所长进, 没有想到仍然是这样, 超过3位数的service, 4位数的表单, 无数不知去向的常量定义和配置信息以及几万个类构成了一个可能只需要十分之一就可以搞定的项目. 居然还想把这些东西堆彻成产品! 这就是一个在业界被称为领军人物的公司的现状. 我只是一个小小的架构师, 没有办法改变什么, 或许混日子才是王道啊.