管线项目今天告一段落.之后的开发要等用户的意见.
这几天,我也算忙得很.只能说瞎忙.现在我所处的位置很尴尬,可能所有公司里做开发的人都很尴尬吧.
我明显感到自己所获得的项目信息和我所涉及的开发范围是不对称的.
这种情况其实一直存在,只不过,现在把它提出来.组长自己掌握了所有的资料,但可我们得到的仅仅是其中的一小部分,而且往往材料之间很难形成统一的认识.
这几天,要做个初版给客户使用.因此维护量在加大.其中有一部分是重复维护的.即相同的代码,多处使用到.
当初,有复用的想法.不过由于对这个项目的了解不够.所以也没有十足的把握说统一抽象出对象来.(手头没有全面的资料是很难抽象出对象的.再加上整个项目也没有说要那样做).
但是不断加大的维护量,确实是比较日眼.
这几天,统筹管线这一部分,觉得局部抽象也不是不可以.只要作到合理,维护的量应该会降低30%.
那天看电视.马云这小子讲了句话,大概的意思是成功在于注重细节.且不管成功是啥玩意吧,至少注重细节是种不错的意识.
忙里偷闲也阅读了好多Blog上的见解.但总感觉大部分还是谈得比较大,比较宽,不够细致,看了之后不知所云.
今天,乘这个机会,也多说几句,给自己备忘备忘.
1.每次开始开发的时候,也是最糊涂的时候.客户需求模糊,从组长那里获得的项目信息也不全.在这种情况下,做全面的设计不太可能(其实,真正的情况是我当出头鸟,先做出个样子让组长看,不好再改.改到他满意为止).就我自己的体会来说,如果想稍微有点设计,最好只对当前页所设计的实体进行必要的抽离.(目前,这点还只是在设想中,感觉还不够成熟.不管那么多,过几天在新模块里尝试一下.其实也没那么危险.本来项目也不是很复杂.都是修修改改太多了.才把UI代码和业务逻辑搅在一起,乱套起来)
2.有些对象可能在多个子模块出现,且自称一体,有很好的内聚力.遇到这种情况,应立即抽象出来.举例来说,温州地区各县市经常以下拉框的形式提供选择.除此之外,各县市要有特定的编码.在这种类似的情况下,抽象出相应的类和UI控件.在这里有个不好的是,代码管理是个问题.如果是一个人开发,这问题到很简单.想怎么安排就怎么安排.现在基本上是两三个人一起做开发,往往互相之间是没有交流的.换个角度来说,代码风格也不一样.看来,必须是要有一个人主动点.
3.动态生成控件在自动刷新中,信息会丢失.(目前,大致用隐藏控件暂存状态.主要还是涉及到ViewState).能不能把动态生成控件,放在一个独立的对象里?这还是个想法.不知道通用性怎么样.
4.Js脚本使用逐渐增加.现在习惯上直接放在aspx文件.这里,可能还要细化一下.比如,一般只针对该页面的,可以放在aspx上.如果js比较多,还是单独写在.js文件里.
5.ajax的使用.最好统一.我目前使用的是propotype.js里封装好的ajax工具类.同事有的在用ajax.net或ajaxpro的.这个无形中,增加了复杂度;
6.团队开发,代码的统一性是必须的.公司现在没有用vss.所以,中间也出过老代码覆盖新代码的情况.没有vss,没有版本意识,很多工作都成了返类型.
7,数据库备份.管线项目的数据库,不仅结构在变,而且数据也会变.客户要求项目一开始就要从Excel导进一部分数据.数据导到数据库里,自然要处理好各表之间的关系.但是数据库的结构会随着客户的需求在变.所以数据库的这些即有数据也在变.一方面测试人员要对数据进行测试,另一方面还要拿原始的数据库打包给客户.但是组长那边没有那个意识去做备份.一旦测试人员搅乱数据库后,组长又开始要求我重新准备数据库.无奈,我又成了数据维护员.无奈,只好自己提前做备份.(按理来说,这个工作不是我做).总而言之,必须要有基线和里程碑.
8,沟通.这点很重要.但也是比较糟糕的.只能说有时候是无奈的.交流是双方的.但是当信息不同步或不对称时,肯定会有一方会不耐烦.
9.其实管线项目不复杂.但是,当你通过手头的资料无法了解组长他的意图和安排时,这无异于混水摸鱼.作为项目组长,起码的告知是必要的.或者说介绍各个模块的关系和功能是必要的.
