1.实践对于大部分开发同学来说，很多时候，他们痛恨没有研发文档，却又不愿意经常写文档，痛苦而固执；程序员该不该写文档，无异于争论哪种编程语言最好。要撕口不留情，该写不罢工；当你的自我意识纠结于是否要做某事时，不妨停下来看看，大的职场环境如何选择，纠结自然就产生了，没必要；对于写文档，你不需要考虑能带来什么好处，也不需要考虑它会占用多少时间。用心去写，自然会明白其中的利弊。这两年，听很多实体朋友说，公司在大版本推广的时候，把文档管理提升到资产级，为文档输出预留时间，已经不是常识；从这几年的工作实践经验来看，写文档原则上是根据复杂的事情写得仔细，简单的东西简写或者不写，量可以但不能闲着；2、目录互联网产品具有一定的虚拟属性，很多事物和思想也具有明显的抽象感。如果缺少文档结构化描述，很容易随时间消失；这里列出了一些与研发管理和工作场所或多或少接触的文档。虽然结构复杂，但随着时间的推移，它会带来很大的价值，因为维护成本；工作中涉及的文件种类较多，但在管理和沉淀行动上重而不急。这并不意味着研发过程中的行动时间可以是混乱的；按照工作流程完成输出文档是一个比较正常的节奏。特殊情况，可以先解决问题，再补充文档；从开发的角度来看，如果在正常状态下进行版本升级，则可以将各种相关文档上传到指定目录；然而，工作中的生产环境却出现了很多意想不到的困难情况。这个时候，团队自然会优先解决他们。如果问题影响太大，后面还需要输出一个总结文档，这是经验。这更是一个教训；3.如果模板是个人文档，可以简明扼要；但工作文档需要有规范和文体约束，通常基于统一的模板库；在研发过程中，通常围绕项目的进度管理文档，其中会协调流程的核心内容，涉及到各个阶段的进度维护；基于项目进度管理文档模板，在流程推进过程中，不断补充相关核心内容，清晰准确记录版本进度；使用特定的模板来编写工作文档，这将具有规范化的效果。在部门的日常管理中，需要阶段性地沉淀和维护各种文档的模板结构，模板的内容可以根据具体需要而定。自己决定，需要在使用过程中不时优化；如果文档模板足够丰富，一??定程度上可以解决不想写文档的问题。很多人不愿意写文档的原因是缺少可用的文档模板;当模板库中有各种样例：项目进度、研发设计、测试用例、阶段总结、阶段规划等，下载后可直接使用，写出核心内容，让用户感慨万千排斥书写文档自然会减少；4.内容文件的内容就是价值。对于团队协作，内容要简明扼要，让阅读文档的人能够快速准确地了解事情的信息；通常文档中需要输出的事项比较复杂，所以内容需要适当。排版和复杂的逻辑尽量用图表来描述，这样内容和思路会很清晰；对于其他细节的控制，如段落缩进、专业术语、空格等，通常基于：内部文档尽量做好，外部文档一定要做好的原则；文档的内容是思维逻辑的呈现，在写的过程中很容易发现逻辑上的问题，然后通过review来讨论完善内容，这样在后续的过程中事情就不会围绕文档过度偏离来自主线；对于开发的角色来说，写文档是一件免不了的事情。一个项目呆久了，看最初的代码，感觉不是自己写的，更谈不上复杂的业务逻辑；研发文档中，最常用的图是逻辑时序，然后适当丰富相关内容，流程、逻辑、交互、数据管理等各个核心节点都可以包含在一张图中；开发的设计文档基本上都是几张图就能描述清楚的，通常涉及：业务流程图、逻辑时序图、数据结构图；当复杂的业务呈现在文档和设计图上时，其实就是为事物预先设定好的路线，当然有时候中途被迫折返或变道的情况并不少见；5、工欲善其事，工必先利其器。如果他们想快速制作文档，他们必须拥有易于使用的工具。根据我的经验，或多或少尝试过以下工具；图中红色标注的工具是我个人认为实践中比较好的工具。使用最多的是DrawIO和语雀文档，在免费范围内足够日常使用；由于工作需要，对接事项较多，协作各方使用的文档工具难以统一。自然，接触到的工具种类非常复杂。对于内部团队，通常使用与办公软件集成的工具，方便统一管理；那些写文档的习惯已经持续了很多年，工具也经历了三个变化，从office文档到Markdown，从离线到在线，换了一个文档工具；时代在变，文档产品也在不断更新。如何找到适合自己的工具，有一个基本原则：免费类，支持在线管理，功能适当丰富；最后分享一个写文档的理由：因为工作太多太复杂，所以应该写在文档里。这样你就可以安全地忘记它。
