关于大项目文件的组织
坛主
第一种，我称为洋葱型，项目一层套一层，项目文件也层次不一
这种组织方式的弊端是不打开sln文件你不可能知道大概有多少project，各是干什么的，
其次，在实际使用中，包含文件的时候
../../这种会特别多，甚至多达3、4个，一个中
途加入的程序员很难搞清楚其中的相互关系，在一个项目中添加一个文件，要想包含
别的文件不切换出来用资源管理器仔细对比他们的对应关系是无法确定到底需要几个
../的
这种组织方式是我最不喜欢的
sln Folder
Project1 Folder
Project2 Folder
Module1 Folder
Module2 Folder
Project3 Folder
Module3
Project4 Folder
Module4
Module5
include
lib
第二种，我称为条理型，项目下所有文件在同一目录下，不同的项目并列在sln下面，
项目的依赖关系是在solution文件中指定的，这是我比较喜欢的方式。如果项目大到
几百个文件之多，堆在一起可能不太好，但是几百个文件肯定可以再细分成不同的
模块，不同的模块在project下建立自己的子目录，但是目录下面不再应该有子目录
sln Folder
Project1 Folder
Module1 Folder
Module2 Folder
Project2 Folder
Module3 Folder
Module4 Folder
Project3 Folder
include
lib
第三种，完整代码型，所有用到的头文件和库都跟着项目，包括第3方的库，
这样的好处是所有需要的东西全在一起了，依赖的库也可以在Project的属性
中指定，把任何一个Project目录拷贝到其他的位置，都可以编译，不依赖VS
环境中指定的路径。可惜这种方式有个致命的缺点，假设project2依赖project1，
如p2-1.cpp
包含了p1-1.h,而p1-1.h包含了自己的include下面的某一个.h文件(比如a.h)，
那么将会导致project2编译不能通过，因为找不到a.h。如果要达到完全的代码完整性，
此种方式必须保证所有的project对外公开的头文件不包含自己include下面的文件，
这个比较难做到。
sln Folder
Project1 Folder
include
lib
Module1
Module2
Project2 Folder
inlucde
lib
Module3
Module4