关于开发模式的文章实在太多了,多得让人越看越糊涂.到谷歌里随便一搜索,就能找出成千上万的文章.

那开发模式到底是什么,这样题目很难回答,因为他是抽象的,但是原理是明确的,我来讲个示例:

现在,我需要在A 类中引用B类,请问我们应该如何做呢,在C++与Java中有什么差别.

天啊,这么简单的问题,没错,确实很简单,一般我们的做法,如同C++一样,如图:

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

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

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

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

经验与探索,J2EE,项目,开发,团队合作,编程思想,这系列博文将主要是以团队合作开发为出发点,涉及到团队如何合作,团队合作如何达到资源最大限度的利用及共享以及对项目开发的模式,思想等的探索.与此系列文章编写的同时,也将同步整理项目开发资源,以要以整理出一个核心项目,将溶合一些项目开发中的通用资源,开发文档,类封装,以及项目设计和团队合作理念(应该说是我个人的),等等,使得后期其它项目在之上进行开发时达到最大的便利,甚至达到只需要做业务设计,而不必为各种JAVA基类方法而费事.这个项目暂时命名为TeamWork