软件文档究竟应该怎么写？写多细？要不要写？有很多不同的看法。有人认为文档应该完备和优雅，并且总是应该用作下一个阶段的驱动；有人认为文档是要写的，但不必区分文档性质，文档间的组织结构也无所谓；有人则认为文档除了浪费时间之外没有任何意义，尤其在中国这个以“中档质量低档价格”的营销环境下，文档只会影响快速交付，降低竞争力，最终让股东很不高兴。
我个人的观点是：
文档应该用作代码的 必要的、最小的冗余。也就是说，
1.文档是代码的冗余，因为文档里有的东西，代码里其实都有
2.
这个冗余是必要的，否则无法保障软件质量
3.
冗余应该是最小的，否则它会项目进度，并且让项目成员很不快乐
首先，文档里的东西代码里都有，这个不必说。
既然文档是冗余的东西，是不是应该去掉？ 如果项目成员能够牢记功能和代码的对应关系，并且能够飞速地扫描代码找到自己所需要的东西，那文档的确可以去掉；否则，还是应该把某些东西成文归档，记个笔记，尤其是需求文档，它是软件产品的最终参考，并且充当了需求人员和开发人员之间的契约，必须做的完备。
但是，中国的软件公司都有普遍现状：文档超乱！最主要的原因有：
1.项目太紧，没时间写
2.文档格式很臃肿，不想碰它
3.文档评审很麻烦
4.我习惯在编码的过程中把设计做好，不想先写文档
5.更新文档，有一种返工的感觉，超烦
所以，要尽量在质量和进度以及烦恼指数上达到平衡。我的建议是，只写“最小的”文档。它包括：
1.
文档工作量尽量地少。我只觉得三个文档是必须的：需求规格说明书，概要设计文档和测试用例。而且，概要设计文档没必要太细致。
2.
抛弃文档模板，只写有必要写的东西。现在很多设计文档里都喜欢把“需求背景”复述一便，换了我写一个“略”字带过
3.
确立开为人员作为文档的主导者，改了代码后自己迅速修改文档，由于自己熟悉文档，在评审时也可以与业务分析人员迅速沟通。
4.
完全可以在开发完成后再补充文档。你完全可以在快速编码的过程中通过调试实现最优设计，这种设计往往比预先的设计要少很多漏洞。
5.
文档不要再建副本。一个组织就一份文档，其版本通过版本工具来维护，不要用邮件发来发去，副本太多是引发混乱的前奏。