科技公司的技术人，为什么不愿意写文档
不管是互联网公司还是传统的技术公司，技术侧，写文档是不是必要？
有必要
为什么不写呢？
可能是没时间，可能是觉得他的效果不明显。最主要的可能是自己不想写，没有意愿。
一般要写什么文档的呢？
至少写总体的设计文档，包括但不限于业务框架、技术框架，以及详细的设计文档
总体的设计文档一般包括什么内容？
需求:可以直接copy产品需求文档的story list部分
名词解释：这主要是照顾非相关领域的同学，需要在通读文档之前提前了解一些概念性质的东西。
设计目标：分为功能目标和性能目标，功能目标主要是对需求的技术描述，性能目标是根据给出的数据对性能进行评估，一般来说，性能目标会影响设计方案。
系统架构：一般来说需要有个简单的架构图，并配以文字对架构进行简单的简要说明；
模块简介：架构图中如果有很多模块，需要对各个模块的功能进行简要的介绍。
设计和折衷：设计和折衷是总体设计中最重要的部分。
详细设计需要哪些？
总体设计结论汇总:可以理解为详细设计对上述总体设计结论的实现
交互流程：简单的交互用文字描述，复杂的描述建议使用流程图，交互图或其他图形进行说明
数据库设计：数据表存储的设计
接口细节：输入什么参数，输出什么参数，根据接口的前端、后端、APP等能进行代码实现
理论上，详细设计达标的标准是，无论谁拿到这个设计文档，都是能够完成该项目的。
咱们今天主要说下性能目标和设计折衷。
设计和折衷
总设中最重要的内容，总社评审中主要讨论的这些折衷的优劣。
评审过后，需要邮件周知，需要及时更新总设中内容，说明最终选中了哪个方案，为什么为选择这个方案。大家是不是这样的体验：我们接手别人的模块、项目、拿到代码和文档，完全是个谜，啥也不知道。
有时候因为人力和排期的问题，不一定采用最优的设计方案，所以这时候更需要在总设中记录决策过程和原因。
性能目标
随着互联网的普及，很多项目依赖于性能的提升，那么现在就很有必要去撰写性能文档，一般包括如下几点
日平均请求：这个需要产品经理支持评估
平均QPS:日平均请求数除以4w。为什么除以4w呢，24小时转化为秒是86400秒，用户活跃都是在白天，除以2得4w
峰值QPS：一般以平均QPS的2-4倍算。也可以根据2/8原则来算。也差不多是2-4倍
文档清楚，开发阶段的变化较小，未来的迭代成本也小。
一个好的程序员是不是应该花80%的时间做代码设计、画UML图、画时序图、讨论需求，而20%的时间做code和debug。
写好文档是给别人更快的替换自己吗？
写什么文档，写完代码我就跑路了。
我们都是面向老板编程的。
平时注释都懒得写，怎么可能去写文档，我又不去造车。
你不写，我也不写，互相杀害。
原文作者：二进制跳动；如有侵权，请联系管理员删除。
