java工程目录结构按排研究

做软件开发都会遇到此问题,不光是java开发中会遇到此问题,现代软件的开发通常采用某种集成开发环境以提高开发的效率,不管理是VC++还是delphi,还将现在比较流行的eclipse这种开发环境通常都会有一个所谓的workspace的根念,其下为多个工程,在每个工程下会有一个一个的文件或文件夹,这些文件以及文件夹的组织怎么才算合理,没有一个固定的说法,下面结合eclipse做java开发源代码包的组织做一些研究,当然每个人的习惯不一样,我总结的这些组织结构不一定也适合你的情况,不可以参考一下:

项目	子系统	版本	性质分类	业务分类	功能分类	类型	包
XXX	xxx_1	trunk	src	m1	main	java	com.gsm.xxx
						resource	com.gsm.xxx
					test	java	com.gsm.xxx
						resource	com.gsm.xxx
		branchs	src	m1	main	java	com.gsm.xxx
						resource	com.gsm.xxx
					test	java	com.gsm.xxx
						resource	com.gsm.xxx
		tags
	xxx_2	trunk	app	core	main	java
						resource
					test	java
						resource
		branchs
		tags

上面的这个设计是结合了svn服务器管理的目录结构,上面的第一列项目并不是对应eclipse中的一个项目,它与商务谈判或平常所说的项目或系统更接近,而与eclipse工程中对应的实际是子系统,但也不完全对,因为它们只是逻辑上对应,真正与项目对应的是truck或者branches,tags等版本后的某个文件夹,是对应的,后面的性质分类,是一个较大分,通常可以不分默认为src;后面的业务分类也可以称为模块,其实这里可以根据需要分多个级另,具体可以看情况,最后一个是功能分类,这里功能分并不是业务功能的意思,更多是指一个技术范畴的分类,通常可以取main(主要功能代码),test(测试功能代码),base(基础支持代码),这里的划分也可以在包中进行比如com.gsm.xxx.base,但是如果你基于某种原因希望代码在源文件级别上进行物理隔离,就可以在这个层次上做.

以上就是我个人在实践中的一点点心得.