标签：包含 min 背景 研发工程师 实现 目录 工程师 测试用例 依赖
凡事预则立，不预则废。
我很认可这句话。我们不能总低着头，向前冲。时不时地回头，看看我们走过的路。总结过去，是为了将来行进得更加有力。
今天在这里与大家聊一聊研发过程当中的文档规范。
首先说一下为什么要有文档规范，背景，
其次说说我们会从文档规范中得到什么意义；
最后说说我们怎么做好文档规范。
1）文档规范当前背景
话不多说，言归正传，先聊一下我们目前的现状，我们的文档输出是很少的，更多的时候，我们还是原始的作坊模式口耳相传。
当我们回头去分析一个问题，但对应的方案是几个月前大家口头商量出来的，没有形成文档。这个时候完全靠回忆。是很用时的。
作为一名研发工程师，我们承认更热忠于F5,F12,F9。文档这种晦涩的东西，我们往往不太喜欢看，也不愿写。这就是产生无文档化的主观原因。
2）文档规范意义
a)当我们处理一个问题时，可以翻阅之前的文档，重新梳理，有助于解决当前的问题；
b)在方案形成时，落在纸上，形成文档。有助于对问题以及方案更深刻的认识。这样的方案也更靠谱。
3）文档规范怎么做
a)先说说文档目录结构，其实代码也是文档中的一种。代码与文档都是我们对外输出的成果。经过这些年的积累，我认为下面这个结构是比较好的。
b)接下来说说各种文档的定义
需求文档，这个是从用户那里拿到的，讲述用户想要一个什么的文档。这个文档描述用户遇到的问题所在，这个是问题描述文档。
开发设计，这个主要是体现用什么技术方案解决用户的问题，技术如何实现，这个目录下面包含，我们的开发方案,功能列表，研发计划等
开发测试，这个目录下面主要是针对上述功能开发测试人员输出的测试条件，测试用例以及测试报告。
发布部署，这个目录里面主要是放模块间之系，发布依赖，端口列表，部署目录结构，配置说明等。
DBScript,这个用于存放开发过程当中的脚本
c)最后说说文档形式
形式不重要，主要是内容。用白板，用纸画，拍照入库都行。
在时间充足的情况下，使用各种软件描述工具，如project, viso, x-mind等等更好。
最后，有了规范之后，你会发现事情越来越顺了。当然上面描述并非最佳实践。最佳的实践，是您感悟出来的。
不正确的地方，请指正。你的批评，让我更好的进步。
标签：包含 min 背景 研发工程师 实现 目录 工程师 测试用例 依赖
原文地址：https://www.cnblogs.com/xhu218/p/12427405.html
