大厂研发需求流程，没想到这么复杂吧？
https://mp.weixin.qq.com/s/SB3aHvalAmZ3_RVwjhpekg
大厂研发需求流程，没想到这么复杂吧？
收录于话题前端
#程序员 1567程序员
#阿里巴巴 554后端
#大厂面经 14服务器
引言分布式
个人读者好像学生居多，而后你们最近问的比较多的一个话题就是大厂的研发流程，都比较好奇，整个流程是怎么操做的。ide
我也很少BB了，那下面就跟随暖男的脚步，走进大厂研发流程吧。工具
正文
咱们先看看一个产品有哪些研发流程，帅丙就用本身接触的阿里系的研发流程举例了，这也基本上是互联网大厂的研发流程了，可能细节有出入，可是绝对大同小异。学习
我问了下字节，多多，腾讯的朋友出入不大，因此仍是具备表明性。测试
看完流程咱们就一个个点的去看看每一个环节干了些啥，咱们开发同窗在这个环节须要作啥，以及在每一个环节的职能。spa
需求提出：
这个环节主要是产品爸爸给咱们提需求，每一个需求都是他们从用户，或者本身绞尽脑汁想出来的，可是产品爸爸还拿不许，不能直接敲定，因此就须要咱们你们（产品，UI，前端，后端，客户端和测试）一块儿讨论一下，看看这个需求是否合理，或者这个需求是否有意义，可否达到预期，技术实现的成本，周期等等。
一旦聊成了，他们就会进入下一个阶段，聊不成他会千方百计让你答应，而后进入下个阶段，知道我为啥叫产品爸爸了吧？
需求PRD提出：
这个阶段，产品爸爸会根据初版聊下来的结果，大体出一个Demo版本的PRD，会画出第一版的原型图，而且配上文字说明，全部涉及到的业务，还有交互细节都会罗列出来。
大体就是下图这样：
这个时候你们又会围绕这一版本去开会讨论，敲定细节，这个环节会久点，由于细节比较认真，逻辑也不能出错，还有UI稿子也得敲定，这里若是不敲定逻辑，UI提早去画原型图，后面假如逻辑推翻，一切重来就会浪费大量时间。
这一环节你们都会把细节问清楚，不了解的点也会去了解，测试，开发，UI咱们都会在会议上提出本身的观点，本身的意见，而后等产品反馈，最后意见一致以后，产品当天就回改出敲定版本。
UI就会按照产品爸爸的意思去做图，接下来就是交互设计评审了。
交互设计评审：
UI会画出客户端，前端，H5开发所须要的UI图，基本上就是咱们看到的产品的样子了，不过仍是要敲定细节，好比按钮合理不，或者上面数据是否在这展现，或者这里展现的数据是否合理。
这个环节会比较快，只要UI按照以前敲定的逻辑开发，出入不会很大，通常都是小改。
可是也不乏不少，以前敲定了状况，等UI按照敲定版本出了图，可是却发现出图以后有些不合理的点，好比是否应该在这里展现GMV（销售总额），或者是否这样展现活动规则啥的，会有这种状况，不过是小几率事件，改动也不会特别大。
UI界面：
你们看到的这种操做界面，按钮，图标的各类位置和图案，都是UI在这个阶段设计好的。（我什么都没暗示，不用关注个人B站）
你们敲定后就进入咱们开发人员的回合了。
概要设计：
概要设计，这个是大厂程序员需求下来以后基本上都会作的一步，不过看需求大小，可能不少小需求直接就详细设计了，也有啥设计都不用作的小改动，具体需求具体分析嘛。
不少不了解的同窗可能会问，须要设计什么呢？为何要设计呢？
问得好，常常看我文章的都知道，技术是把双刃剑，你用了技术以后你是否是须要列出他的优势缺点，出问题以后的解决方案，还有可能出现的问题，注意点等等。
这么是为了让你能有把控力，好比你这个需求接入了新技术Es（Elasticsearch）你什么都无论你就是要接入它，你把他开发好了上线了，可是有啥坑你知道么？上线崩了怎么办？
不主动，不拒绝，不负责，这是渣男的行径，咱们须要负起责任。
这个环节你须要考虑这个需求涉及到哪些服务了，须要新增哪些接口，修改哪些接口，表有现场的仍是要新建表，字段要新建么？
其实远远不止这些问题，这就是咱们作设计的主要缘由，也是你们工做里面能成长的途径之一，你觉得大佬们的经验是怎么来的？
推荐工具：Xmind/ProcessOn
Xmind官网地址：https://www.xmind.cn
ProcessOn在线做图地址：https://www.processon.com
ProcessOn是我使用最频繁的工具了，我身边也有不少小伙伴在用，也推荐你们都使用：
你们在学习，看书等等的时候作个脑图，后面学习和复习的时候思路会很清晰，并且效率瞬间高不少，造成知识体系。
概要设计通常就是作个大概，给你们看一下我本身在设计ES相关的需求的时候的概设，比较粗糙看个大概就行了：
这个设计好了，就须要给Leader看，看理解程度，一两次返工是有可能的，若是你像或者像敖丙同样笨的话，是有可能会被打回N次的，这里我得提一下，好好作设计好处大大的有，本身体会。
而后会进行一轮测试用例评审，好比你涉及哪些服务，新增了哪些接口，改了哪些接口，都是要同步出来的，至于为啥？
是由于测试会依据这个数据，评估影响范围，方便他写测试用例，后面会提到。
详细设计
小伙伴又要问了啥是详细设计呀帅丙？
傻瓜，简单呀，见名知意嘛，概要设计是大概的设计，详细设计是详细的设计。
咱们研发的时候整个流程每每很复杂，若是你理解不对直接就写代码，最后容易形成返工，延期，加班，被骂，心情差，回家吵架，离家出走，露宿街头，饥寒交迫，被迫吃野味，而后全国。。。。
看到不作详细设计的后果了吧，其实你们花点时间作详细设计颇有必要，你思路彻底清晰了，写代码那就是分分钟的事情，不是嘛？
那再看看帅丙的一个小设计吧，以前文章中大量的流程图，时序图都来自它，主要是这玩意仍是在线的，都不用下载很方便啊。
详细设计的工具我用的就是以前提到的在线做图神器：ProcessOn https://www.processon.com
仍是我本身以前设计的一些流程图，你们能够看看：
这个环节同样重要，这个地方若是你能想好不少细节，开发的时候效率会高不少，像我上面的一些点，基本上就是看着图开发了。
这个环节通常上不须要Leader参与，可是若是你有疑问或者不了解的点仍是要提出来的。
测试用例评审：
上面咱们说过，测试会根据你的概要设计，评估你的影响范围，你的影响点，新增和改动的接口啥的，去编写本身的测试用例。
测试用例，主要是为了把改动点影响点都考虑到，测全一点，省得上线了影响别的现有业务，也是为了把你开发的功能可能出现的bug给排除了。
我拿个小破站的小用例你们看看，这个比较粗糙可是也有点那味了。
这个环节也会开会讨论，也是细节的肯定，好比他写的是否合理，或者有什么点没考虑到，你们有没有补充的。
接口定义&开发&先后端联调
这个环节其实比较好理解，啥都敲定了，那就开发呗，开发差很少了，就得先后端联调了。
这里有个小细节仍是想说一下，通常开发前咱们都会提早定义数据类型，接口名称，而后在公司的接口工具上给出连接和参数，方便前端爸爸mock数据。
他总不能等咱们后端开发完了，才去开发嘛，这样效率打折扣，因此都是后端先定义好，而后先后端并行开发的。
后端开发好，通常都是会发布到联调环境，咱们有哪些环境，联调环境在咱们全部的环境中处于哪一个地位呢？
你们能够看到我列出了咱们开发的全部环境。
Tip：平常环境不能由开发人员发布，是由于测试流程比较久，因此不能中断，若是你一直发布会影响测试的效率，在发布期间他们是没办法干活的，并且不少部门涉及相同的服务，你发布还会影响别人。
测试发布以前，在测试群里问问能够发某个服务么，你们以为不影响，那么就能够发了，懂了吧。
预发环境，也叫灰度环境，这是跟线上数据同样的一个环境，只是只能内网访问，通常这一步是防止不少是由于平常的数据量不够真实，数据级别达不到线上的量级没法测出的bug。
扯远了，联调完了就是代码Review了。
代码Review：
codeReview环节，画一下重点，这多是整个研发流程中，让你成长最快的一个环节，让组员和Leader Review你的代码，每每他们能给你不少业务上和技术上的建议和意见。
过来人的经验你就说香不香吧，之前老大常常没时间，可是我就是烦着他要Review，后来他说不用review了，可是我仍是要组员大佬review，由于我很享受别人对我提建议的时候，这不就是成长，扫盲的好时机嘛。
提测&灰度发布&产品第一次验收
这一阶段就是把代码都发到平常环境，而后等测试爸爸测试，这个环节开发同窗若是没BUG是比较轻松的，等着就行了，能够看看丙丙的文章啊，看看丙丙的B站视频什么的。
可是若是你BUG多，那我以为你可能会生不如死，由于有的bug真的找好久好久的，调用链路又长，特别是跨服务又涉及消息队列，或者第三方的接口什么的。
总之你也不知道会出现什么bug，我看身边的大神也只能用经验避免常见的吭，孰能生巧吧。
发布计划
敲黑板，这个确实是比较重要的环节，这个环节主要是开发同窗和前端同窗说好一个发布时间，而后制定一个发布计划，为啥要发布计划呢?
咱们开发一个需求，可能涉及到N个服务，这些服务是有依赖关系的，那就须要打包，好比订单系统，依赖人员系统。优惠券系统，也依赖人员系统，而后订单系统还依赖优惠券系统，是否是有点乱了？
咱们看图：
打包和发布顺序原则上是同样的，从没彻底依赖的服务按照顺序发布到最后一个服务。
生成环境上线：
这就是神圣而庄严的上线环节，通常在这个环节丙丙都是要洗手洗澡，而后才点下那个神圣的发布按钮。
通常如今都是自动化发布，界面上点点就行了，记得丙丙大学发布都是服务器一个个kill进程，替换jar包而后重启。
如今都是分布式的集群，这样发无疑会累死，我以前负责的系统有50多台机器，通常都是4台4台发布。
日志观察&产品第二次验收
通常发布第一批以后不会立刻发布第二批，而是观察错误日志，看看是否正常，有时候会发现仍是会出现异常状况的，那就保留错误日志，而后回滚。
知道解决了再发布，顺利的话就没啥错误，一口气发完了，看了下时间凌晨了，那发完差很少也得回家了。
一次发布可能涉及服务多的话，真的有可能发布这么久，可是没办法，线上出问题就是掉脑壳的事情。
日志观察通常公司都有错误日志搜集系统，或者本身登陆跳板机查看就行了。
没问题，发完以后告诉产品大大就行了。
需求结束
至此基本上一个需求可能就结束了，其实仍是很不容易的，短的需求几天，长的需求几个月，中间涂涂改改，BUG，技术难点都是你要面对的，不过没啥大问题，咱们技术人嘛皮实能顶。
总结
产品研发流程你们是否是以为有点复杂，或者以为不少点有点小题大作了，不瞒你说，刚开始我也这么认为的，可是随着时间的推移，你会发现有时候越是这样规范，越是提高了效率，也提高了产品质量。
对本身设计的严苛也会让你的业务能力提高，开发考虑的点也愈来愈普遍，我想大佬应该都是这样走过去的，那没啥好说的，咱们也走。
最后给你们看看我本身搞的一个项目管理模板吧，基本上能适用大部分项目了。
我是敖丙，一个在互联网苟且偷生的程序员。
你知道的越多，你不知道的越多
我不想被白嫖，求点这里