设计方案，写了才知道有多香 黄金外汇期货投资方案设计思路怎么写好一点呢

设计方案，拿来吧你

大家好，我是零一，今天要跟大家聊聊开发流程中不起眼的环节——设计方案。你们可能没听过，也可能只是简单得走过过场，别划走，这非常重要！

在字节，我接触到了更完善、更规范、更高效的开发流程：产品需求设计 => 需求粗评 => 做设计方案 => 粗估时 => 需求细评 => 排期 => 开发 => 提测、修bug => code review => 上线

其实在我未工作之前，大部分的流程我都听说过或者在实习时经历过，比较少接触的可能就是设计方案和code review了，这两者分别是干什么的？

设计方案：在拿到需求后，写一个文档，来描述自己对于该需求的实现思路、模块划分等相关考虑的点，可供今后自己或他人查阅Code review：代码提交合并前给mentor或leader检查一下你的代码，让别人作为旁观者来看你的代码，集思广益，完善代码，发现未考虑到的边界问题

说实话哈，啥设计方案啊，我第一次在一家小公司实习的时候，突然就被产品叫过去，花5分钟给我阐述了一下下个版本他想要上的功能，紧接着立马就问我：你看看大概需要多久？我的预估是5天后就上线，ok吗？

我： ？？？？？？？？？ （内心os：我刚知道这个需求，我哪能那么快知道我得花多久做出来啊！你说5天就5天吧，反正我说6天也没用）

太离谱了，可能很多小公司的现状都是像我说的这样吧！这样真的很不好，版本快速迭代中掺杂着许多需求，而开发时间又比较紧张，只会让开发想尽办法怎么赶紧把功能实现，而不会去考虑任何性能问题，更别说让你考虑边界问题了。长期这样下去，你会深深地体会到你处于一个无止境的项目快速迭代中，加班、通宵可能都是常事，哪还会有时间去学习新的知识或做自己爱做的事，也不会有多余的时间去关注自己接手的需求从开发到上线的整个生命周期线，不会定期去复盘，因此个人的项目经验、技术积累是很少的

之前也有小伙伴私聊过我类似的情况，我也是建议他最好能在一个有「自我学习」、「定期复盘反省」的环境中工作

大圣老师就是如此，记得他在有次直播中讲到，他当年去360时，把「能留给自己充足的学习时间」作为他最在乎的因素，这样真的非常好。大家也可以看看自己当前的现状是否真的利于自己发展，然后做更长远的打算。

好了，言归正传！

我们为什么要写设计方案呢？

目的是为了在真正开始敲代码之前理清自己的思路，对需求有一个更清楚的认识，这样就不至于在开始开发后边写代码边思考了，想必你们都有遇到在写代码时突然发现哪一模块之前没考虑到，然后对之前写好的代码的架构进行调整，代码进行抽离，这无疑是在降低开发效率。

另一点就是时间一久，突然这个功能出现了一个bug让你去修复，你可能会对自己写的代码有些忘却，此时找到之前自己写的设计方案一看便知，这同样也能作为新入职的小伙伴在熟悉现有代码的重要资源！

对于第二点我深有感触，到一个新部门总会接手1~2个祖传项目代码，紧接着你就要阅读他们的代码逻辑，这是非常痛苦的，因为你根本不了解这些需求的背景，也不了解他人代码完整的设计思路，这不跟抱着一本厚书在那硬啃一样嘛！

要是之前的人都写过设计方案，你完全可以在看每个模块的时候，找到相应的文档，这不事半功倍嘛~

那么如何写设计方案呢？

整个方案大致分为4个部分：需求相关信息、方案调研、具体方案、其它

一、需求相关信息

作为一个开发工程师，一定要有工程师的精神，需要对自己所接手的需求有清晰的认识，这包括：负责这个需求的其它相关人员分别是谁（产品、测试、UI、后端等）、我这个需求的出现背景是什么、需求何时提测，何时上线...

格式如下：

一、需求相关信息​ 需求背景：因为我们要做线下推广，提高xxxxxxxxx PRD：文档