几乎所有的研发人员或者项目管理者都认为文档很重要,但是那么多文档,哪些文档重要? 可能我们都会有不同认识..
但我们都有一个共识,就是严重的文档化,目前也行不通,研发人员几乎每天都在写文档,真正干活的时间就不多了,常常抱怨项目完不成.那么多少的文档量才是合适的呢?我想说,如果研发人员的文档水平很高,尤其是UML水平,那么做UML过程其实就是项目构架和简单编码的过程,UML完成之后,整个项目代码页完成80%,但我们常常更加习惯于直接写代码,而不习惯画UML,这是现实情况.因为它不能测试,无成就感吧.
严格的按照标准的软件工程流程来说,需求文档,概要设计文档,详细设计文档,测试文档等...在我所遇到和认识团队中,没有十分严格的完成过的,尤其是详细设计文档,虽然我以前也写过很多详细设计文档,但都与最终的实现差距很大,又不愿意耽误时间改文档,导致基本都作废了.下面是我对文档的观点
现在我认为,需求文档是最主要的, 首先,他指明了项目开发人员应该完成的功能点,要达到的目标,他能是我们快速了解整个系统功能..另外,需求文档相当于是客户与研发间的约定的,防止互相扯皮的可能...项目类型的公司,可以有专门的需求部门,负责写需求文档,研发人员只要看文档开发就OK了.
其次,概要设计文档,我认为这个文档主要记录项目的构架,各个功能实现遵守的规则就OK了...
最后,测试文档,功能复杂的软件中,每个测试点都要记录,防止出现某些功能不确定的情况,有些时候你会忘记某些功能是否实现了,与其查代码或者运行再试下,不如找测试文档.
那么详细设计文档呢?我个人认为作用最小.我建议采用规范代码的方法,尤其加强对注释的应用,我相信合格的程序猿能够看明白复杂的代码,即使没有注释也应该能够理解,加了注释后,应该更加没问题...如果加了注释的代码都看不懂,怎嘛改bug,怎嘛升级软件...注释不应该停留在函数或类功能的简单描述,要尽量详细,包括建立和修改时间的记录,本功能对其他功能的影响等.
要下班了,就这样了...