开发文档的目的
开发文档不是蓝图，不是设计文档，它的重点是关于技术的、关于实现的，但也不仅仅是一些伪代码。应当包含 “程序为什么设计”、“主要功能点是什么”、“目标是什么”、“程序的编码思想思路是什么” 等内容。没有一个结构化的、连贯的程序主要逻辑说明，用户或者文档阅读者是看不出你如何使用数据或组织数据的。所以我们必须将数据和代码演变为信息管理，实现需求设计所要求功能。
要点罗列
Point 1:模板和标准
最为关键的是在撰写文档前和客户约定好开发文档模板以及各部分验收标准，取得事半功倍的效果。使用一个良好的模板范本和客户详细沟通，逐步改进达成一致，而不是匆匆忙忙按自己的理解编写完所有开发文档，而被客户验收时一脚踢出，打回重写，事倍功半。
Point 2:以客户为中心
技术文档是作为交付物而存在的，因此一定是面向客户的。要让客户知道程序提供了什么，是否达成了预期，程序运行的结果，以及你是如何达成预期结果的。不要让用户读完不理解你做了什么，那样就必须返工重做了。
不要仅描述乐观路径在有程序重大的异常分支处理存在时，一定要在开发文档里体现出来，满足程序对乐观路径和悲观路径的全覆盖。
Point 3:可视化
一个用户友好的文档应该是可视化的，对程序的一些复杂情况如接口相关、数据库表的交叉引用、流程图、屏幕编程等最好使用图片、图表或者附件等方式，更清晰完美的展现技术内核。
Point 4:WORD 风格
利用 WORD 工具的目录或者文档地图等功能，让用户可以快速浏览开发文档。当然还包括使用统一的字体、对齐、缩进、小标题、LOGO 等有用的小技巧。
Point 5:及时更新
当重要变更发生时，一定要及时更新文档。在 SAP 的项目里，开发文档一般是最后撰写，这个时候程序相对已经稳定，改动会较少，但也不要对这点视而不见。
Point 6:结构化文档
在一个大项目里，通常会包含若干个程序，那么文档本身也需要管理。通常应该按照模块或者程序类型放置在不同的文件夹路径里，另外避免给文档命名如’XX_023_DS_1.0’，应该用有意义的名称。