共计 1911 个字符，预计需要花费 5 分钟才能阅读完成。
写文档也是技术活
$$01：实际 $$
对于少数开发同学来说，很多时候即厌恶没有研发文档，然而本人又不违心常写文档，痛且倔强着；
程序员该不该写文档，与争执哪种编程语言最好一样，想撕的嘴不留情，该写的笔不停耕；
当自我的意识下来纠结一件事件要不要去做的时候，无妨停下来看一看，大的职场环境是如何抉择的，纠结天然就没必要了；
对于写文档这件事件，并不需要去思考能带来哪些益处或者会占用多少工夫，用心去写天然明确当中利弊；
最近两年听到不少搬砖的敌人说，公司曾经把文档治理晋升到资产层面，在重大版本推动过程中，预留文档输入的工夫，这可不是个别的大聪慧；
从工作的这几年实践经验来看，写文档原则上本着简单的事项细写，简略的事项简写或者不写，卷能够但又不闲的慌；
$$02：目录 $$
互联网的产品，多少存在肯定的虚构属性，很多事件和想法也都具备显著的形象感，如果不足文档的结构化形容，工夫拉扯下很容易云消雾散；
这里列举一份在研发治理和职场中，或多或少都会接触到的文档内容，尽管结构复杂，但随着工夫的积淀，其带来的价值远大于保护老本；
工作中波及到的文档品种比拟繁多，但就治理和积淀的动作来说属于那种重要但不紧急的事件，这样说并不是指研发流程中动作的时序能够凌乱；
顺着工作流程把该输入的文档做好，是比拟失常的节奏，在非凡状况下也能够先解决事件，再后补文档；
从开发的角度来说，如果是惯例状态下的版本推动，那么在版本完结时各种相干文档就能够上传指定目录了；
然而工作中不乏很多生产环境突发的辣手情况，此时团队天然优先解决，如果问题影响过大，在预先必然还要输入总结文档，即是教训更是教训；
$$03：模板 $$
如果是集体的文档，简明扼要即可；然而工作文档须要有标准和格调上的束缚，通常状况下基于对立的模板库即可；
在研发流程中，通常会围绕我的项目的进度治理文档，在该文档中会兼顾流程中的核心内容，波及各个阶段的进度保护；
基于我的项目进度治理的文档模板，在流程推动的过程中，一直补齐相干的核心内容，清晰精确的记录版本进度；
采纳特定的模板写工作文档，自身就会起到标准的成果，在部门的日常治理中，须要阶段性的积淀和保护各类文档的模板构造，而模板的内容能够依据具体需要来定，在应用的过程中也须要时常优化；
如果文档模板足够丰盛，在肯定水平上能够解决不想写文档的问题，在写文档这件事上之所以会劝退很多人，很大起因是短少可用的文档模板；
当模板库中存在：我的项目进度、研发设计、测试用例、阶段总结、阶段布局等各种样例时，下载之后间接应用，编写核心内容即可，这样排挤写文档的情绪天然缩小；
$$04：内容 $$
文档的内容是价值所在，对于团队的合作来说内容简明扼要即可，让浏览文档的人能够疾速精确的了解事件的信息；
通常须要输入文档的事项都比较复杂，所以在内容上须要适当的排版，简单的逻辑尽量应用图解来形容，这样内容条理和思路都会很清晰；
对于其余细节方面的把控，比方段落缩进、专业名词、空格等，通常本着：对内的文档尽量做好，对外的文档必须做好的准则；
文档内容是思考逻辑的出现，在编写过程中也容易发现逻辑上的问题，再通过评审探讨和欠缺内容，这样事件围绕文档在后续的过程中不会适度偏离主线；
对于开发这个角色来说，写文档是避不开的事，在一个我的项目上待的工夫久了，再看初期的代码，都感觉不是本人写的，更别说是简单的业务逻辑了；
在研发文档中，最罕用的图解就是逻辑时序，再适当的丰盛相干的内容，在一份图中能够包含流程、逻辑、交互、数据管理等各个外围节点；
开发的设计文档根本是几张图就能够形容分明的，通常波及：业务流程图，逻辑时序图，数据结构图；
当简单的业务出现在文档和设计图上时，其实就是给事件预设好了航线，当然有时候中途被迫出航或变道也不少见；
$$05：工具 $$
工欲善其事，必先利其器，想疾速做好一份文档，必须得有趁手好用的工具才行，在多年写文档的教训中，以下工具多少都试用过；
图中标红的工具，是集体在实践中感觉不错的工具，当下应用最多的是 DrawIO 和语雀文档，在收费的边界内足够日常应用；
因为工作中须要对接的事项比拟多，很难对立合作的各方应用的文档工具，天然接触到的工具类型就很简单，对于团队外部来说，通常应用办公软件集成的工具，以便于对立治理；
写文档的习惯曾经继续了很多年，工具的变迁也经验了三次，从办公文档迁向 Markdown，从线下迁徙到线上，更换过一次文档工具；
工夫在变，文档类产品也在一直的更新换代，如何寻找本人棘手的工具，本着一个根本的准则：收费的领域内，反对在线治理，性能适当丰盛即可；
最初分享一条写文档的理由：因为工作多而简单，所以要写到文档中，这样便能安心的忘了它。
$$END$$
