承接基于.Net的系统研发,精通物流系统,特别是仓储物流管理,有意者请联系。

让每一个项目都能给我们点什么


        每一个项目,不论成功还是失败,都将是一笔宝贵的财富,我们都可以从中学到很多的东西。成功给我们的是成功的经验,失败给我们的是避免同样失败的教训。不管怎么样,关键是进行项目总结,让每一个项目都能给我们点什么。  

       我就业后参加了一些项目,从小到大,从无序到有序。但每一个项目,不论大小,都会在项目结束进行总结,主要是限于设计和技术,找出在开发过程中的问题,每一次总结都感觉是一次收获。(自我感觉)

       刚开始的项目,因为并不是很大,而且参与项目的人通常就是一两个,谈不上设计,谈不上评审,引用大师的话就是“代码就是设计”。所以,项目的目标就是实现功能。再加上刚开始做项目,时间催的紧,没有经验,信心不足,导致畏首畏尾,所以从系统的设计到代码的实现都是惨不忍睹。所学的面向对象的知识,基本上只使用了封装和继承,面向对象的开发最后成了面向过程的开发。更可怕的是,因为没有抽象,很多功能类似又稍有不同的代码在项目中大量地存在着,有时候为了修改相同的部分,不得不找到所有出现的地方,一个个的修改,而且有时候这个地方修改后不清楚会不会影响其他地方。当时也考虑不了那么多,代码的可重用性及可维护性极差。幸好,项目相对比较小,功能需求相对稳定,所以改动的地方也不是很多,改动量也不大。最后,项目提交通过了。虽说项目改动比较少,但每次改动后都会涉及到主要流程控制的修改和调试,也是很烦的。

       经过这些小项目后,以及看了一些大师们设计方面的文章,开始有了软件设计的想法,最直接的感觉大量的重复代码造成了维护的困难,同时系统设计的好坏也影响着项目的重用和维护。那么,对这部分的代码需要进行重构,同一功能的实现项目中只能出现一个实现体,而不能出现多个类似的实现;还有就是需要将项目中通用的功能进行封装,比如加密、信件格式的转换等完全以进行封装成组件,以后所有的项目只要使用到这些功能都可以调用这些组件, 而不是每个项目都要去实现。这样不仅减小了维护的工作量,也提高了开发和维护的效率。

      于是,我将很多模块中都调用的功能模块封装起来,既包括了基础功能(如Socket通信)的封装,也包括了业务中常用的功能(如信件的转换)的封装。以后不论是项目,还是维护的项目,我都会使用这些封装的模块。当然,也只是最基础的代码复用。并且,项目中类似功能的方法尽量只出现在一个地方,就算有不同,也会抽象出共有部分的代码,减少维护的代码和降低出错的可能性。

      后来,开始接触相对较大的项目,不过还是一个人负责我那块的东西。根据以前积累的一些经验,实现基本的代码重用。好了,项目功能并没有花多长时间实现了,自我感觉还可以吧,至少功能实现了,而且功能也进行了封装。(呵呵,目光短浅啊。) 但是,随着项目的增加,需求的变化和新增几率也随着增大。修改功能还好说,只是修改功能方法,不会涉及到其他地方。但是如果是新增功能,那就要从界面控制、配置文件修改,到主要业务控制,到功能函数的实现,都需要新增,改动涉及的地方也是很多啊。刚开始感觉这样维护无所谓,后来发现很麻烦,老是这么改,一改就改了个遍,何时才算结束啊。就算需求变动没完没了,那能不能每次的改动不这么大呢。在公司,没有人带,更没有人指方向,全都靠自己去摸索,想了一些方法,都不怎么爽,这个过程花了很长时间。

     工作一年后,在一次与一个刚进公司的同事的交谈中,我提出了我的困惑,同事给我介绍了设计模式。于是,从网上查了一些资料,因为设计层次和理解水平没有到一定的高度,读完后都没能理解。最后,因为读的很费劲,而且一个更大的项目来了,所以,只能暂时搁置了。后来的两年,也就是设计模式的学习过程了,学习的精力在项目的压力中一点点的消磨,学的那是个苦啊。不过还好,从刚开始接触设计模式的痛苦,到现在设计中都尝试着使用设计模式,感受着设计模式在设计中带来的震撼。(不过还是菜鸟)

     我要感谢那位同事,是他让我了解了设计模式。同时,也要感谢所经历过的每一个项目。是它们给了我经验和教训,让我慢慢地成长。还是那句话:让每一个项目都能给我们点什么!

      时间仓促,文笔又差,写的比较短浅,见谅。

posted @ 2006-10-30 17:34  阿修罗一平  阅读(1512)  评论(7编辑  收藏  举报