1.综合业务系统现状分析。

根据同事和用户的反应，综合业务系统主要存在以下问题●针对用户1.对业务挖掘不够深，系统只对传统的手工操作使用电脑替代而已，并没对业务进行挖掘，带来价值不深。

2.系统响应太慢（针对部分界面和不确定的时间）。

3.交互操作别扭，以及易用性不高●针对公司开发人员和维护人员1.维护及其麻烦，代码注释不清晰。

2.缺少统一规范，导致实现同一功能出现多种写法，不便于后来开发人员和维护人员的理解和重用。

3.对于可以重用的封装好的组件和代码，没用详细的文档说明和获取的统一渠道，不便于新来员工的沿用，造成程序开发的不统一和不一致。

2.结合当前技术如何改进.1)首先讨论下系统响应慢的原因：综合业务系统的程序架构大概如下图所示。

由于后台的持久层hibernate和事物处理层spring都是业界成熟技术，而且拥有大量的成功案例，这些技术是不会造成性能问题的，而后台业务逻辑类虽然是由程序员完成，但该类主要保证的是业务逻辑的正确性，也不会对性能带来很大的问题。

所以性能问题以及优化主要集中在dorado的前端，以及数据库的数据抓取。

Web前端性能优化手段：1.减少html/jsp文件的大小。

由于每次用户请求都需要重新从服务器上加载jsp/html文件，当该文件越庞大则下载和解析时间就会越多。

一般应该控制该文件在2000行以下，大概是100kb以下。

而公司在开发一些应用中并没有注意或者使用技术手段去避免这些问题，比如生产经营下的合同管理界面的jsp源代码大概是1万7千多行，文件大小大概是1.2MB ，解析和下载花掉的时间解析和初始化时间就要将近5秒钟（第一次访问），这还是内部网中使用，如果使用外网访问的话，下载时间会成倍的增加，这样会显得更慢。

技术解决方案：像上面类似的拥有大量逻辑应用的界面是完全可以用技术手段进行避免的。

观察该界面，其实用户点击时只需要显示一个table和几个按钮，再就是tabSet中的一个简单意见界面。

也就是这些控件必须是在初始化页面时一定要实现的控件。

而其他的控件就可以分布到不同的界面来进行实现，在使用时，通过ajax的异步加载或者重新请求来进行调用。

这样就可以将该页面的html源代码大大降低。

综合业务系统改造的时候，做过一个这样的示范，可以将速度提升1秒左右。

当时的项目经理认为1秒钟的性能不需要进行改动。

其实如果一个软件对秒级的性能都不考虑改进的话，该软件不慢也不行了。

2.将JS和CSS外链: 当用户第一次请求界面时，会向服务器请求外连接进来的js文件和css文件，下次再使用该界面时，就会判断缓存中是否存在该界面需要的外连接文件，如果浏览者已经下载并缓存了这个文件，那么再浏览该页面就不需要再进行下载了，也就是第一次浏览会感觉有点慢，下次就会省掉下载js和css文件时间。

所以当一个界面的js达到一定数量是（推荐是超过100行）就应该将js代码提取出来放到一个js文件中。

比如还是使用合同管理界面为例子。

Js的行数就达到了2千行如果将这些js提取到一个外链文件的话，就不需要每次请求都去下载这些代码。

从而太太提过用户多次使用时的用户体验。

也同时减小了合同管理界面的源代码，从而加速了合同管理界面的展示速度。

3.删除重复脚本：重复调用的代码浏览器并不会识别忽略，而是会再次运算一遍，这当然是大大的浪费。

其实出现重复代码的重要原因就是因为没用前台人员进行相应的封装而导致的。

在下面的如何封装中会进行详细的阐述。

4.延迟加载组件: 调查了下现在ERP部使用dorado开发的程序人，大部分都不知道什么叫ajax的异步和同步，在开发过程中几乎没人去采用异步加载和延迟加载来加载组件。

异步和延迟加载都是ajax的用来提升性能的亮点，反而公司的开发人员却一无所知。

当然会对性能带来一定损耗。

比如数据下拉，一般是在数据增加时采用，所以应该采用延迟加载来进行加载。

比如有多个数据来源的话，客户不会在登录一个界面时就关心所有的数据，对不是最重要和不是最先展示的数据就可以采用异步进行加载。

后台数据抓取端的性能优化：1．在使用新闻公告和部门公告时，都会认为速度慢.其实前段花费的时间并不多。

所以大部分时间都消耗在数据的抓取上。

由于新闻公告和部门公告在后台是对应为一个表，每次查询都是从几千条数据中，帅选出满足一定条件的记录。

这当然会有一定的性能消耗。

再加上查询时也没有建立索引。

解决方案：其实这种情况是可以从业务设计上完全避免的。

新闻公告讲的就是即时性和公共性。

试问下谁还关心2年前的甚至4年前的新闻，像这种情况应该为该表建立一个历史信息表，然后做个定时倒数据的程序。

定时把2到3年前的数据导入到另外一个历史表中。

如果有需要查询历史信息业务需求时就到历史信息表中查询。

这样既不影响业务需求，也能提升当前业务的性能，可乐而不为呢？2．hibernate是业界最流行的一种数据持久层。

