做软件开发都会遇到此问题,不光是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,但是如果你基于某种原因希望代码在源文件级别上进行物理隔离,就可以在这个层次上做.
以上就是我个人在实践中的一点点心得.
