j2EE架构的批判及随想（Web开发的困境）

Web系统开发的复杂性

在企业级的应用系统开发领域，J2EE架构现在已经被普遍接受了。虽然它并未完全兑现刚刚出现时的种种美好许诺，跨平台，分布式，易于开发维护等等，但J2EE的广泛普及，已经是一个不争的事实。虽然J2EE已经非常普及，但从技术上来讲，它本身还是存在很多缺陷的，比较突出的缺点，就是开发效率低，维护更加复杂，许多项目组都陷入其中不可自拔。

自互联网出现以来，企业应用系统的架构发生了很大的变化，C/S架构被废弃，B/S成为绝对的主流。但B/S架构本身，要比C/S复杂的多，加上新技术层出不穷，整个行业都处于巨大的困境之中。Web应用系统的开发，就像一座大山一样，把所有的人，无论是甲方还是乙方，无论是开发人员，维护人员还是系统用户，都被累垮了。

B/S系统本身的架构设计，要比C/S系统复杂很多，在C/S架构中，一般是两层结构（Client/Server）。一般在这种架构中，服务器是一个数据库服务器，只负责数据的存储和读取访问支持；前台程序采用VB，PB，Delphi等图形开发工具来开发，通过网络直接连接到后台的数据库服务器，通过发送SQL命令来实现数据库的访问。这种开发环境下可以使用图形化的控件来搭建用户界面，用户的交互性比较好。缺点在于应用程序发布在客户端，如果客户机数量很多的话，客户机程序的安装，升级都比较困难。而在B/S结构中，涉及到了多种服务器类型，Web服务器，App服务器，DB服务器。在B/S系统中，用户通过客户机上的浏览器来访问后台的Web服务器，Web服务器再把相应的请求转发给应用服务器来处理，应用服务器再将其中的数据访问请求转发给数据库服务器进行处理。

与C/S开发的一种语言包打天下不同，B/S系统的开发需要在多个层次上进行编程开发。在Web开发中，人们为了简化开发过程，提高效率，陆续发明了很多新技术，在页面开发上，基于JavaScript本身，发明了如prototype, jQuery, Ajax等框架；基于java技术，发明了J2EE架构，基于J2EE架构，又发明了Struts, WebWork, Spring, Hibernate ,Itabtis等无数的框架产品。结果在试图解决问题的同时，这些产品本身又造成了新的问题。

相对于C/S开发的单一开发工具开发，B/S开发要涉及到很多工具，语言和框架，这些工具，语言和框架，都是为了解决某一问题而设计的，而开发人员必须把这些目的不同的东西整合起来，才能搭建出一个整体的系统。
B/S的复杂度，很大程度上是由于涉及的技术面太多，太多的产品，太多的技术，太多的框架，这样不仅增加了学习的难度，增加了学习技术的成本，而且也增加了系统运行维护的成本，最终提高了整个系统的开发，运营成本。
这种高昂的成本让开发人员，维护人员，开发公司，和甲方都陷入了困境之中，大家在这一困境中挣扎，不能自拔。


开发人员的困境

在B/S系统的开发中，开发人员是最辛苦的一类人。用户的所有需求，都需要一行一行编写代码来实现，项目时间紧，加班加点干，最苦恼的是，要完成一个基本的功能，需要学习一大堆东西才能实现。HTML, JavaScript, Ajax, Jquery, Jsp, Servlet, EJB, Jdbc, Struts,Spring ,Hibernate,光是技术名词，恐怕一张纸都列不完。
开发人员面临的困境，就是技术本身在快速演化发展，不时有新名词，新概念出现，同时现有的技术也在快速演化之中，真是生也有涯，而知也无涯，感觉象夸父追日一样，每日不停的奔跑追赶，何日才是尽头啊。另外一个头疼的事情，就是技术架构的变化性，今天一个语言，明天一个语言，一旦底层的平台变了，自己费劲力气学会的东西就一文不值了，年龄一天一天大了，那里有那么多的精力老追赶新技术呢，于是很多人转行离开了。

但仔细想一想，所有这些架构，这些技术，真的那么必要吗？
为什么一定要忙于学习新的技术，而不是把精力用在用好现有的技术上呢？
为什么一定要受限于某种具体的语言和技术，而不是采用跨语言的解决方案呢？
为什么一出现新的技术，就把原来的代码全部推翻重写呢？
为什么要整天跟着新技术的脚步跑，而不沉思程序设计的哲学思想，厚积而薄发呢？

从某种程度上讲，Java世界里面这么多框架，产品，语言，很多都是这样的思路，试图解决问题，但同时创造出新的问题出来（大家可以回顾一下Struts1糟糕的设计，痛苦的调试，艰难的维护）。开发中用的产品，技术越多，系统就越复杂，光是学习这些技术，框架怎么使用，就把开发人员的时间和精力耗去大半，而究竟应该怎样来设计实现系统，已经没有人考虑了。时间和精力被无谓的消耗掉了。这才是开发人员最大的悲哀所在。
Web开发压垮的第一批人，是开发人员。压垮他们的，是系统的复杂性。


