无奈的现实
作为服务端开发,对于中小型的需求(比如只涉及单端 <5人天)出技术方案常让人苦恼,费时间,费力,时不时还要务虚一下,说句大白话,有那点时间,代码早都写完了,何必呢?
往粗了写,主要是给 leader 看,要讲「政治正确」,起不到实际帮助自己理顺 todo 的效果。
往细了写,业务代码细节多,能看懂的人,其实基本不需要看,本来也知道要怎么做。
但常常我们又不得不写一个技术方案出来,从项目推进的「政治正确」,到 leader 的要求,到很多项目的复盘todo,很可能强制你必须整个文档出来。
作为服务端一线研发,我们应该怎样看待「技术文档」,又该怎么去写呢?
为什么要有方案文档
- 以较为系统化的方式,梳理清楚要做的事情;
- 与合作者对齐上下文,保证对接人的认知一致;
- 明确方案的细节,提前暴露可能的风险和工作量;
- 记录自己的思考,以及项目执行中踩过的坑,方便之后回过头来 review ,排查问题;
- 让 leader 了解你的思考和设计,作为绩效的证明;
- 帮助其他同学了解业务,为未来可能的交接做好准备。
一篇优质的技术方案文档,可以帮助你省下大量的沟通成本,也可以提前规避掉潜在的风险,带来的杠杆效应其实是很强的。也因为你需要出一个技术文档,很多一拍脑门就定下来的设计会被二次 review,修正不合理的部分。
那么&#