5，Publish。项目发布的目录。按照“时间+版本”的方式发布，我们的目标就是尽早的发布！注意发布中应该含有所有相关信息，包括程序（安装程序）、数据库脚本、帮助文档，甚至是刻录光盘的Autorun.Inf。

　　6，Ref。引用目录，里面放的是项目引用的第三方类库和相关的帮助文档等。

　　7，Solution。重要目录。这就是我们的解决方案所在的地方了！一般是按照版本建立解决访问。

　　8，Source。参考资料。可以是文档，图片，也可以是别人的产品，开源项目等。只要是对项目有参考价值的，都应该被捕捉。

　　9，Team。团队的公用文件夹。存放公用的信息，比如说成员的联系方式等。

　　10，Template。模版。一般指文档模版，即dot文件。目的是为了保证项目的文档都有一致、良好的格式。这点在对企业单位，特别是国有企业的项目中尤其重要。混乱的格式会给人不可靠的感觉，领导对此尤为敏感。

　　11，Tools。项目所用到的工具软件。比如说代码生成器等。

　　12，TryProject。每个项目都可能涉及到一些我们不太了解的技术，这就需要我们做一些尝试，这些尝试也应该保存下来，作为参考。我们可以建立一些TryProject进行实验。

　　以上就是我管理文档的方法。从文档的管理方法其实可以反映出很多项目的情况。一个良好的项目应该有良好的条理性。，具体展示出来的效果如图所示：

　　需要说明的是，这个图所展示出来的只是一个Demo。也是我为这篇文章所建立的。所有非常的小。真正的项目文件夹有几个G大小是很正常的。

　　2.4版本控制

　　任何项目都需要有版本控制，这是无可厚非的。版本控制就是个大型的Undo/Redo。保证你随时可以吃后悔药。

　　版本控制的概念不应该仅仅只是捕捉代码。所有和项目相关的数据都应该在被捕捉的范围内。这些数据通常包括：文档、设计、数据库（及脚本），发布过的二进制包。采集的资料等。这也是现在的版本控制软件发展的方向。

　　对于文档、设计等，其实前面的文档管理方法就是一种版本的控制方法。

　　对于代码，这个级别上的项目VSS无疑是最合适的选择。不管有没有第二个程序员，代码的版本控制都是有益无害的。

　　2.5其它方面

　　1， 数据库

　　数据库如果在团队项目中，一般是架设在专门的服务器上的，这样大家都可以根据同一个版本进行开发。不过数据库的修改就要比较谨慎。同时要建立好数据库备份计划。

　　如果能够分离数据层，或者采用ORM等框架，支持数据库类型的转换，那么采用Access进行开发，部属的时候采用Sql也是一个不错的选择，这样备份和转移的时候依然可以一个Copy搞定。

　　2、备份

　　由于文件都在一个目录中，所以备份文档就是把整个项目目录Copy以下，不过有的时候最好清理一下TestResults（单元测试结果）文件夹，再压缩一下Solution文件夹。如果使用了VSS，还要记得备份VSS的数据库。

　　以上的方法不一定是最好的，只是我在做项目的过程中总结的一些适合自身的技巧。希望对大家有帮助。也希望起到抛砖引玉的作用。