项目文档管理的一些想法
我个人比较倾向于敏捷的方式，不赞同大而全的文档，因为那样的文档书写起来浪费时间，维护起来更浪费时间，更可怕的是没有持续更新导致文档与实际项目偏差很大的文档。所以我认为文档就是应该少而精，必须确保文档的持续更新才有价值，具体的细节让代码去说，当然代码本身要写的可读性高。 今天和项目管理人员讨论了一下，我觉得分为如下几种情况： 1. 正规立项的项目：那个当然要安装立项你当时承诺的给文档。我建议是 1）如果有需求分析阶段，那必须要出一个文档来记录这段时间的工作； 2）架构设计文档是必须的，因为在代码中是很难直观看到整体的系统设计； 3）概要设计、详细设计什么的我都不知道是想干什么，如果是说代码的具体实现，那就到代码中去看，没必要维护这个文档； 4）测试文档：这个比较尴尬，这个应该是测试人员编写的，但是我们现在的情况是自己测试，那么有测试就要有记录，把测试的预期、测试的结果、测试的结论要写清楚就行了，格式可以不限； 5）数据库设计文档：我个人认为这个写文档完全没意义，在架构设计中把数据库表结构的关联关系说明即可，工程目录下的db目录里面必须有当前版本的建表语句，这样就足够了。 6...
