几年的工作中,经历了2个几十号人以上的大项目.深深体会了,一个好的框架对项目的成成败是多么重要的. 尤其是我上一个项目.做的是一个国内顶尖的医疗公司的一个门户项目.当时由于项目的时间比较紧,没有过多时间去考虑和研究框架.于是就简单引进公司的另外一个框架,到最后的2年多使用时间,就逐渐感觉到了那框架的弊端.到后面项目中的很多同事都反映,该框架不但没有提高效率,而且严重阻碍项目的进度.结果也恰恰证明了这一点.使得我们中的很多开发进度,都是严重推迟了.

当然,一个项目的成败有很多因素.因为我是搞技术的,我想我还是分析一下技术方面的原因吧:

1,一开始时定项目时,由于时间的因素.没有过多的考虑和研究框架.这也是我感觉到的普遍一个项目类型公司的悲哀.一开始为了拿项目, 过多答应客户要求.其实自己并没有那么大的实力去做那事情.当问题出现了,想的解决方法往往都是一些短期的解决方案.以致导致很多该做的事情没做,俗称”欠债”.我们当时引框架也是,由于前面做的工作有点延误了,所以为了给客户交付一个漂亮的项目进度报表.于是把这么重要的框架选型时间也压缩了.而且我们当时公司的框架也比较乱.基本一个项目一个框架.没有成熟的框架. 所以当我们引了别的项目的框架,也没有过多去验证该框架.结果到最后才发现那框架根本适合我们的需求.然而发现了问题,本该要及时纠正. 但由于自己公司,不可能去承担这更改框架的成本,而且客户也不可能去承担.所以到后面就将错就错,不断去用错的框架去做.这样也导致后面的问题越来越多,到最后只能让一些技术好的同事,就当救火队员,采取头疼医头,脚疼医脚的方式去解决当前问题. 可是纸终究是包不住火的,当问题不断出现后,项目经理顶不住了,就只好换项目经理的方式去解决了. 还好,到最后客户也实在无法忍受了,终于愿意自己掏钱成立一个架构优化组,专门去处理相关的架构问题了.

2.我们当时的项目的主要技术问题有,

一,框架没有很好的支持多表查询.

二.框架的底层报错机制不好,动不动就报未将对象引用的错误.或者一些看不懂的错误提示,导致开发人员要通过调试才能找到问题的原因.

三.底层架构,存在很多性能低下,不稳定的代码.

3.我们没有很好的执行当前定下的开发规范.一开始有做coder review工作.可是做了几次后,就再也没去做了.这样导致后面的开发很乱.很多人为了贪求方便,写代码都copy 粘贴的方式.而且的代码的耦合度非常高,经常改一个问题,又会带来了其他问题.而且同样一个问题,有的地方改好了,有的地方又没改好.

4.技术好的人,往往是用来做救护队的队员.没有充分发挥好他们的作用.其实我们做的工作更多是要有前瞻性.我们要把问题,扼杀在摇篮里.

俗话说经验是宝贵的财务.作为一个架构师,我必须好好总结我这2年多的项目经验.同时我也希望我把这项目经验跟大家好好分享.共同探讨如何做好一个大项目. 接下来,我分别会向大家介绍我自己总结出来的东西.

一、,如何选框架

二、单点登录

三、缓存组件开发

四、夸域选用户和部门.

五、权限设计

六、流程平台的设计

七、移动应用框架.