本章的主要身体力行的传授了制作一份文档的细节；流程图的心得；以及探讨了自文档化。
需要什么样的文档
首先根据不同受众，应分不同级别的文档。
用户手册（使用程序）
每个用户都需要一段对程序进行描述的文字。
- 目的。主要的功能是什么？开发程序的原因是什么？
- 环境。程序运行在什么样的机器、硬件配置和操作系统上？
- 范围。输入的有效范围是什么？允许显示的合法范围是什么？
- 实现功能和使用的算法。精确地阐述它做了什么。
- 输入－输出格式。必须是确切和完整的。
- 操作指令。包括控制台及输出内容中正常和异常结束的行为。
- 选项。用户的功能选项有哪些？如何在选项之间进行挑选？
- 运行时间。在指定的配置下，解决特定规模问题所需要的时间？
- 精度和校验。期望结果的精确程度？如何进行精度的检测？
测试用例（验证程序）
除了程序的使用方法，还必须附带一些程序正确运行的证明，即测试用例。
- 常规的 、主功能的；
- 极限的 ，边界的。
- 错误的 ，不符合规范的，用于测试异常情况。
开发文档（修改程序）
和一般用户一样，修改者迫切需要一份清晰明了的概述，不过这一次是关于系统的内部结构。那么这份概述的组成部分是什么呢？
- 流程图或子系统的结构图，对此以下有更详细的论述。
- 对所用算法的完整描述，或者是对文档中类似描述的引用。
- 对所有文件规划的解释。
- 数据流的概要描述——从磁盘或者磁带中，获取数据或程序处理的序列——以及在每个处理过程完成的操作。
- 初始设计中，对已预见修改的讨论；特性、功能回调的位置以及出口；原作者对可能会扩充的地方以及可能处理方案的一些意见。另外，对隐藏缺陷的观察也同样很有价值。
流程图
流程图是 被吹捧得最过分 的一种程序文档。事实上， 很多程序甚至不需要流程图，很少有程序需要一页纸以上的流程图。
流程图显示了程序的流程判断结构，它仅仅是程序结构的一个方面。
当流程图绘制在一张图上时，它能非常优雅地显示程序的判断流向，但当它被 分成几张时 ，也就是说需要采用经过编号的出口和连接符来进行拼装时， 整体结构的概观就严重地被破坏了 。
大家完全可以丢掉流程图，使用文字列表来表达这些内容
自文档化（self-documenting）
在作者的年代自文档化刚刚萌芽，大意包括不限于
- 规范的格式，请大家遵守各自语言的“最佳实践”；
- 重复模块的抽象；
- 良好而规范的注释，有些工具甚至可以通过注释生成API文档；
- 好的版本号，推荐语义化版本