维护人员的困境

终于，在多次延期，多次修改，无数次补丁以后，系统终于上线了。现在轮到维护人员来面对这个庞然大物的系统了。
系统维护人员，对自己的工作，有一个形象的，不太雅观的比喻：擦屁股。
系统本身开发起来就复杂，使用起来也复杂，再加上开发过程中隐藏的错误，行业术语叫Bug，维护人员的电话一直没有停过，除了操作指导，就是错误报告，再加上误操作以后直接在后台数据库里面改数据，反正事情又多又杂，整天忙得不亦乐乎。
如果是开发人员自己来做维护，相对还好一点，至少里面是怎么回事情，大概知道个差不多，有了问题，小修小补打打补丁，虽然累点，总还是有希望的；如果不是自己开发的，要来做维护，那就要了老命了，要文档没文档，要注释没注释，还要面对同样多的技术架构，语言和技术平台，用维护人员的话说，就是如履薄冰，如临深渊，每天都在祈祷，这个系统别出问题。
从表面上看，是开发人员和维护人员之间的矛盾；从本质上看，是系统复杂度的矛盾。如果一个系统开发的很复杂，那么它本身就很难维护，即使勉强维护，维护的成本也很高。
如果你在系统里面用了10项技术，那么维护人员就必须学习10项技术才能进行维护；如果你在系统了写了10万行代码，那么维护人员就必须面对10万行代码。
当维护人员觉得系统已经无法支持下去时，他们会一走了之。而新来的人对于这个系统，工作的难度只有更高，更加难以胜任。
当一个系统无法维持正常的维护时，它的寿命也就到了。这时就会把它推掉，重新开始一个新的系统开发。不幸的是，新的系统一般来说会重复旧系统已经走过的路线，开发的更加复杂，更加难以维护，最后再次陷入无法维护的境界。

为什么系统变得难以维护，因为系统太复杂；
为什么维护人员无能为力，因为系统太复杂；
为什么维护成本居高不下，因为系统太复杂；
Web系统压垮的第二批人，是系统的维护人员，压垮他们的，还是系统的复杂性。

科技公司（乙方）的困境

和对个人的收益不同，系统复杂性，带给科技公司的，既有收益，也有风险。
系统复杂度的收益，就是客观上的跑马圈地，一件事情简单了，能做的人就多，竞争就激烈，最后就不好赚钱。CPU不是谁都能设计的，所以Intel发了；OS不是谁都能开发的，所以MS发了。把Web系统搞得很复杂，就会人为提高它的门槛，能做的公司少了，竞争就会少很多。早期的C/S阶段，把整个MIS系统搞得很简单，开发门槛太低，于是有一大堆的公司来做，最后大家都难以生存下去，现在的外包公司，也不需要公司有啥技术积累，于是有一大堆公司一起做，最后大家都挣不了钱。从这一方面来说，系统搞的复杂一些，对科技公司来说，客观上是有一定好处的。
最大的好处，是提供这种复杂性的基础设备的公司，例如Oracle, BEA, SUN, HP这些。以Oracle为例，每升级一个版本，就可以访问更快，存储更多，也就能卖更多钱。但问题是：究竟有什么必要在系统中存储那么多的信息呢？这些信息真的增长那么快吗？还是垃圾增长快呢？
基于这个原因，所有的基础设备提供商，都在不遗余力地推进系统的复杂性，今天一个标准，明天一个标准，如果有现成的标准，就把这个标准不断升级，让你跟着跑，整天疲于奔命，永远处在追赶之中。
最典型的例子就是Microsoft了，无论操作系统也好，Office也好，IE也好，反正三年必升级，强制性让你报废现在的东西。这就是基础设备提供商的生命所在，不断增加系统的复杂性。
对于具体的开发公司来说，系统的复杂性就是可怕的敌人了。系统越复杂，开发的成本就越高，维护成本也越高，如果客户不为这些来买单的话，开发公司就会做一个项目，赔一个项目，最后把公司赔光，关门拉倒。
在人月神话中，讲述了恐龙在泥沼中挣扎，挣扎的越厉害，险的越深；现在很多的开发公司也是一样，险在项目之中不能自拔，活儿越干越多，不知何日才是头，最后一算账，还不能挣钱。对于公司来讲，人力成本居高不下，所有人员被困在一个个项目中挣扎，公司永远长不大，变不强。
很多人会讲这个现象归咎于大环境和客户的不成熟。也许他们是对的。
但从深层次看，还是系统的复杂度问题，系统太复杂，以至于把开发公司的人力，物力，财力都消耗殆尽，根本无力发展。
在一个复杂度无法控制的状态下，公司只能是疲于奔命，随波逐流。

Web系统压垮的第三批人，是一个个开发公司，压垮他们的，还是系统的复杂性。

