5
编码 Coding
这部分是咱技术人员最熟悉的，平时我写的文章也多半都在这部分，所以就不多说了，跳过。
6
联调 Intergrated Debug
联调分两种，个人多模块联调和多人集成联调。
前者常见的问题就是在全栈开发中，同一个人需要涉及多个端或多个仓库的同时开发，尤其是在MonoRepo盛行的当下，多模块调试方法很重要，直接影响你的开发舒适度。
后者更为传统，主要矛盾就是多人之间的协同和依赖冲突问题。
小团队在这块的痛点可能并不多，毕竟人少，也不需要协同，需求来了一把梭，干就完了。
当团队规模增大后，协作痛点就凸显出来了，比如：
1. 你的代码总是和别人产生冲突，解决起来贼费劲。
2. 你尚未验收的代码被人“带”上了线。
3. 前后端协议变更后没有相互通知，导致程序Bug。
4. 多人并行开发不同需求，相互覆盖彼此的联调环境。
5. 前后端进度不一致，你等我来我等你，就像牛郎和织女。
问题当然不止这些，只是简单举几个例子，说明下联调这一块的问题和挑战其实也是不小的，团队越大，挑战越大。当然了，这些问题早就有相应的各种解决方案，感兴趣的留言告诉我。
7
测试 Testing
测试这个话题就更大了，简单聊聊吧。
早期互联网蛮荒时代，测试人员是很吃香的，薪酬待遇也很高，因为他们非常重要！公司愿意花很多钱专门养一个测试团队，给他们配置各种高中低端的终端设备，想方设法的给业务代码找Bug。在研发同学眼里，客户都不算是爸爸，测试才是真爸爸！在团队里地位非常高。研发同学甚至不怕代码Bug多，就怕被测试人员发现Bug。
你正写着代码唱着歌呢，突然飘出一个弹窗 “某某测试人员刚给你提了一个Bug单，请尽快处理“，或者直接在群里@你，噼里啪啦一顿发Bug图，那种心情，就像是「正在和对象你侬我侬的时候被人一脚踢开门，让你出去扫一下门口的垃圾」，经历过的人都懂。
不过，测试人员的好日子没过几年，前端死不死我不知道，测试岗是真死了（倒也没有死绝，只是岗位需求不多了）。
当然了，这并不是意味着测试不重要了，恰恰相反，测试依然非常重要，甚至比编码本身都重要。只不过，随着Devops的发展，代码质量保证工作迅速的左移了，通过一系列自动化工具，完全融入了软件工程的全生命周期里。
说点好玩的，随着AI技术的发展，越来越多人开始用大模型来帮助review自己的代码，测试自己的软件了，这绝对是一个有意思的尝试。
8
CR - Code Review
说到Code Review，又让我想起我那篇火爆「掘金」的水文：
我发现大家伙很喜欢讨论这个话题，评论区里各种晒自己遇到的劣质代码，我的技术群里也是，每次聊起CR，群里就沸腾了：
从上面的现象也可以看出来，Code Review在软件开发周期里极其重要，你可以选择跳过这个环节，但是你的队友也因此需要承担这份跳过的代价。
所以如果你是一个团队管理者，你要做的第一件事，就是把Code Review严格执行起来，否则你就是在造孽。
至于什么样的代码才是好代码，这其实就是「代码可读性」(Readability)的话题了，后面找机会给大家介绍一下鹅厂是怎么玩这个Readability的，要知道，鹅厂为此还专门搞了个培训和考试体系出来，虽说这个行为在司内广为诟病，但是对代码质量的治理效果还是显而易见的。
9
CICD - Continuous Integration / Deployment
CICD，就是「持续集成」和「持续部署」，属于研发工作流(Work Flow)自动化中最为重要的一个环节。
在我刚入行的时候，那个刀耕火种的时代，根本没有CICD，代码都是自己在本地用一系列脚本（Grunt，Gulp，Bower等）进行构建：混淆(mixin)，编译，简化(minify)，打包等等，然后把压缩包人肉上传到服务器上，解压运行。
早已习惯了CICD的新生代程序员们，是无法体会那种原始行为的酸爽的。整个过程非常冗长繁杂，和编码无关，但每一步操作都极其高危且不稳定，但凡漏了一个文件，或者少了一个步骤，就会产生线上故障，提桶跑路。
而且以前每个团队还会专门设置一个运维岗，这个同学专门为大家负责维护服务器的部署，扩缩容等常规性事务。
也就是在这样的大背景下，Devops应运而生，带着CICD工具链干掉了一个个人肉环节，同时也干掉了一个个运维人员，主打一个降本增效！
研发编码人员只需要负责写好自己的代码，剩下的事情就交给CICD一条龙服务了，不可谓不爽！
10
验收 Acceptance
验收，是最容易产生撕逼的环节。通常情况下，都是需求提出人来验收功能，而验收人员的素质决定了有多大概率会出现流血事件。一个不合格的验收人，往往事前啥也没准备，一上来就把玩你的成果，然后给你提一堆的「体验问题」，更过分的，则是直接给你提Bug单。你要问了，不该提Bug吗？该！但是你首先要搞清楚你提的是一个Bug，还是一个Feature。这，就是研发人员和验收人员常常撕得面红耳赤的源头。那么究竟什么才是Bug，什么算是Feature，什么又是优化呢？验收用例说了算。
一个优秀的验收人（通常是产品经理），应该在需求提出时，编码开始前，就制定好一系列验收用例，然后拉研发同学一起过用例评审。这就相当于提前拟定了一份契约：“咱可事先说好了啊，严格按照用例来开发，不符合的一律算Bug”。
这样一来，流血冲突事件少了不说，研发人员也避免了过度设计，冗余设计的毛病。对照着用例进行开发，简单省事，这也就是所谓的「用例驱动开发」，按照实现方式又可以分为「TDD」和「BDD」。
用例不通过算Bug，用例覆盖不足算Feature，用例范围内体验改善算优化。
完美。
11
发布 Publish
代码发布，其实有不少知识点在CICD那一环节，毕竟CD就是持续部署，说的就是发布，只不过前面的CD环节特指非正式环境发布。
那么正式发布又有什么东西可聊呢？可聊的多了！
还记得文章开头我贴的那张图么，9年前我在知乎上问的第一个问题就是和发布相关：「静态资源的覆盖式发布和非覆盖式发布」
这个问题是可以延展的，因为其本质其实是在问 「如何实现无损发布」。
这个话题看起来简单，但据我了解，很多中小公司根本不具备无损发布的基建设施，和研发人员素质，他们为了保证服务稳定性，只能被迫采用「人肉无损」的方式：通宵发布！
你可别笑，我相信看我文章的各位，有一大半的团队都是这个水平。能力不足，拿命来凑！我老婆她们公司的研发团队就是这样的，隔三差五就跟我说，今天要晚点回家了，有版本发布。然后我开着灯等她回来，经常一等就是等到凌晨3点……我说你们研发是有多差啊，就不能做到无损发布吗？白天开开心心发布完，晚上舒舒服服躺床上看电视打游戏不香吗？她跟我说，他们研发不会。当然也不能怪他们研发，要保证无损发布，得做不少基建工作和准备工作，要怪也只能怪他们的技术leader没本事，大头兵有什么错。
要做到无损发布，这里的知识点也蛮多，包括但不限于：需求拆解，依赖剥离，同源异构，特性开关，灰度发布，快速回滚，优雅降级，热更新等等。
还是那句话，对这个话题感兴趣的，评论区留言吧，展开聊又是一大篇满满的干货。
12
数据收集 Data Collection
终于到了最后一个环节！
很多团队其实在上一个环节（发布）就已经结束迭代了，然而事实上，在「持续交付」双循环里，一切才刚刚开始。
还记得我们一开始在软件开发之前做的「指标制定」吗？
没错，那时候制定出的指标，就是在这个环节进行「数据收集」的，通过日志，监控，埋点上报等方式，收集一系列关键指标数据，进行统计分析，从而对你本次的迭代成果做考评和审视，并对你软件产品的下一步迭代方向指明道路。
这，就是大名鼎鼎的「数据驱动」！是不是听过一百遍这个词了，就是不知道长啥样哈哈，把我这篇文章从头再看一遍，你就知道数据驱动的精髓和方法了。
这既是最后一个环节，也是新一轮迭代的第一个环节。
以终为始，便是「XX驱动」的本质。
好啦！本来想简简单单写一篇文章，带大家窥探一下大厂的研发流程，没想到即使我努力控制字数，甚至很多地方都不断跳过略过，依然控制不住篇幅。
这个研发流程简化模型，每一个环节都值得一大篇文章细说，篇幅有限，我这里也只能带大家走马观花看一遍，点到为止。
有感兴趣的欢迎留言，呼声高的话，我就抽空把这个系列完完整整的写出来。
今天就酱，你学废了吗？
