阿里面试官问我，你们的需求研发/开发流程是怎样的？我？？？

点赞再看，养成习惯，微信搜索【三太子敖丙】关注这个互联 苟且偷生的程序员。

前言

我的读者好像学生居多，然后大家最近问的比较多的一个话题就是大厂的研发流程，都比较好奇，整个流程是怎么操作的。

我也不多BB了，那下面就跟随暖男的脚步，走进大厂研发流程吧。

正文

我们先看看一个产品有哪些研发流程，帅丙就用自己接触的阿里系的研发流程举例了，这也基本上是互联 大厂的研发流程了，可能细节有出入，但是绝对大同小异。

我问了下字节，多多，腾讯的朋友出入不大，所以还是具有代表性。

需求PRD提出：

这个阶段，产品爸爸会根据第一版聊下来的结果，大致出一个Demo版本的PRD，会画出初版的原型图，并且配上文字说明，所有涉及到的业务，还有交互细节都会罗列出来。

大致就是下图这样：

大家看到的这种操作界面，按钮，图标的各种位置和图案，都是UI在这个阶段设计好的。（我什么都没暗示，不用关注我的B站）

大家敲定后就进入我们开发人员的回合了。

概要设计：

概要设计，这个是大厂程序员需求下来之后基本上都会做的一步，不过看需求大小，可能很多小需求直接就详细设计了，也有啥设计都不用做的小改动，具体需求具体分析嘛。

很多不了解的同学可能会问，需要设计什么呢什么要设计呢/p>

问得好，经常看我文章的都知道，技术是把双刃剑，你用了技术之后你是不是需要列出他的优点缺点，出问题之后的解决方案，还有可能出现的问题，注意点等等。

这么是为了让你能有把控力，比如你这个需求接入了新技术Es（Elasticsearch）你什么都不管你就是要接入它，你把他开发好了上线了，但是有啥坑你知道么线崩了怎么办/p>

不主动，不拒绝，不负责，这是渣男的行径，我们需要负起责任。

这个环节你需要考虑这个需求涉及到哪些服务了，需要新增哪些接口，修改哪些接口，表有现场的还是要新建表，字段要新建么/p>

其实远远不止这些问题，这就是我们做设计的主要原因，也是大家工作里面能成长的途径之一，你以为大佬们的经验是怎么来的/p>

推荐工具：Xmind/ProcessOn

• Xmind官 地址： https://www.xmind.cn
• ProcessOn在线作图地址：https://www.processon.com

ProcessOn是我使用最频繁的工具了，我身边也有很多小伙伴在用，也推荐大家都使用：

这个设计好了，就需要给Leader看，看理解程度，一两次返工是有可能的，如果你像或者像敖丙一样笨的话，是有可能会被打回N次的，这里我得提一下，好好做设计好处大大的有，自己体会。

然后会进行一轮测试用例评审，比如你涉及哪些服务，新增了哪些接口，改了哪些接口，都是要同步出来的，至于为啥/p>

是因为测试会依据这个数据，评估影响范围，方便他写测试用例，后面会提到。

详细设计

小伙伴又要问了啥是详细设计呀帅丙/p>

傻瓜，简单呀，见名知意嘛，概要设计是大概的设计，详细设计是详细的设计。

我们研发的时候整个流程往往很复杂，如果你理解不对直接就写代码，最后容易造成返工，延期，加班，被骂，心情差，回家吵架，离家出走，露宿街头，饥寒交迫，被迫吃野味，然后全国。。。。

看到不做详细设计的后果了吧，其实大家花点时间做详细设计很有必要，你思路完全清晰了，写代码那就是分分钟的事情，不是嘛/p>

那再看看帅丙的一个小设计吧，之前文章中大量的流程图，时序图都来自它，主要是这玩意还是在线的，都不用下载很方便啊。

详细设计的工具我用的就是之前提到的在线作图神器：ProcessOn https://www.processon.com

