写文档也是个技术活。
对于大多数开发生来说，他们往往痛恨研发文档的缺失，但又不愿意经常写文档，所以痛苦而固执。
程序员该不该写文档，就跟辩论哪种编程语言最好一样。想撕嘴就毫不留情，该写的笔就不停犁。
当一个人的自我意识纠结于一件事该不该做的时候，不妨停下来看一看大的职场环境是如何选择的，自然没必要纠结；
对于写文档来说，你不需要考虑它能带来什么好处，或者要花多少时间。用心写，自然能明白利弊；
近两年听很多搬砖的朋友说公司把文档管理提升到资产层面了。在推广主要版本的过程中，预留文档输出的时间不是一般的智慧。
从这几年的实践经验来看，原则上写公文是以复杂事项的详细书写为基础，简单事项略写或不写，卷可以写但不要太闲；
02:目录
互联网产品有一些虚拟属性，很多东西和想法明显是抽象的。如果没有文档的结构化描述，很容易在时间的拉扯下消失。
这里有一个在研发管理和工作场所或多或少可以接触到的文档列表。虽然结构复杂，但随着时间的推移，它带来的价值远远大于维护成本。
工作中涉及的文件种类很多，但就管理和沉淀的动作而言，重要但不紧急。这并不意味着RD进程的行动顺序会混乱；
沿着工作流程做好输出文档是正常节奏。特殊情况下，可以先解决事情，再补充文件。
从开发的角度来看，如果在正常状态下推送版本，那么各种相关文档都可以上传到版本末尾的指定目录；
然而，在生产环境中有许多棘手的情况。这时候团队自然会优先解决。如果问题影响太大，事后需要输出一个总结文档，即经验是教训。
03:模板
如果是个人文件，可以简明扼要；但是，工作文档需要受到规范和风格的约束，通常基于统一的模板库；
在RD过程中，进度管理文档通常是围绕项目的，其中会对过程的核心内容进行协调，涉及到各个阶段的进度维护；
基于项目进度管理的文档模板，在流程推进过程中，不断填写相关核心内容，清晰准确记录版本进度；
使用特定的模板来编写工作文档将会产生标准化的效果。在部门日常管理中，需要分阶段沉淀和维护各类文档的模板结构，模板的内容可以根据具体要求确定，在使用过程中需要不时优化。
如果文档模板足够丰富，就可以在一定程度上解决不想写文档的问题。许多人不愿意写文档的原因是缺少可用的文档模板。
当模板库中有各种样本时，如项目进度表、RD设计、测试用例、阶段总结、阶段规划等。，直接下载下来用就行了，只写核心内容，这样拒绝写文档的情绪自然就降低了；
04:内容
文档的内容就是值。对于团队协作，内容简明扼要，让看文档的人快速准确的了解事物的信息；
通常需要输出的项目比较复杂，所以内容需要适当的排版，复杂的逻辑尽量用图来描述，这样内容组织和思路才会清晰；
其他细节的控制，比如段落缩进，专业术语，空大小写等。，通常是本着内部文件尽量做好，外部文件一定要做好的原则；
内容是思维逻辑的呈现，在写作过程中很容易发现逻辑问题，然后通过回顾来讨论和完善内容，这样文档周围的事情在后续过程中就不会偏离主线太多；
为了发展这个角色，写文档是不可避免的。在一个项目上呆久了，看着最初的代码，觉得不是自己写的，更别说复杂的业务逻辑了；
在RD文件中，最常用的图表是逻辑顺序，然后适当充实相关内容。图表可以包括核心节点，如流程、逻辑、交互、数据管理等。
开发的设计文档可以用几个图描述清楚，通常涉及:业务流程图、逻辑序列图、数据结构图；
当复杂的业务呈现在文档和设计图纸上时，它实际上是事物的预设路线。当然，有时被迫折返或中途变道的情况并不少见；
05:工具
欲善其事，必先利其器。如果你想快速制作一个文档，你必须有手边的工具。在多年的文档编写经验中，尝试过以下工具。
图中中标的工具都是个人在实践中觉得不错的。目前用的最多的是DrawIO和语言鸟文档，在免费边界内足够日常使用；
由于工作中需要对接的东西很多，合作方使用的文档工具很难统一，自然接触到的工具类型也很复杂。对于团队内部，通常使用与办公软件集成的工具，便于统一管理；
写文档的习惯已经持续了很多年，工具的更换经历了三次，从office文档到Markdown，从线下到线上，文档工具换了一次；
时代在变，文档产品也在不断更新。如何找到自己得心应手的工具，是基于一个基本原则:在免费的范围内，支持功能适当丰富的在线管理；
分享一下写文档的最后一个理由:因为工作复杂，所以要写在文档里，这样才能安心忘记。
目标