为了提高对系统数据的重用性，提高系统的性能，hibernate提供了二级缓存。

只是二级缓存对程序开发人员的个人素质要求高了些，但并不能表示该技术不能使用，通过个人大量的验证，在许多场合使用该技术，是可以带来一定性能提升的。

3.如何减少维护难度。

综合业务系统的维护时相当复杂的，造成这局面的因素太多了。

有管理方面的，也有程序开发方面的，也用各种历史原因等等。

本人认为应该从下面方法来进行努力改善：1)对开发结构进行统一规范，并强制执行。

维护和新开发难是因为，没用规范导致，前台控件中到处是js代码，改动一个地方可能就影响到下一个功能的使用，加上js的调试困难，造成开发效率降低。

现在以新闻公告单表的CRUD为例子来阐述下应该怎么规范：首先我们来看下新闻公告界面。

其实就是个简单的增加，修改,删除,查询功能。

现在的开发模式：查询按钮中的代码是dataset_query.setValue("caption","");dataset_query.setValue("issuanceDate","");dataset_query.setValue("issuanceName","");subwindow_query.show(true,true);增加按钮中的代码是：//显示增加信息框button_query.style.display="none";button_add.style.display="none";button_mod.style.display="none";button_del.style.display="none";在此不一一列举了。

这种代码最大的弊端在于，该按钮跟业务逻辑的dataset强耦合在一起了，这样我们如果需要再开发部门公告时，我们把这些按钮copy过去，还需要找到每个按钮进行逐一的修改。

但如果我们制定出统一的开发规范，那就可以避免上面问题。

比如按钮中调用的事件必须是一个接口ButtonOperation中的方法，具体实现现在不关心。

查询按钮代码为：ButtonOperationFun.queryButtonFun()增加按钮的代码为：ButtonOperationFun.addButtonFun();修改按钮的代码为: ButtonOperationFun.modButtonFun();这样定义好后，再在一个js文件中来实现这些接口的具体实现。

var ButtonOperationFun={queryButtonFun:function(){……………………具体实现},addButtonFun:function(){……………………具体实现}}如果这样做了后，会带来几个好处●如果现在需要开发部门公告，由于该俩个界面的控件是一样，完成的功能也几乎差不多，我只需要把控件全部copy到这边，不需要找到每个控件去修改其中的内容。

只要修改相应的接口实现就可以了●如果现在要维护公司新闻公告界面，我们也不需要关心到底是怎么调用的，我们只需要找到相应的js文件修改对应的接口●再就是这样做的话，可以让开发人员一目了然的发现那些代码是重复使用多次，可以对代码进行抽象封装，从而减少重复代码的使用量●形成一套公司的开发规范，不会像现在每个程序员都写各自一套代码，只能各自维护各自的代码。

如果形成规范了，就会减少个别之间的差异与差距，从而有利于公司程序员的梯队的培养2)对现有代码进行必要的封装：上个星期受综合业务系统之托，为该项目写了个流程控制的封装，从使用效果来看还算不错。

以前是需要程序员花大量时间来写流程节点的使能控制,而现在只需要程序员做个配置文件，再写一句简单的调用就全部搞定。

带来的不仅仅是现在开发上的方便，而是对后来维护也方便了许多。

只需要根据需求修改相应的配置就达到修改目的。

再就是大大减少了源代码量，提高了相应的性能4.怎么提高用户的用户体验。

用户体验是一种纯主观的在用户使用一个产品（服务）的过程中建立起来的心理感受。

因为它是纯主观的，就带有一定的不确定因素。

个体差异也决定了每个用户的真实体验是无法通过其他途径来完全模拟或再现的。

但是对于一个界定明确的用户群体来讲，其用户体验的共性是能够经由良好设计的实验来达到的。

用综合业务系统的个人文件夹为例子：看上去给人一种凌乱不知道怎么操作的感觉。

现在业界个人文件夹的界面如下：这就是抓取了大部分用户的习惯性思维，由于大家习惯使用操作系统的文件夹了，把个人文件夹开发成这样，从用户体验和用户操作上都要方便多了。

再用任务计划为例子，俩年前业界大概跟我们公司的差不多但现在业界的已经更方便了，以前的是没办法进行跨天任务进行展示的，而现在业界的可以显示跨天任务，而且界面显得更大方美观了。

应该怎么来提高用户体验呢：1.适时为不同级别的用户进行设计。

由于登陆者处于企业不同角色，对信息的关心程度和侧重点不一样，所以界面的展示方式和展示内容应该根据不同角色进行展示，这样才能做到更好满足用户的需求。

而公司现在的做法却是为了减少软件管理麻烦和程序开发难度，在设计时把所有的视觉点都设计到一个界面上，不管是管理员进来还是老板进来看到的东西都是一样。

我认为这是不合理的。

以会议通知为例子：发布会议通知的人员关心的是谁看了该通知，谁还没看该通知。

而普通员工关心的是什么时候开会，开会内容是什么，并不关心谁看谁没看。

等。

像这样的我认为就不应该使用一个界面来满足所有人的需求，而是要分不同级别的人群来进行界面设计，才能做到各个用户群的体验的提升。

下图所示：就分管理员和普通员工以及历史信息关心者的视觉来进行设计。