Thumbs up again, a habit, micro-channel search [ Third Prince Ao propyl ] concerned about the Internet beds many programmers.
This article GitHub https://github.com/JavaFamily already been included, there are first-tier manufacturers and test sites full interview series.
Foreword
My readers seem mostly students, and then we recently asked more of a topic is the maker of the development process, are more curious is how the whole process operations.
I will not BB, that below follow the warm male footsteps, he went into the development process manufacturers.
text
We take a look at what a product development process, the development process handsome Ali propylene with their own contacts, for example, which basically is the Internet giant's development process, and the details may differ, but absolutely similar.
I asked the next byte, a lot, Tencent friends differ significantly, so it is still representative.
Watching the process we have to look at every aspect of one point did some of what we have developed in this part of the students need Zuosa, and functions in every aspect.
Demand proposed:
The main part of the product father give us needs each requirement is that they want to come out from the user, or their own brains, but the product still not sure my father can not be directly finalized, so we need all of us (product, UI discussion, front-end, back-end, client and test) together to see if this demand is reasonable, or whether it makes sense this demand, the ability to achieve the expected cost of the technology cycle and so on.
Once the chat has become, they will enter the next stage, he will not talk about trying to make you agree, then enter the next stage, know why I called product father , right?
PRD demands put forward:
This stage, the product will be based on the results of the first edition of my father talk down, roughly a Demo version of the PRD, prototype map will be drawn first edition, and accompanied by captions, all related to the business, as well as interactive details will be set out .
This is generally the FIG:
这个时候大家又会围绕这一版本去开会讨论，敲定细节，这个环节会久点，因为细节比较认真，逻辑也不能出错，还有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，技术难点都是你要面对的，不过没啥大问题，我们技术人嘛皮实能顶。
总结
产品研发流程大家是不是觉得有点复杂，或者觉得很多点有点小题大做了，不瞒你说，刚开始我也这么认为的，但是随着时间的推移，你会发现有时候越是这样规范，越是提升了效率，也提升了产品质量。
对自己设计的严苛也会让你的业务能力提升，开发考虑的点也越来越广泛，我想大佬应该都是这样走过去的，那没啥好说的，我们也走。
最后给大家看看我自己搞的一个项目管理模板吧，基本上能适用大部分项目了，要xmind格式的公众号回复【项目】即可。
我是敖丙，一个在互联网苟且偷生的程序员。
创作不易，不想被白嫖，各位的「三连」就是丙丙创作的最大动力，我们下篇文章见！
文章持续更新，可以微信搜索「 三太子敖丙 」第一时间阅读，回复【资料】【面试】【简历】有我准备的一线大厂面试资料和简历模板，本文 GitHub https://github.com/JavaFamily 已经收录，有大厂面试完整考点，欢迎Star。
你知道的越多，你不知道的越多
