看了标题,估计有些同学会想,这个文章是不是写一下具体怎么写文档,怎么开头,怎么组织语言,又怎么结尾,采用什么样的格式。非也,非也,真非也。具体怎么写文档真不擅长哦。每次都是赶鸭子上架。而且写出来文档也不咋地。
昨天某个同事问我一个什么什么文档,该怎么写?看了一眼,非常惭愧,不会。也没有类似的经验。虽然不会,但是装还是装一下的,所以问他这个谁让你写的,有没有给你个模板啊?他说模板倒是给了,但是套不上啊,于是乎看了一眼模板,虽然继续看不懂,但是我决定继续装,我说你首先把模板中主题词A全部替换成主题词B。然后修改一下文档标题,格式,作者以及时间就可以了。这个这个,好像有点惭愧,是不是糊弄啊?确实是在糊弄,因为不会写,也没时间去研究,但是又不得不写。因此只好出此下策了。
说到写文档,众所周知,程序员大都不喜欢也不愿意写文档,相对来说,他们更喜欢也更写代码。其实不愿意写主要还是因为不会。如果所需要的文档,有类似模板,还有相关的资料,我相信他们都会愿意写,甚至喜欢写。人其实都差不多的,每个人都愿意做自己熟悉的事情,做自己擅长的事情。反过来也一样,人如果遇到自己不会的事情,不擅长的事情,总会想到如何逃避,如何拒绝。会去找各种理由拒绝。表面上看,拒绝的理由千万条。不管拒绝的理由合理也好,不合理也会好,其实原因往往就一个,那就是不会。
记得刚开始做程序员的时候,每当项目做得差不多的时候,领导总是让大家补充相关一些相关的技术说明文档,当时感觉不知道怎么写,似乎没啥可写的。所有的算法,所有的业务逻辑不都在代码里面嘛。还写什么技术文档哦,这不是画蛇添足嘛。所以极其不愿意写,但是又没办法,不得不写,只好硬着头皮写。结果往往是写那么几页或者十几页,实在觉得没啥好写的,就给交上去了,结果又往往被退回来,原因只有一个就是页数太少,不够详细。记得当时有个领导就说了,不管怎么样,你们就得多写啊,干了的,没干的,相关的,不相关的都给写上去好了。当时的那种感受哦,非常的不理解。为什么了?这么不是强人所难嘛,写这么多干啥啊?有啥用啊?写了又有谁去看了。
后来慢慢的,写多了,积累的东西多了,可抄的内容多了,需要的写的文档更为规范了,明显感觉轻松多了。个人觉得,一个项目下来,写个工作任务书,需求文档,概要设计,用户手册,如果项目上没有特殊要求,基本上就够了。
记得某一年。有个项目几乎做完了,其实已经交付客户使用了。项目上的事情感觉都完事了。当时大家都是一种胜利在望的感觉,就好像到点了,该下班了,只等拎包走人了。却突然有人跟我说,项目上还缺一个详细设计文档,而且下午就得要。如果不给出来,麻烦大了,整个项目都得延期验收了。这个责任是没人担得起的。不过还好,审核文档的人其实是不懂技术的,是我,是我,急中生智了一把,把概要设计文档改了个名。不过,反过来说,审核文档的人如果懂技术,那就未必会纠结有什么文档,缺什么文档了。哎,谁在项目上不想认真,努力做好每一件事情,不想处理好每一个细节了。谁说不是了,细节决定成败嘛。
还有一次,同样非常惭愧,又是我,不过这个不是临时起意,因为我们的项目是没有做单元测试的,但是测试主管一直纠着说,你们缺少单元测试文档。既然都没有做单元测试,哪来的相关单元测试文档哦。只好一直期望着到最后一刻,放我们一马。也不知道人家是怎么想的,反正最后的结果是我们成了阿娇,图样图森破。实在没有办法,网上找来一个相关主题的文档,改了个名,提交了,反正谁也不认识谁。你好我好大家好。
拉拉杂杂,写了这么多了,感觉讲了两个关于写文档的故事,最后总结一下,说一下自己的观点,自认为还是有用的哦。文档这个必须有,但是我们一定要明白,这个文档写给谁,写什么内容,尽可能有的放矢,看的人需要什么,写的人就给什么。而不要那些套话,空话,废话。说实话,大大小小的文档看过没有几百个,也有几千个乐。但是往往都是大段大段套话、空话、废话。彷佛是文档页数在决定文档的质量。这个问题嘛,似乎不好解甚至无解。