还是我自己之前设计的一些流程图，大家可以看看：

这个环节也会开会讨论，也是细节的确定，比如他写的是否合理，或者有什么点没考虑到，大家有没有补充的。

接口定义&开发&前后端联调

这个环节其实比较好理解，啥都敲定了，那就开发呗，开发差不多了，就得前后端联调了。

这里有个小细节还是想说一下，一般开发前我们都会提前定义数据类型，接口名称，然后在公司的接口工具上给出链接和参数，方便前端爸爸mock数据。

他总不能等我们后端开发完了，才去开发嘛，这样效率打折扣，所以都是后端先定义好，然后前后端并行开发的。

大家可以看到我列出了我们开发的所有环境。

Tip：日常环境不能由开发人员发布，是因为测试流程比较久，所以不能中断，如果你一直发布会影响测试的效率，在发布期间他们是没办法干活的，而且很多部门涉及相同的服务，你发布还会影响别人。

测试发布之前，在测试群里问问可以发某个服务么，大家觉得不影响，那么就可以发了，懂了吧。

预发环境，也叫灰度环境，这是跟线上数据一样的一个环境，只是只能内 访问，一般这一步是防止很多是因为日常的数据量不够真实，数据级别达不到线上的量级无法测出的bug。

扯远了，联调完了就是代码Review了。

代码Review：

codeReview环节，画一下重点，这可能是整个研发流程中，让你成长最快的一个环节，让组员和Leader Review你的代码，往往他们能给你很多业务上和技术上的建议和意见。

过来人的经验你就说香不香吧，以前老大经常没时间，但是我就是烦着他要Review，后来他说不用review了，但是我还是要组员大佬review，因为我很享受别人对我提建议的时候，这不就是成长，扫盲的好时机嘛。

总之你也不知道会出现什么bug，我看身边的大神也只能用经验避免常见的吭，孰能生巧吧。

发布计划

敲黑板，这个确实是比较重要的环节，这个环节主要是开发同学和前端同学说好一个发布时间，然后制定一个发布计划，为啥要发布计划呢/p>

我们开发一个需求，可能涉及到N个服务，这些服务是有依赖关系的，那就需要打包，比如订单系统，依赖人员系统。优惠券系统，也依赖人员系统，然后订单系统还依赖优惠券系统，是不是有点乱了/p>

我们看图：

一般现在都是自动化发布，界面上点点就好了，记得丙丙大学发布都是进服务器一个个kill进程，替换jar包然后重启。

现在都是分布式的集群，这样发无疑会累死，我之前负责的系统有50多台机器，一般都是4台4台发布。

日志观察&产品第二次验收

一般发布第一批之后不会马上发布第二批，而是观察错误日志，看看是否正常，有时候会发现还是会出现异常情况的，那就保留错误日志，然后回滚。

知道解决了再发布，顺利的话就没啥错误，一口气发完了，看了下时间凌晨了，那发完差不多也得回家了。

一次发布可能涉及服务多的话，真的有可能发布这么久，但是没办法，线上出问题就是掉脑袋的事情。

日志观察一般公司都有错误日志搜集系统，或者自己登录跳板机查看就好了。

没问题，发完之后告诉产品大大就好了。

需求结束

至此基本上一个需求可能就结束了，其实还是很不容易的，短的需求几天，长的需求几个月，中间涂涂改改，BUG，技术难点都是你要面对的，不过没啥大问题，我们技术人嘛皮实能顶。

总结

产品研发流程大家是不是觉得有点复杂，或者觉得很多点有点小题大做了，不瞒你说，刚开始我也这么认为的，但是随着时间的推移，你会发现有时候越是这样规范，越是提升了效率，也提升了产品质量。

对自己设计的严苛也会让你的业务能力提升，开发考虑的点也越来越广泛，我想大佬应该都是这样走过去的，那没啥好说的，我们也走。