研发文档规范

凡事预则立，不预则废。

我很认可这句话。我们不能总低着头，向前冲。时不时地回头，看看我们走过的路。总结过去，是为了将来行进得更加有力。

今天在这里与大家聊一聊研发过程当中的文档规范。

首先说一下为什么要有文档规范，背景，

其次说说我们会从文档规范中得到什么意义；

最后说说我们怎么做好文档规范。

 

1）文档规范当前背景

 

话不多说，言归正传，先聊一下我们目前的现状，我们的文档输出是很少的，更多的时候，我们还是原始的作坊模式口耳相传。

当我们回头去分析一个问题，但对应的方案是几个月前大家口头商量出来的，没有形成文档。这个时候完全靠回忆。是很用时的。

作为一名研发工程师，我们承认更热忠于F5,F12,F9。文档这种晦涩的东西，我们往往不太喜欢看，也不愿写。这就是产生无文档化的主观原因。

 

 

 

 

 2）文档规范意义

a)当我们处理一个问题时，可以翻阅之前的文档，重新梳理，有助于解决当前的问题；

b)在方案形成时，落在纸上，形成文档。有助于对问题以及方案更深刻的认识。这样的方案也更靠谱。

 

3）文档规范怎么做

a)先说说文档目录结构，其实代码也是文档中的一种。代码与文档都是我们对外输出的成果。经过这些年的积累，我认为下面这个结构是比较好的。

 

 

b)接下来说说各种文档的定义

　　需求文档，这个是从用户那里拿到的，讲述用户想要一个什么的文档。这个文档描述用户遇到的问题所在，这个是问题描述文档。

      开发设计，这个主要是体现用什么技术方案解决用户的问题，技术如何实现，这个目录下面包含，我们的开发方案,功能列表，研发计划等

      开发测试，这个目录下面主要是针对上述功能开发测试人员输出的测试条件，测试用例以及测试报告。

      发布部署，这个目录里面主要是放模块间之系，发布依赖，端口列表，部署目录结构，配置说明等。

　　DBScript,这个用于存放开发过程当中的脚本

 

c)最后说说文档形式

    形式不重要，主要是内容。用白板，用纸画，拍照入库都行。

在时间充足的情况下，使用各种软件描述工具，如project, viso, x-mind等等更好。

 

最后，有了规范之后，你会发现事情越来越顺了。当然上面描述并非最佳实践。最佳的实践，是您感悟出来的。

不正确的地方，请指正。你的批评，让我更好的进步。