新年已过几天，自己掐指一算，眨眼间工作快六载。时间过得真快，该静下心来对自己进行总结总结，反省反省了。

   作为程序员中的一员，鄙人对新技术、新方法有着狂热的激情，每天都希望自己多看一些资料和多编一些程序，有时自个颇以陶醉于比特世界而自鸣得意。但我们的生活毕竟不是单一的，我们毕竟要在团队中生活，要在“死亡之旅”项目中挣扎前行，在这之中对我造成折磨的一件事，那就是写文档。

   写文档，谁都会写，这句话没错。就像每个人都觉得自己可以当皇帝一样，但不见得就可以做个明君。

   每当项目中需要什么文档时，鄙人就三下五除二把它“拿下”了，自我感觉自己已经把该写的东西都写全了。但很多时候都是事与愿违，每当进行文档评审或别人参看文档时都会提很多意见，比如：
   1）文档没有体系结构
   2）前后不呼应
   3）没有层次
   4）...

   最严重的评论是“不知所云”，我拷，我可是花了整整一天时间，!@#$%^&。

   举个例子，有次领导让我写篇调查文档，针对xxx厂中的信息系统中存在的一些问题进行分析并提出改造方案。接到任务后，没经过仔细思考，就开始埋头写起：
   第一段列出了目前存在的所有信息系统，
      系统A
      系统B
      系统C
      系统D
      系统...
      系统Z

   第二段列出了它们存在的问题，
      问题a
      问题b
      问题c
      问题...
      问题z

   第三段进行了问题分析
   第四段给出了解决对策，
      对策1
      对策2
      对策3
      ...
      对策n

   在会上领导进行了委婉地批评，说文档就像流水账一样，不成体系，没有归纳，没有总结。其中的系统、问题和解决对策就像一盘散沙，给读者的阅读带来极大的困难。经过“批评指正”，我意识到一篇文档要写出结构、写出思路、写出层次，读者才会看下去，不然就像我原来写的文章那样，文档中一大堆信息，谁容易明白，可能时间长了自己也不明白。

   经过文档“重构”，我对问题进行了归纳和总结，比如：
   
   第一段中的信息系统，我根据功能级别把它分类成管理决策层（L4），生产管理层（L3），过程控制（L2），电器仪表层（L1），又根据建设时间把它分成了已建系统（又分成未改造和正申请改造）和在建系统。通过把信息分析，进行归纳之后，信息的理解和消化将变得轻松。

   对问题我也是依葫芦画瓢，把问题归纳成系统问题、兼容性、扩展性、管理方便性进行了说明。对解决方案进行了从重要性、操作性和阶段性进行了说明。

   经过“重构”，文档得到了领导的认可。自己在文档的编写方法有了一次小飞跃。

   写文档不难，写好文档不易。就像我们程序员的程序一样，一定要有好的体系结构，要善于利用设计模式以及惯用法等。对比于文档，我个人觉得，

      文档                                                      代码

   金字塔原理               <——>              体系结构

   归类、排比句           <——>              惯用法 

   许多程序设计中的思想都可以用于文档编写，比如：

   1）用例驱动，在文档编写中，我们可以关心文档的用户是谁，他们对这篇文档都有什么期望，...。
     
   2）以体系结构为中心，在文档编写中我们可以按照“金字塔原理”的思想为中心展开我们的编写工作。

   3）迭代和增量为过程，在文档编写中，我们可以增量进行编写工作，然后休息一下，把自己换成文档用户的角色通读一下文档，把不满之处记于纸上，然后在把修改意见放入下一轮迭代编写中。

   最后，以领导常说的一句话共勉，“凡事要用心”。不过我个人要再添一句，“到时需动脑”，:-)

   
（注：《金字塔原理》是一本关于写作的书，非常不错，值得拥有）