新年已过几天，自己掐指一算，眨眼间工作快六载。时间过得真快，该静下心来对自己进行总结总结，反省反省了。
作为程序员中的一员，鄙人对新技术、新方法有着狂热的激情，每天都希望自己多看一些资料和多编一些程序，有时自个颇以陶醉于比特世界而自鸣得意。但我们的生活毕竟不是单一的，我们毕竟要在团队中生活，要在“死亡之旅”项目中挣扎前行，在这之中对我造成折磨的一件事，那就是写文档。
写文档，谁都会写，这句话没错。就像每个人都觉得自己可以当皇帝一样，但不见得就可以做个明君。
每当项目中需要什么文档时，鄙人就三下五除二把它“拿下”了，自我感觉自己已经把该写的东西都写全了。但很多时候都是事与愿违，每当进行文档评审或别人参看文档时都会提很多意见，比如：
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）迭代和增量为过程，在文档编写中，我们可以增量进行编写工作，然后休息一下，把自己换成文档用户的角色通读一下文档，把不满之处记于纸上，然后在把修改意见放入下一轮迭代编写中。
最后，以领导常说的一句话共勉，“凡事要用心”。不过我个人要再添一句，“到时需动脑”，:-)
（注：《金字塔原理》是一本关于写作的书，非常不错，值得拥有）