奔跑的蜗牛

in silence.....
posts - 1,  comments - 0,  trackbacks - 0

先简单描述下项目情况。

 

该系统是基于share point 做的内部系统支撑平台,自己做的 WF 引擎,据说是一帮人做了1年多,然后接下来的好几个系统,都是基于此平台上进行开发。

 接手的项目亦是基于此平台,2个已经做完,一个正在开发中。

 


 

 再说下其他同事对此平台的看法:

 

1: 交接的同事给我告诉我:“最好不要再研究这个平台了,说不定等你研究透了,它也该换了” 。听完立刻石化..... 

2:其他team的同事给我说,你们那个平台运行好慢,搭载在上面的系统运行都很慢.

 


 抱着“风萧萧兮易水寒,.......”的决心,花了2周的时间看相关的代码,趁热打铁,记下当前的心情:

 

1:开发时缺少沟通交流,代码风格迥异,水平参差不齐,例如:项目用了JQ,但一些JS文件里,有部分是JQ代码,但另外部分又没有用JQ.囧.

2:平台提供的common的东西不够,导致每个系统有不少重复的东西,而且估计大家态度都比较消极,写的东西看这蛮累的.(PS:不排除写代码的人技术很牛B,锅看不懂)

3:用的新技术不少,而且还有些SAP的东东,倒回1-2年,用WCF,EF,postsharep等这些在生产环境中搞,胆子还是蛮大的,还有些这样插件,那样插件的,so.维护成本比较高,这些东西,我都是边学边看.

4:这是个所有接手项目的人都头痛的问题, 此平台系统,无文档,大部分代码无注释,还好搭载在上面的系统都是有文档的,不然我就真的“壮士一去兮不复返"了.

5:还有就是调试相当麻烦,不像常规项目那样直接F5就可以调试了,要想跨页面的调试,需要copy工程,该东西,附加进程...等等...总之,我搞这个调试的环境,都搞了一天多, 曾经因为一个错误搞了1天,错误是因为调用某个WCF出错,最后发现居然是某个工程的dll不是最新的引起的...当时我就抓狂了.....

6:平台用了大量的接口,基类继承,设计模式这些,命名和工程建立也是千奇百怪,看的我眼花,这些真的全部都有必要吗?

 

 .....其他的,想到了在补充...

 


以下针对以上的问题简要的记录一些解决方法,稍后在继续完善:

 

 1: 这个问题我实在想不到好的办法去控制这个风险,照理说,项目周会每周要做,沟通交流肯定也强调过,但还是有问题,不理解。(不知道各位看官有啥办法不?)

曾经我看到代码某个地方,不明白,想问下当时为啥这样写。于是乎去问同事A,然后同事A让我去问同事B,同事B又让我去问同事C.....算了,锅自己慢慢看..就是多花点时间而已.

定期做code review,应该也算是个办法,不过说实话,这办法感觉挺水,以前公司也搞这个,项目时间一紧,大家都不愿意搞。

2:我认为初期考虑的不够,导致很多冗余,比如:前台的那些信息提示,验证,数据绑定。 最近筹划把mvc的modelbinder拿来强化一下弄成自己的东东.

3:个人对WCF的印象一直不太好,感觉老慢.个人觉得其实很多时候restful的东完全可以代替wcf.

4:代码注释,设计说明.....项目大了,没这些东西,太耗费维护的成本. 

5:以后要多适应用 VS自带的那个test工程....

6:这个问题不好说,无法了解他们当时的设计思路,不好评论,反正我看着挺累的,又不好调试,简直是在考验我的思维能力.

 


总结:此项目让我感觉是被人复杂化了,不知道是想玩玩这些技术的集合,还是展示自己技术的NB,还是其他什么的,总之,对于项目开发,我认为,设计就该是如何简化成本。扩展性,维护性,是和技术含量成反比的。还会带来很多风险。

 


因为保密的一些关系,无法贴出项目的相关情况,只好在这里边YY边说.

  此文目的仅记录心得体会,为日后项目做参考,如遇熟人,请勿对号入座.

 



posted on 2010-09-29 10:39 icyleaf 阅读(...) 评论(...) 编辑 收藏