为什么我拒绝Spring项目

为什么我拒绝Spring项目？就是因为Spring项目的高失败率。在国内一线城市里的表现还不明显，因为有政府和国企的采购托着一线城市众多的软件公司，养活了太多的不应该存在的公司和产品，但是在二线城市表现得就非常明显了，因为二线城市的政府和国企项目金额少很多，数量上也差得远，现有合同额难以填满Spring项目的损耗，亏损是必然的，甚至不少一线城市的公司都在抱怨二线城市里政府项目的钱难挣，不少二线城市的公司从一线城市重金挖来的团队却把公司赔个底掉。据我观察，每十个Spring项目中，至少有7到8个是失败的，大部分投资并没有得到回报，活下来的项目至少有一半也是和政府和国企相关且质量低劣（原因很简单，既然高损耗无法避免，那么只能靠降低质量盈利了），Spring成了名副其实的浪费民脂民膏的东西。招聘方面的情况就是这个现象的旁证，二线城市以Spring为主要技术架构的公司特别是初创公司，每三年就会大面积更换，消失的那些公司除了少部分是因为更名外，绝大部分都死掉了。虽然Spring项目不需要在收费的应用服务器上运行，但是在你上手之後，很多足以压垮项目的隐性成本就逐渐显现，在下文中就为您细细讲来。

一、非标准化带来的成本上升

Spring的风格更像是一种反叛，有人说生产力的发展需要反叛精神，但是反叛的结果可不一定是光明的未来，我们经常看到是一地鸡毛，况且做产品需要科学精神和工匠精神而不是反叛精神，我们看到的Spring项目中那些“炫酷”的东西里充斥着太多的隐患，最让人诟病的是静态变量和滥用的线程，以至於在标准化的JavaEE和JavaWeb容器上无法重新部署，非要重新启动服务器不可，浪费的时间大家可以自己计算一下。在JBoss或Weblogic上开发和运行一个Spring项目更是困难重重，只能在tomcat和jetty等功能简单的服务器上运行，如果你想念应用服务器上的很多便捷的功能，对不起，你最好选择功能相近的Spring模块，否则就是无尽的麻烦，这些模块里的bug和设计问题，你只能默默忍受。因为Spring是非标准化的，你不要再想像以前一样从Weblogic、Websphere和JBoss之间互相迁移，你的项目已经被Spring套牢了，你不满意也没有退路。

二、Spring是一堆半成品的松散组合而非整套方案

Spring给人的印象，就是一大堆的软件半成品，几乎所有功能都需要人手动组合，每个开发都有自己的组合方法，而且Spring代码库复杂，一旦遇到Spring模块中的bug很难定位到出问题的地方，要么自己修正要么想办法避开，对付模块组合中的问题你需要付出很多额外的成本。另外由於每个开发者都有自己的模块组合方式，造成他人难以适应。标准的JavaEE项目在其他人接手时通过代码和配置文件很容易就可以梳理出清晰的脉络，但是如果你接手的是Spring项目，这个基本上很难，更别说你碰上个奇葩架构师。

三、Bug成堆

笔者遭遇过Spring MVC、Spring Security上的好几个bug，还有几个filter里的bug无法确切定位是哪个Spring Filter里带来的，甚至对HTTP POST信息的解析都有bug，开发过程中这些bug造成了很多麻烦，至少我以前在应用服务器上做JavaEE开发时从来没遇到过这么多严重的问题。而且，因为Spring是非标准化的，你没有替代品，你只能硬着头皮用下去，绕过这些bug所造成的时间成本你也只能硬扛下去。为了解决这些问题，你需要雇佣很多“Spring高手”来解决问题，你从应用服务器上省下来的钱就这么逐渐被消耗殆尽，更别说浪费的时间成本。这是造成Spring项目在後期步履维艰的一个重要原因。

四、被单一提供商套牢

之前在使用标准的JavaEE应用服务器开发时，如果对方对可靠性和可扩展性比较在乎，你可以选择Websphere和Weblogic等知名厂商的产品，这些应用服务器一般都带有灾难恢复和集群功能，你可以免去很多开发工作，如果你要做的软件比较简单，JavaEE的基本功能就够用了，你完全可以选择开源免费的JBoss，而且JBoss的灾难恢复和集群功能同样很牢靠，如果你需要更轻量级，你可以选择Apache的TomEE。但如果你选择了Spring，对不起，你将不再有这种辗转腾挪的空间，你只能按照Spring的行事方式行事，研究他们的模块，处理他们的bug，你甚至不再像以前一样享有不满意的权利，因为你没有其它兼容的产品可以选择，悬崖勒马对於Spring开发者来讲是一种奢望，你只能按着Spring给你的路一直走下去，哪怕结局是失败。

五、人员浪费

因为Spring的架构是一堆需要自行组合的半成品，没有良好的封装，所以启动一个项目需要招募更多的开发者来组合这对半成品并测试其中的问题，使用更多的开发者来做以前完成了无数次的工作，这本身就是一种浪费，在项目推进过程中，仍然会间歇性地遭遇到那些半成品组合後出现的问题。经本人观察，无论是启动项目的人数和项目膨胀後的最大规模，Spring项目在人员上的投入往往是标准JavaEE项目的两倍。

六、开发水平的倒挂

Spring这种松散的架构理应需要水平更高的开发者来使用，实际上并非如此，这种经过大量定制的松散架构理应是软件中的奢侈品，因为它没有标准化的接口和独立的模块设计，但大多数参与Spring项目的人员都是接受培训没多久的新手，工程思想和对工程师文化的认识都欠缺。就算是老手，搞通Spring这种松散架构也要付出比标准JavaEE项目更多的努力，在实际项目过程中，Spring项目到了後期无一例外地陷入混乱。不少人这时候都想到一个“妙招”，就是将Spring项目的架构进行中央集权式的统一管理，这种做法在初期都会显现出一些好的效果，但在後期效果却反过来，由於没有考虑到不同开发者的不同情况，这种方法做出来的架构到後期往往会发生比前者混乱得多得局面，然後仓促的加入很多东西导致整个项目每一步都走得异常艰难。那些所谓的“创造性思维”，在成本面前是那么的软弱无力。

在现实情况下，将设想变成实际的产品，需要的是设计师和工程师，而非艺术家，产品在用户使用过程中会发生很多意想不到的情况，所以就需要在设计上反复推敲，在实现上细致入微，如果用Spring这种松散架构，你就要做好付出很多额外成本的心理准备，因为Spring里面很多非标准化的设计，没有经过现实的反复考验，会出现很多未知的问题，解决这些问题造成的额外成本往往无法预估，所以Spring这种松散架构只能用来做奢侈品和实验品，难当大任。如果你确定要采用Spring，你就要为这个框架所带来的项目高失败率做好心理准备。