对开发过程中文档的一些想法

做软件开发也已经有6个年头了，最近总结了一下，针对文档这件事情，还真是有一些想法。不知道是不是对，只是自己看到的情况基本上就是这样。
1、要不要文档的争论    呆过两家公司，两个极端。     A公司的文档及其详尽和完整，而且能始终保持更新。好吧，基本上就是CMMI4的程度。 这样确实有好处：    ·项目的整个阶段都是受控的，基本上偏差不大，一旦出了问题之后，也能很容易回溯到最初出现问题的点上；    ·新人进来之后的上手速度相对也快，按部就班跟着各阶段的文档前进就可以；
   ·软件质量是有保障的，每个阶段都很好地执行PDCA的过程，都有记录都有认可；
   ·还有两个很重要的好处：一是能让人站在更高的角度来看软件开发，至少是可以跳出某一特定阶段(比如做概要设计文档时就要通盘考虑需求、技术、沟通等)，可以更全面的思考整个项目；二是怎样把事情说清楚又不冗余的能力，个人觉得软件开发中，这个能力很重要
   B公司呢基本上就是没有文档，所有的东西都在代码里面。一开始也觉得匪夷所思，但是时间长了思考一下，发现这也是没有办法的事情：跟这个行业相关。Ｂ公司的项目是产品主导的，并且竞争极其惨烈，时间就意味着生存，这种情况下迫使所有人放弃所谓正规的开发流程，全力突击，文档自然是被舍弃的。比如5天就要做出一款产品，你试试。。。。     所以，要不要文档不是靠书本知识甚至是经验就能判断的，很多时候还有很多的限制条件。个人觉得认真负责的软件开发人员特别是管理人员，应该综合考虑行业、经验、团队特性等裁量出合适的文档管理方法和流程。

2、对于文档的态度     这个东西说起来其实很主观，每个人都有自己的想法。个人觉得，其实很多人都是没有能够跳出一个既定的思维，而这个既定的思维是你呆过的对你影响最大的项目组给你的。
   具体说，我先在A公司做了4+年，这中间一直处于严苛的文档管理体系中，一直是这样在做的。所以，当离开A公司的时候觉得一切就应该是这样的，理所当然。进入B公司之后也想着用这样的方法去做，并试图影响别人。但慢慢的终于发现，这是不可能的。对B公司来说，现有的状态才是最合适的，其他都是格格不入的。
    这个时候该怎么办自己的看法：还是要裁量出最适合自己的方式，也就是调整自己的态度。在A公司形成的那些好习惯不能丢掉：比如详细笔记、先思考后操作、每天做计划和检查等等，这些还是可以实施的；但同时又要适应B公司的方式，习惯没有文档直接写代码(确实也提高了快速编码实现的能力)
    相反：假设我要是先在B公司做了4+年再去A公司呢人觉得这种情况会更难适应一些，毕竟人的惰性很能克服。原来在A公司的时候也确实有这样的同事。所以，大家还是要养成良好的习惯啊。
   要有时刻挑战自己习惯并不断裁量的良好心态。

3、不仅仅是文档的问题     文档的问题，归根结底是开发流程和规范的问题。
    良好且完整的开发流程，当然会对文档提出一定的要求，文档是不可或缺的，相差异的仅仅只是文档的覆盖度、精细度和规范程度而已。
    个人觉得，就算是像B公司这样的情况，也应该要由一些文档支撑，特别是软件框架设计相关的东西。是不是可以在项目完结的时候，项目组用总结会的方式整理一些文档呢者对Coding环节的要求更加严格一些，比如代码规范、比如注释规范，借助Doxygen等工具，生成代码说明性文档，这样对今后维护、新人介入等等都是有帮助的。

    好吧，乱七八糟说了一堆，总结起来就是一句：文档是需要的，但是需要根据实际环境进行相应裁量，同时，作为软件开发人员来说需要不断克服惰性、多思考，确定文档跟自己工作的关系。

来源：ploere