客户(甲方)的困境

Web系统的复杂性，依次打垮了开发人员，维护人员和开发公司，现在轮到甲方来承担它的后果了。
甲方的科技人员对于系统的复杂性，往往缺乏先见之明。所有的招标文件中，一律指出要保证技术的先进性，素不知，所谓的先进性，往往也意味着新技术，对于整个系统而言，往往是增加其复杂性，而不是减少其复杂性。
国内的甲方对于项目开发往往有个误区，喜欢按照人员的工作量，通常是人月来估算项目的费用，预算和成本。其实这是很不取的。很多时候只是盲目的要求增加人手，却不考虑到底有没有这么多工作需要人来做，或者做这件事情的时机是否成熟，是否合适。
在按人头计算费用的模式下，开发公司倾向于增加人手来提高整个项目的费用计算，而且最好是增加低成本的新手来做项目，这样做的结果就是整个项目陷入盲目运行的状态，所有的人都在忙，但不知道在忙啥，整体作的是无用功。很多时候把甲方的人员也拉了进来，包括业务人员和科技人员，大家一起瞎忙，一起浪费时间做无用功。
项目开发的种种问题，最后的恶劣后果，实际上都是由甲方来承担的。甲方既是项目的投资人，也是最终的使用者，如果项目不能达到目标，最终买单的是甲方。
项目的过程管理，时间管理这些都先不谈，单独谈谈项目的复杂性对甲方的长远影响。
首先是开发成本的失控，项目越复杂，开发的成本也越高，这些不必要的成本，或者说资源的浪费，最终是由甲方来买单的，开发公司最多不干了退出，甲方却退无可退，硬着头皮也要把项目做完。
其次是项目最终难以维护，正如上面所谈到的，系统越复杂，以后的维护就越困难。而更加要命的是，一个企业内部会有多个系统，这些系统分别由不同的开发商在不同时间按照不同的技术来开发，有的甚至已经换手几次。而甲方的科技部门要同时维护这样并行的多个系统，再考虑各个系统之间的交互关系，最后的结果就是焦头烂额，忙得不可开交。
从整体上来看，甲方对于信息技术可以说是又爱又恨，一方面，现在的企业运行离不开这些系统，另一方面，这些系统在带来便利的同时，又带来了无穷无尽的麻烦。每个系统的搭建费时费力，最后用不了几年就漏洞百出，不得不推倒重来。整个系统的建设在不断重复这一故事，直到下一个轮回开始。
有的甲方是家大业大，浪费点没啥，他们可能不太在乎系统建设时浪费的一点点资金，但对于系统运行带来的烦恼也是无可奈何。而有的甲方本身的底子就比较薄一些，这些系统建设上的浪费和失败就可能直接导致企业的巨大损失。行内有句名言，不上ERP是等死，上ERP是找死。说的就是这种现象。
甲方的困境，简单来说在于成本的投入和收益不成比例，由于系统的复杂性不断增加，甲方的投资被不断消耗在调合系统的复杂性上，而不能用在更有效益的地方。
现在的项目开发现状，使得很多甲方变成了一朝被蛇咬，十年怕井绳，对于后续项目的开发，早已失去了往日的激情和动力。
根本的矛盾，仍然在复杂度上，只有降低项目的复杂度，才是解决问题的根本途径。


原因分析

虽然在《人月神话》中，布鲁克斯已经指出：软件的复杂性是它的本质特性之一，但在实际工作中，人们往往容易忘记这一点。
软件的复杂性来源很多，但B/S系统的复杂性，又对C/S时代更有进步，尤其是J2EE的项目开发，其复杂性在不断增加。具体原因很多，但涉及的技术太多，是重要原因。
目前，B/S系统开发涉及的技术面太多，在界面展示，业务流程，数据操作等多方面，目前一般采用不同的技术方案，不同的框架，不同的产品来处理和实现。这些产品本身都是相对独立的，都构成一个自己的知识体系，而要把这些不同范畴的技术整合起来，使之成为一个统一的整体，光在技术层次上，就构成了一个非常复杂的系统。
一个系统涉及的内容越多，也就意味着出现错误的几率越大，这样一个系统也就更加不稳定。
而系统的价值，就在于它的稳定性，一个没有起码稳定性的系统，是不会产生价值的。

在传统的J2EE框架内，应用开发已经太过复杂，变得臃肿庞大，这一点业内已有定论。正是基于这个考虑，近年来出现了一些试图简化这一过程的产品和框架，例如Spring, Hibernate，都是这种思路的产物。
但不幸的是，诸如Spring, Hibernate这样的产品，在解决某一问题的同时，又往往带来更多的问题，只是用一个问题代替了另一个问题，从整个系统的角度来看，整体的复杂度不仅没有减少，反而有逐步增加的势头。开发人员现在需要学习的东西，不是更少了，而是更多了；工作不仅变得轻松，反而更加复杂，更加混乱，也更加没有生产力了。