我为什么反对在实际项目中使用类似ext的js技术框架

 

      最近一个项目在加紧实施，项目组中包含我在内都是新人，对于业务来说基本不懂，项目一期的交付时间是6月1日，在实施计划中留给编码和测试的时间仅是一个月，大体的功能模块在30个左右。

      目前整个项目组有9个在做基本业务模块的开发，公司原先懂业务的开发人员基本都散啦。

 

      在项目软件实施技术框架上，项目经理提出使用dojo来完成表示层的展现。 java后台处理使用ssi框架整合，我主要承担核心架构的建立或某个业务系统的设计，对于dojo来说我了解基本是0，但大体看完介绍和demo，总体感觉就是类似ext的js技术框架，项目内的其他人员，除项目经理外没一个人用过，但是具体没说明在什么项目中使用；对于ssi技术，总体熟悉的程度在70%。

 

对于前台的dojo展现使用部分我很是担心，经过多次和项目经理总是无果，其坚决程度堪称罕见。我之所以坚决反对使用dojo，原因有如下：

1. 总体项目组对dojo根本就是从零开始，前期必然大大的延迟开发进度和上手阶梯；

2. 项目编码+调试的时间仅为一个月，当前系统仅是v1.0，也是能否长期抓住客户的关键所在，如果客户不能对当前这个版本的有个基本的满意度，其后期的二期和其他基本就是泡汤；

3. 类似ext，dojo等js技术框架，外部看来很是方便和适用，但仔细研究发现，如果真正要在项目中用好，必须具备必要的条件，至于是什么，我先卖个关子，下面去具体分析；

4. 如果引入ext等框架，由于其各组件和其内核的紧耦合性，必然造成可扩展、可维护性较差，如果不能详细了解其内部的原理，必然造成开发过程和系统维护性的重大投入；

5。客户的个性化要求，根本不能很快的响应和修改，究根到底还是需要彻底地了解其框架的内核；

6. js调试和bug定位、跟踪之繁琐，软件开发人员都是感同身受的。据我知道的ie的js调试器和定位bug位置，visual studio可完成对js的单步调试；

7. 虽然ext这样的框架都是开源的，但其js代码都是经过混淆的，我曾找过很多js客户的工具，但是基本上达到的效果仅为80%左右，要读懂也不是一朝一夕的事情；

8. 如果存在浏览器版本的兼容性问题，那将是灾难性的，不说其他的，光IE不同版本的兼容都是累死人不可遇见的；

 

基于以上原因我得出，不要被其五花八门的demo混乱你的脑子和编程思想，如果说做web程序可以经过组件式的组合而完成其程序的编写，那我劝君不要妄想，如果是这样那高中，中专或者没有学历的也能生产很好的程序，可能很多人反对我说，很多技术牛人出身本就是高中生，中专生，但我想问下，有几个这样的人，在北京，上海，广州，深圳这样的软件相对密集的地方有几家公司找软件工程师要求学历是高中、中专即可。

 

回到我们项目组来，为什么项目经理一直坚持使用dojo，在和他交流的过程我得出以下结论：

1. 他对于web程序了解度根本就是门外汉，因为他总是想当然地认为，使用dojo这样的组件来组合一个基本的页面，可以很好的统一整个系统的风格，开发过程中仅需要在后天定义接口或方法通过组件需要的数据格式，就可以完成对模块的编写，但他忽视了一点，如果程序员一味的依赖与js框架中提供的API来指导你的后台来完成数据的组合，那我想问下，web程序都是居于页面的开发吗？那为什么我们还需要spring,hibernate,structs,ibatis这样的解决方案来完成数据的存储和逻辑判断尼，直接在jsp中嵌入<=%%><%%>完成即可，这样我们可以更加省掉dao/service/action甚者ioc、aop这样的东东？

 

2. 由于当前公司今年存在很大的人员变动，当前项目组成员基本上都是新人组合，包含项目经理也是，当前整个项目的成败或实施效果就是公司对全体项目组成员肯定的过程，所以他希望使用一些自己的东西来证明自己，但现在最大的瓶颈就是他本身对dojo也是个门外汉，可悲可叹。

 

我可预见的项目开发过程

 

编码过程中整个项目组面临的巨大的阻碍：

 如果以现有的模式就绪进行后期代码编写过程必然是进度的严重滞后，这还是理想的情况，如果碰见某个关联的js语法错误那将是杯具中的杯具；

 

项目上线后的可维护性：

即使项目成功上线，我们很可能被客户的个性化需求繁死，其修改任务的巨大将是不可遇见，当然能做到修改也是一个理想，非理想就是无从下手修改；

 

编码过程中的持续性加班：

由于前期的熟悉过程和阶梯必然造成开发进度的严重滞后，其最终的结果就是程序员的家常菜——加班。。。。

 

项目最终结果：

如果当前使用js框架和后天整合性好，项目组成员内很快上手，项目在加班后紧凑上线，内我们算是成功的；如果涉及修改的东西多或者某些js文件的错误爆发，客户的个性化需要频繁，那最终可能已失败而告终，那整个项目组的新人们必然继续徘徊在试用期或者淘汰出局的局面。。。

 

就以上问题，我是多次和项目经理进行过交涉，结果都是无功而返，无奈啊。。。。。。。。。

 

 

上面我卖了个关子，说什么样的情况下时候使用ext等js框架技术来作为系统开发，我得出如下：

1.有足够内力、精力的人员来负责对其js整个框架的深入了解，使用；

2.有良好的js调试技术；

3.有很好的js优化能力，大伙都知道，光ext中其数据装载方式就存在很多（xml、json、file），如果在系统中使用，必然仅使用一种模式来完成，那其他方式就需要屏蔽或者砍掉以减少其js文件的大小来加快业务加载速度；

4.项目组有优秀的美工成员，同样ext中存在很多皮肤样式的种类，在系统中也同样仅使用一种，其样式文件的优化也需要美工成员来配合完成，以降低样式文件的大小；

5.最后一点不限于使用js框架，在系统开发中使用任何技术框架都需要一个严格的讨论和技术评审，全面、充分的对其稳定性、效率性进行测试，用数据来说话，而不是局限于看到说ext封装了个tree/datawindow等：好看，使用简单，如果是这样，你的项目必要在开放过程中将如履薄冰————不知道真正的陷阱在哪里；也不知道如何正确逃离困境。

 

（我以前也当个项目经理，所以能想到这些问题，当然可能我的认识还很肤浅，有不妥处请大家指正）

写的差不多啦，今天出去玩啦，很累，要休息啦，下次想到其他的再写啦。。。。。。。。。