聊聊后端技术文档那些事

无奈的现实

作为服务端开发，对于中小型的需求（比如只涉及单端 <5人天）出技术方案常让人苦恼，费时间，费力，时不时还要务虚一下，说句大白话，有那点时间，代码早都写完了，何必呢？

往粗了写，主要是给 leader 看，要讲「政治正确」，起不到实际帮助自己理顺 todo 的效果。

往细了写，业务代码细节多，能看懂的人，其实基本不需要看，本来也知道要怎么做。

但常常我们又不得不写一个技术方案出来，从项目推进的「政治正确」，到 leader 的要求，到很多项目的复盘todo，很可能强制你必须整个文档出来。

作为服务端一线研发，我们应该怎样看待「技术文档」，又该怎么去写呢？

为什么要有方案文档

• 以较为系统化的方式，梳理清楚要做的事情；
• 与合作者对齐上下文，保证对接人的认知一致；
• 明确方案的细节，提前暴露可能的风险和工作量；
• 记录自己的思考，以及项目执行中踩过的坑，方便之后回过头来 review ，排查问题；
• 让 leader 了解你的思考和设计，作为绩效的证明；
• 帮助其他同学了解业务，为未来可能的交接做好准备。

一篇优质的技术方案文档，可以帮助你省下大量的沟通成本，也可以提前规避掉潜在的风险，带来的杠杆效应其实是很强的。也因为你需要出一个技术文档，很多一拍脑门就定下来的设计会被二次 review，修正不合理的部分。

那么&#