程序员如何写文档的故事

      看了标题，估计有些同学会想，这个文章是不是写一下具体怎么写文档，怎么开头，怎么组织语言，又怎么结尾，采用什么样的格式。非也，非也，真非也。具体怎么写文档真不擅长哦。每次都是赶鸭子上架。而且写出来文档也不咋地。      

      昨天某个同事问我一个什么什么文档，该怎么写？看了一眼，非常惭愧，不会。也没有类似的经验。虽然不会，但是装还是装一下的，所以问他这个谁让你写的，有没有给你个模板啊？他说模板倒是给了，但是套不上啊，于是乎看了一眼模板，虽然继续看不懂，但是我决定继续装，我说你首先把模板中主题词A全部替换成主题词B。然后修改一下文档标题，格式，作者以及时间就可以了。这个这个，好像有点惭愧，是不是糊弄啊？确实是在糊弄，因为不会写，也没时间去研究，但是又不得不写。因此只好出此下策了。

           说到写文档，众所周知，程序员大都不喜欢也不愿意写文档，相对来说，他们更喜欢也更写代码。其实不愿意写主要还是因为不会。如果所需要的文档，有类似模板，还有相关的资料，我相信他们都会愿意写，甚至喜欢写。人其实都差不多的，每个人都愿意做自己熟悉的事情，做自己擅长的事情。反过来也一样，人如果遇到自己不会的事情，不擅长的事情，总会想到如何逃避，如何拒绝。会去找各种理由拒绝。表面上看，拒绝的理由千万条。不管拒绝的理由合理也好，不合理也会好，其实原因往往就一个，那就是不会。

        记得刚开始做程序员的时候，每当项目做得差不多的时候，领导总是让大家补充相关一些相关的技术说明文档，当时感觉不知道怎么写，似乎没啥可写的。所有的算法，所有的业务逻辑不都在代码里面嘛。还写什么技术文档哦，这不是画蛇添足嘛。所以极其不愿意写，但是又没办法，不得不写，只好硬着头皮写。结果往往是写那么几页或者十几页，实在觉得没啥好写的，就给交上去了，结果又往往被退回来，原因只有一个就是页数太少，不够详细。记得当时有个领导就说了，不管怎么样，你们就得多写啊，干了的，没干的，相关的，不相关的都给写上去好了。当时的那种感受哦，非常的不理解。为什么了？这么不是强人所难嘛，写这么多干啥啊？有啥用啊？写了又有谁去看了。

      后来慢慢的，写多了，积累的东西多了，可抄的内容多了，需要的写的文档更为规范了，明显感觉轻松多了。个人觉得，一个项目下来，写个工作任务书，需求文档，概要设计，用户手册，如果项目上没有特殊要求，基本上就够了。

   记得某一年。有个项目几乎做完了，其实已经交付客户使用了。项目上的事情感觉都完事了。当时大家都是一种胜利在望的感觉，就好像到点了，该下班了，只等拎包走人了。却突然有人跟我说，项目上还缺一个详细设计文档，而且下午就得要。如果不给出来，麻烦大了，整个项目都得延期验收了。这个责任是没人担得起的。不过还好，审核文档的人其实是不懂技术的，是我，是我，急中生智了一把，把概要设计文档改了个名。不过，反过来说，审核文档的人如果懂技术，那就未必会纠结有什么文档，缺什么文档了。哎，谁在项目上不想认真，努力做好每一件事情，不想处理好每一个细节了。谁说不是了，细节决定成败嘛。

   还有一次，同样非常惭愧，又是我，不过这个不是临时起意，因为我们的项目是没有做单元测试的，但是测试主管一直纠着说，你们缺少单元测试文档。既然都没有做单元测试，哪来的相关单元测试文档哦。只好一直期望着到最后一刻，放我们一马。也不知道人家是怎么想的，反正最后的结果是我们成了阿娇，图样图森破。实在没有办法，网上找来一个相关主题的文档，改了个名，提交了，反正谁也不认识谁。你好我好大家好。

  拉拉杂杂，写了这么多了，感觉讲了两个关于写文档的故事，最后总结一下，说一下自己的观点，自认为还是有用的哦。文档这个必须有，但是我们一定要明白，这个文档写给谁，写什么内容，尽可能有的放矢，看的人需要什么，写的人就给什么。而不要那些套话，空话，废话。说实话，大大小小的文档看过没有几百个，也有几千个乐。但是往往都是大段大段套话、空话、废话。彷佛是文档页数在决定文档的质量。这个问题嘛，似乎不好解甚至无解。