昨天写的序[经验与探索,J2EE,项目,开发,团队合作,编程思想系列博文起航序] ,今天有两位朋友指出文章的标题不太好,所以从今天起,系列文章标题改成了团队项目合作探索系列,英文名称为teamwork.

在我学生时代,我就没能分清项目与编码,那时认为,项目,就是编码,一个项目的大部分任务就是编码.而事实上,编码只是一个项目中的一部分,最小的那一部分.正规的项目就像一个刑事案件,总有一个过程,不可能直接就是结果.

我们项目确立之前,就应该是一个长期的立项过程,但是,作为技术开发来说,我们不讨论这个,我们从立项之后说起.从这一刻开始,一个项目基本上都是要经过这样的套路:需求调研==>需求分析==>需求文档==>概要分析==>概要设计==>概要设计文档==>功能模块划分==>分工==>代码开发==>开发过程中的单元测试==>开发结束,综合测试==>试运行==>正式交付==>维护.

但是实际过程中,我们往往不会严格遵循这种套路,而且,上面写的这个套路,也不是书本中以及网络上技术文章中提及的,而是我此刻想起的,本身也不是什么规范.

我们在开发过程中,其实,或大或小,都会淡化除编码之外的工作.因为,编码,让我们这些技术人员感到快乐和成就,但是,其它的东西,我想没有几个人会把这些当成一种高兴的事.

但是,不管如何,大家都会有这样一个大致的过程,也许我们前期只会随便写写需求与概要,并不是很规范,但是,我并不反对,因为,这些规范及流程也是为了更好的组织项目的开发,但是如果项目不够大,遵循这样的过程反而是一种负担.

简单点,我们归纳成这样的流程:需求及概要及分工==>项目编码开发及单元测试==>综合测试及试运行==>交付及维护

作为团队开发,第一个过程是很重要的,没有一个详细的文档(需求,概要,分工),团队合作会很艰难,除非有一个很强的英雄领导.

文档应该是活泼的,我认为只要包括了重点就行,不用太多言语.比如,它应该说明我们这个系统要做什么,把这个内容详细一点,就是需求了,然后,我们开发者认为这个系统应该做成什么样子(技术上,功能上,模块上),这就是概要,最后,我们有什么资源,我们如何分工及最大化利用已有的资源,这就是分工与合作.这个过程,如果做得够好,够详细,对后面的编码与团队合作很有帮助,所以,如果你有时间,还好还是在这个阶段上下点功能.

编码,是实现一个项目的基石,项目的好坏,直接的影响就是这个.我们一个学生刚刚进入项目中时,第一个要掌握的就是编码能力,但是,作为一个有经验的工程师,这就不再是他的重点了,他的重点更多的在于业务,以及技术框架上,及控制代码规范和质量,编码能力,只是他吃饭的工具,就像吃饭用筷子一样平常,如果他连这都不行了,那还能吃这碗饭吗?

编码,不仅仅是编码,我们要善于在日常的编码中进行总结与归纳,以及最终给自己做一系列的封装类.一个好的封装类(自己的),胜过千千万万行代码经验.

按我的经验及想法,总结出自己在项目开发中的各类代码,封装起来,作为一个util类库.另外在使用其它类库前,封装一个基类,这个基类去继承别人(或者开源)的类库,这样,便于在项目中统一控制这些类.将来如果需要更换别人的类库,你也许只要对你的这个基类进行少量的修改就可以了,而不必对每个使用了别人类库的地方都去修改.

对于经常重复的代码,应该适当的进行提取,封装,来提高代码质量及代码的复用性,在eclipse中还可以做成模板来使用.

而对于一些核心的,各项目可能都会拥有的模块或者功能,就应该在合适的时机提取出来,加以修改,配合适当的配置文件,做成一个独立的组件JAR包,以便在其它项目中使用,使用时,只需要修改相应的配置文件就可以进行强大的功能控制.

但是,有一个问题,以上讲到的是做为一个程序员尽量去做的事情,但是,在团队合作中,如果每一个人都按照自己的封装去做,那团队还如何合作得了呢.

所以,我们还应该继续探索团队合作.

Tags: 经验与探索  J2EE  项目  开发  团队合作  编程思想  teamwork  

原创文章如转载，请注明：转载自：巴士飞扬-技术BLOG : http://www.busfly.cn/

本文链接地址：http://www.busfly.cn/post/teamwork-01-Project-coding.html

如果你喜欢本文，请顶一下，支持我，你的支持是我继续发好文章的最大动力。谢谢。
好东西需要分享，快把本文发给你的朋友吧~!~