第三篇故事,是来自于贝壳自己的惨痛经历,在另一位朋友那里也有类似教训,可惜他未及早听我一句。

贝壳原来在一家公司里面做项目经理,公司做企业定制开发,现在仍在,所以具体情况隐去不表。因为某些情况,老板叫贝壳做了项目经理,按照资历和能力来说,其实并未足够。贝壳精通的是C++开发,而项目是使用.net技术做的。因此贝壳对项目的管理能力实际上打了一个折扣,只能负责结构设计和协调。当时对项目管理也不是很精通,可以说是半吊子水平。公司承接了一个企业的业务系统开发,经过前期准备,我们团队就开去了客户那里进驻。客户要求,界面一定要漂亮。因此我们选型下来的结果,使用了.net 3.5的wpf开发。开发过程中其实还是有很多问题,很多都是新手问题,暴露贝壳总体设计和项目把握的缺陷。不过这和今天主题无关,就略过不谈了。主要是.net 3.5开发,到了最后发生了几个严重问题。

首先第一个问题,是客户有很多win2000机器,甚至还有一些win98。这个在当初系统设计的时候完全没有考虑。我们开发的机器一律全是winxp,.net 3.5 wpf可以完全的运行在上面。而对于win2000,wpf是无法安装的。于是,我们就必须要求客户升级到winxp。企业用户,他们还必须使用正版。其次,.net 3.5在进行远程SOAP调用的时候,会出现严重的内存泄漏。其实并不是真的泄漏了,.net 3.5的SOAP系统没有考虑调用接口可能多达数百个的情况,对每个函数都进行了序列化器缓存。这个缓存会耗费100-200M的空间,加上其他开销,我们的系统总开销是200-300M,比大部分游戏还高。这个直接导致客户运行我们系统的时候,必须多加一倍的内存。

更郁闷的问题还在后面,wpf是使用dx渲染的系统,因此如果客户没有独立显卡,系统速度就会慢如龟速。wpf的部署必须使用完整sdk,2.0的runtime安装包只有20M,而3.5的完整sdk高达350M。我们在每台机器上安装的时候都是用U盘完整安装350M的sdk。不过这都不是最郁闷的,最郁闷的是,我们项目最后问题实在太多,有个员工做了一个web版的。界面难看很多,但是方便移植部署,内存消耗小。瞬间得到全企业上下一致支持,他们的老板还问我们,当初为什么不这么设计。贝壳哪里好意思说,您不是要漂亮么?

实话说,要不是老板和客户关系好,我们非要给愤怒的客户踢出大门不可。这一个项目,成功的是老板,失败的是贝壳。

总结下来,两个教训。首先是设计必须实地的调查一线需求,不能光听上面的就得出结论,也不能光看部分典型用户就得出结论。如果有一些关键用户对构架支持不良,业务上又不能放弃,就必须权衡得失,甚至修改构架。如果当时我们知道win2000乃至win98的事情,就压根不会考虑使用wpf来做界面。第二个,就是不能迷信技术,或者激进的使用无法掌控的技术。宁可使用最土的办法,老老实实的把业务做出来。新技术由于刚刚出现,因此很多问题都没有完全暴露,很多领域也没有经验积累。例如这个例子里面的内存占用问题,安装包问题,系统问题,都是到了部署时才发生的问题。使用新技术,就会随时面对无人发现的问题,这和RPG的踩地雷战斗是一样的经历。只是这里不但没有经验值,而且踩多了还会直接挂掉。