前两天瞅个空，把WordPress的表全部看了一遍，大部分字段的用意基本清楚，有几个字段仅仅从字面上还无法得知其含义，而且已有数据里，那些字段里都是空白，无法猜测是何用，有些朋友说，这些可能是历史升级时为了向前兼容而保留下来的，对新安装的博客无任何作用，我暂且先不纠结这些。看完全部表结构后，惊奇的发现，几乎所有的表，里面的字段全部是必填项，只有那两个元信息表里有2个可为null的字段。...Wordpress的表设计的原则到底是怎样的呢？全部为not null有什么好处？可以为null又有什么好处？....

 在J2EE的代码生活上，不知不觉，就走了3年多了。一直在摸索，在前进，可是，在内心，不停的纠结着，我们真的需要这么多框架，这么多层次，这么多所谓的一套又一套理论吗。在我们的开发中，不停的集成添加更多框架，JAR包越来越多，几个，几十个，几M，几十M，甚至上百M。当初为啥要用这种那种的框架，为啥要引入这套那套理论，简单说，不就是为了开发更加方便，速度更加快捷，维护更加容易吗？但是，现在各种框架我们都有了，难道我们的开发真的就快捷了吗？我们的维护更加轻松了吗？我们的后期扩展更简单了吗？不，不是的，至少我感受到的不是这样的。而且我越来越模糊，Spring是什么，Ibatis是什么，Struts是什么，WebWork是什么。还有Hibernate，SiteMesh，Velocity，freemarker，Struts 标签，JSTL等等，太多了，多得让人眼花缭乱。我们要用Spring，为什么，他的特性是什么，原理是什么？

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

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

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

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

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

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

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

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

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