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

贝壳原来在一家公司里面做项目经理，公司做企业定制开发，现在仍在，所以具体情况隐去不表。因为某些情况，老板叫贝壳做了项目经理，按照资历和能力来说，其实并未足够。贝壳精通的是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的踩地雷战斗是一样的经历。只是这里不但没有经验值，而且踩多了还会直接挂掉。