源代码组织方法随笔

如果一个软件的开发只涉及到一种语言,那么源代码管理相对会比较简单.按照不同的模块,直接划分成不同的文件夹就可以了.例如,C,可以把一个项目分成ModA,ModB,ModC等模块，然后再Mod?中分成h,src两类文件(夹)，在h目录下，可以再分成SubMod1，SubMod2等子模块，在src目录下同样也分成SubMod1,SubMod2等子模块或者也可以是其他子模块划分。

这样的组织方式，是针对一种语言来进行的，同时是一种以模块作为划分标准的方式。以模块作为划分标准有很直接的作用，就是能够使得开发人员之间的交流更加容易，因为模块的划分对应了功能的划分，这符合软件开发以功能为目的的本质。在这种情况下，模块之间的层次关系并没有直接的体现出来，而是需要有另外的系统定义和文档说明。

令我困惑的是多种开发语言下的组织方式。如果同时有C，C++，那我还是可以按照上述的组织方式。但是如果同时又有Java呢？

按照一般的想法，不同开发语言适用于不同方面的功能开发。例如Java适合于做多层应用架构下的中间服务层和客户访问层，这在B/S架构中发挥得淋漓尽致，J2EE架构就是一个很好的例子。而C/C++则更适合于基础层次的功能模块的开发，在多层应用架构中适合于做中间服务层，以及在驱动开发、硬件管理、网络通信等方面作为首选开发语言。这其中Windows、ACE、VxWorks等等都是很好的例子。可以看出，C/C++主要是面向功能的，而Java则是面向应用的。其他语言，如Tcl适合于自动测试的脚本编写等，Fortran适合于精确计算等。

在这种情况下，如果把不同语言的应用范围相互独立，让他们各自专心于一个模块设计，则完全可以按照上述的面向单个语言的组织方式。但是，如果同一个模块中涉及到不同的PL，例如C/C++和Java，那么显然上述适用于C/C++的方式将不能满足Java代码的管理需求。因为Java的源代码不分为h/src两类，只有.java文件。

在这种情况下，子模块与模块之间的文件夹层次关系很容易让人迷惑。其实现在我都迷糊了，我已经写不下去了。我对这种情况的解决方法，仍然是以模块作为主要划分标准。在最根部的模块中划分不同的语言。也就是说同一个模块中的所有子模块都是使用同一种PL开发的。