14年前，作为一个后端新手，我在知乎上写下了第一个问题：
这是一个后端经典问题，如下：
我们先进入正题吧。
那时我刚加入阿里半年，平时只做一些零碎的后端工作，剪剪图片，写静态页面。 不知道企业级后端工程的概况。
工作本身没有什么可抱怨的，而且当时整体氛围还不错，但是我遇到了一个创业的机会，所以我开始准备离职创业。
创业这件事，意味着在离职之前，我必须尽可能早地了解公司发展历程的概况。 其实，创业初期的人并不多，一个人被几个人用的情况很常见。 作为技术伙伴，我需要能够独立。
回到题外话。
没想到的是，我发布问题后不到2小时，后端大佬张云龙就来解答了（早期的后端大鳄，不知道的可以搜一下它）。
云龙哥又搬了一个好评帖子，正好完美回答了我的问题。
整个答案精辟且易于理解。 即使放在10年后，整套工程解决方案也不会过时。
()
那么我为什么要提起这个老故事呢？
是因为，在写文章的三个月里，我接触到了一些“新”的前端小白。 他们实际上比我晚了六年进入这个领域。 普遍的疑惑和六年前的我几乎一样。
有的刚开始学习前端三件套（Html、Css、Js）； 有的学完三件套后开始学习UI框架（React/Vue）； 有的在学习了UI框架后开始学习Redux、RxJs、Nuxt、Next、Nest、Node、Deno……一堆一辈子学不完的杂乱“轮子”。
学习能力低的人很快就被“轮子”说服了； 学习能力强的人学完后学不会，开始着急，出来后不知道该学哪个方向，于是异口同声地问到了这个问题：
“大公司的后端开发是什么样的？”
这和原来的我很相似。
而后端工程师的成长分界线就在这里。
中级工程师常常只是呆在各种轮子前面，痴迷地啃咬和徘徊。 中层工程师将目光重新转向软件开发的本质问题：工程。
没错，无论时代如何发展，框架如何推陈出新，程序员要面对的一个永恒的问题是工程问题，而不是特定框架或库的句型问题。
从这个意义上来说，虽然后端和前端的界限早已模糊，但大厂的中层工程师大多也会是全栈工程师。 他们日常的工作就是利用工程方法一一解决复杂的问题。
所以你会发现，大厂的后端鳄鱼，日常研究的东西可能早已脱离了你所了解的“前端”领域，它们不再屈服于一亩三分地的HTML，而是遵循不同的业务场景和不同的问题领域将求知之网撒向更广阔的世界。
为了弄清楚大工厂的后端是什么样子，可以分为两个主题：
1、大厂的企业级发展流程是怎样的？
2、大厂的后端大鳄一般都是做什么的？
再说一句，很多朋友反映文章太长，看不懂，所以我打算分成两篇文章来澄清这个问题。 明天我先讲第一个问题。
按照惯例，先从一张图开始：
这是我绘制的需求开发过程的简化模型。 实际的生产过程可能比这更复杂。 不过，虽然简化了，但是这个模型对于 DevOps 来说基本是完整的，所以我们会用它来扩展。
预赛阶段
软件工程的后期环节位于图片左上方，包括“发现商机”、“设定目标”和“建立项目”三个环节。
很容易理解为什么称为后处理。 软件诞生的意义一定是为了解决某个现实问题，从而获得一定的商业回报。 因此，进入软件工程之前的准备和探索工作自然是后期环节。
这部分一般是公司内业务领导关心的，而产研团队通常是接触不到的，所以不多说，合并到一起，快速跳过。
需求排序 需求排序
需求梳理可以定义为“需求分析”和“需求拆解”。
说到需求分析，就不得不奉上这张经典图：
动画很直观，我就不过多解释了，或许可以充分说明需求分析环节的复杂性和重要性。
不同角色和能力的人在面对相同的需求时往往会表达截然不同的理解。 而一旦理解错误，就会将错误的需求层层传递下去。
很多团队对这个环节掉以轻心，不认真对待，经常提出一些“口头要求”，这实际上是极其不负责任的行为，轻则浪费人力、返工，导致交付延误，重则造成生产事故和团队矛盾。
我们来谈谈需求拆解。 这部分也是日常工作中最容易被忽视的环节，但即使资历丰富的职场老手也未必真正懂得如何合理拆解需求。
“UserStory”用户故事拆分，是敏捷交付团队中最常用、最有效的需求拆解方法，其目的是将复杂的事务拆分成更精细的细节，从而增加复杂性。
一般来说，可以从上到下拆解为Epic->Feature->Story。
拆解原理请参考INVEST指南，参考链接：（助记词）
这部分内容也很复杂。 如果有机会单独开聊，我就不会在这里继续了。
产品设计Product Design
在消费互联网兴起的时代，所谓toC产品，产品设计基本上是强烈依赖于产品规划师（我个人不太喜欢产品总监这个词，我更喜欢区分为产品规划和产品运营） ）。
而在当前工业互联网时代，即流行的toB/G产品中，技术人员也参与甚至主导了产品的设计工作。
为什么会发生这些根本性的变化？
本质上是由于产品功能和定位所需技能点的变化。 ToB产品的诞生是为了解决个别行业、领域、业务流程的效率问题，而流程（Flow）的重点是逻辑。 在流程设计中，需要大量的领域知识和技术背景来提高流程的效率。
因此，在互联网发展重心转移到工业互联网之后，“产品技术人员”和“技术产品总监”变得越来越稀缺和重要。
事实上，产品设计流程直接决定了产品的有效性，但并不意味着只有产品总监才能做到这一点。 一名优秀的中级工程师还应该具备一定的产品思维能力。
指标制定 指标制定
很多产研团队在做产品的时候，往往收到需求文件后就直接开始工作，有意无意地跳过了指标制定的环节。
到了绩效考核或者晋升答辩的时候，我就尽力从各地搜救一些“数据”结果来佐证我“做了很多了不起的事情”的推论。
显然，这些即兴的事情往往收效不大。 收集的数据不完整或不正确。 如果你只是将它们提供给你的举报人，那么很难不被抓住。
因此，做事之前设定目标就变得越来越重要。
好了，现在你已经有了设置指标的意识，那么如何设置指标呢？ 这是另一个长期存在的问题。 据我不完全统计，我身边90%的人都不知道如何设定目标。 我还在大工厂，周围的学生都很优秀。 这个比例如果放在中小企业身上，恐怕就得被夸大了。
首先，你需要分清楚目标和指标之间的区别。
目标是终点，是本次研发工作的结果，是某个问题的解决方案。 该指标是用来衡量成果是否实现的参考维度。
那么如何设定指标才合理、真实、有效呢？
这件事和目标关系不大，和你要解决的问题、你想做的事密切相关。
最好设定产值指标，无非是一定时期内实现营业额多少、收入多少、增长多少。 达到与否是另外一回事，但指标是直观、明显的。
基础设施技术指标也很容易确定。 比如需要优化某个页面的首屏渲染时间、3秒首开率、4个9的系统稳定性等等。 这些指标也可以直接获得。
最麻烦的是面向业务的技术指标的制定。 这部分特别考验一个技术人员的技能。
举个反例，你收到一个做页面A的请求，用于“拉新品、推广活动”。 页面完成并上线后，产品朋友收到了他想要的PV/UV/转化率，自豪地访问了网站。 我去巴结老板了，那么作为一个技术人员，你的贡献在哪里呢？
PV/UV下降了1000%，和你的代码有关系吗？ 好像有，又好像没有……你是否经常陷入这些烦恼？ 没错，你的麻烦就是因为你没有一个强有力的指标来证明你的代码和运行结果之间的相关性。
也是因为你无法证明，所以你才干了所有脏活累活。 你加班加点努力编码，没想到却给产品朋友打工。 看着他们拿着大量奖金的背影，我留下了嫉妒的泪水……
到目前为止，指标如何设置，感兴趣的可以评论区交流。
这部分是我们技术人员最熟悉的，我平时写的文章也大多在这部分，所以就不多说了，直接跳过。
联调集成调试
联调分为单独多模块联调和多人综合联调两种。
后者的通病是在全栈开发中，同一个人需要同时开发多个终端或者多个仓库，尤其是在MonoRepo兴起的当下，多模块调试方式就显得非常重要，这直接影响你的开发舒适度。
前者较为传统，主要矛盾是多人之间的协调与依赖冲突。
小团队在这方面可能没有太多痛点。 虽然人少，但也不需要协调。
当团队规模缩小时，协作痛点就会显现出来，例如：
1.你的代码总是与别人产生冲突，并且需要花费很多努力来解决它们。
2. 您未经测试的代码被“带到”线上。
3、前后端合约变更后，没有互相通知，导致程序bug。
4、多人并行开发不同需求，覆盖彼此的联调环境。
5、前后端进度不一致，你等我我等你，就像牛郎织女一样。
事实上，问题还不止这些。 我只是举几个反例来说明，虽然上海调联的问题和挑战不小，但团队越大，挑战就越大。 事实上，长期以来针对此类问题已有多种解决方案。 如果您有兴趣，请留言告诉我。
测试
测试的话题就更大了，简单说一下。
在早期互联网的狂野时代，测试员很受欢迎，他们的工资也很高，因为他们极其重要！ 公司愿意花重金组建测试团队，为他们配备各种高端终端设备，尽最大努力为业务代码寻找Bug。
在研发朋友眼里，客户不是父亲，测试才是真正的母亲！ 在团队中的地位非常高。 开发朋友们甚至不怕代码有很多bug，就怕测试人员发现bug。
你正在写代码，唱着歌，突然弹出一个弹窗“某测试人员刚刚给你提交了Bug Ticket，请尽快处理”，也可以直接在群里发帖@you bug画面，那种心情，就像“当你和伴侣做爱时，有人踢开门，让你出去清理旁边的垃圾”，经历过的人都明白。
然而，测试人员的好日子还没有过去几年。 不知道后端死没死。 测试岗真是死了（没死，只是岗位需求不多）。
其实，这并不意味着测试不重要，相反，测试仍然非常重要，甚至比编码本身还重要。 然而，随着DevOps的发展css流程图，代码质量保证的工作迅速左移，并通过一系列手动工具，完全融入到软件工程的整个生命周期中。
有趣的是，随着人工智能技术的发展，越来越多的人正在使用大型模型来帮助审查自己的代码并测试自己的软件。 这绝对是一次有趣的尝试。
CR 代码审查
说起CodeReview，让我想起了我火热的“掘金”水文：“8种能让队友笑死的石山代码”（）。
我发现你们很喜欢讨论这个话题。 评论区里，你贴出你遇到的各种不好的代码，也在我的技术群里。 每次说到CR，群里就沸腾了：
从前面的现象也可以看出CodeReview在软件开发周期中非常重要。 你可以选择跳过这个环节，你的队友需要承担这个跳过的费用。
所以如果你是一个团队管理者，你要做的第一件事就是严格执行CodeReview，否则你会吃亏的。
至于什么样的代码才是好代码，这可能就是“代码可读性”的话题了。 我会找机会给大家介绍一下Goose Factory是如何利用这个Readability的。 要知道鹅厂还专门建立了培训考试制度，虽然这种行为在公司内部广受诟病，但对代码质量的整改效果还是很明显的。
CICD-持续集成/部署
CICD，全称“持续集成”和“持续部署”，属于开发工作流程（WorkFlow）手动化中最重要的环节。
刚入行的时候，刀耕火种的时代，根本没有CICD，代码在本地用一系列脚本（Grunt、Gulp、Bower等）进行改进：mixin、compile 、简化（minify）、打包等，然后将压缩包上传到服务器，解压运行。
对于习惯了 CICD 的新一代程序员来说，很难感受到那种原始行为的酸涩。 整个过程非常繁琐冗长，而且与编码无关，但每一步操作都非常危险且不稳定。 即使漏了一个文件，漏了一个步骤，也会出现线上故障，你就拎桶跑了。
而且过去每个团队都会设立一个专门的运维岗位，由这个朋友来负责为你维护服务器部署、伸缩等日常事务。
也就是说，在这样的背景下，DevOps应运而生，带来了CICD工具链，杀掉了一个个人的肉环节，同时杀掉了每一个运维人员，专注于降本增效！
研发和码农只需要负责写自己的代码，剩下的就交给CICD一站式服务，这是极其难受的！
10
初试是最有可能形成骂战的环节。
一般情况下，首先检查功能的是请求者，而第一位检查者的质量决定了发生出血事件的可能性有多大。 一个不合格的初次测试者，以前没有任何计划，一上来就玩你的结果，然后问你一堆“经验问题”，更有什者，他直接提出了一个问题。为您提供错误票。
你一定会问，难道不应该提一个bug吗？
应该！ 而且你首先要认清你所提到的到底是Bug还是Feature。 这就是开发人员和初始测试人员频繁红脸的根源。
那么哪些是错误，哪些是功能，哪些是优化？ 最初的测试用例拥有最终决定权。
一个优秀的初始测试人员（通常是产品总监）应该在需求提出时、编码开始之前拟定一系列初始测试用例，然后邀请开发朋友一起回顾这些用例。 这相当于提前制定了一个契约：“我们提前约定好，严格按照用例来开发，凡是不符合的都将被视为bug”。
这样，出血冲突就会少一些，开发者也会避免过度设计和冗余设计的问题。 根据用例进行开发既简单又无麻烦。 这就是所谓的“用例驱动开发”，按照实现方式可以分为“TDD”和“BDD”。
未通过的用例被认为是bug，未充分覆盖的用例被认为是特性，用例范围内的体验改进被认为是优化。
完美的。
11
发布
代码发布，虽然CICD链接中有很多知识点，虽然CD是持续部署，也就是发布，但是后面的CD链接特指非迫在眉睫的环境发布。
那么，在即将发布的版本中，有哪些内容值得讨论呢？ 有很多话要说！
你还记得我在文章开头贴的那张图片吗？ 9年前我在知乎上问的第一个问题是与发布相关的：“静态资源的覆盖和非覆盖发布”
这个问题可以延伸，因为它的本质是问“如何实现无损发布”。
这个话题看似简单，但据我了解，很多中小企业不具备无损释放的基础设施和研发人员素质。 为了保证服务稳定，他们只能被迫采用“人肉无损”的方法：熬夜发布！
别笑，我相信看过我文章的团队一半以上都是这个水平。 能力不足，就用生命来弥补吧！
我儿子公司的研发团队是这样的。 他们时不时地告诉我，他们明天晚些时候会回去，并且会发布一个版本。 之后我就开灯等她回去，经常等到晚上三点……
我说大家发育得有多差，就不能毫发无损的放出来吗？ 晚上舒舒服服地释放一下，白天舒舒服服地躺在床上看电视、玩游戏，岂不是很好吗？
她告诉我他们不会开发它。
事实上，这不能归咎于他们的发展。 为了确保无损释放，需要做大量的基础设施工作和规划工作。 要怪的话，只能怪他们技术领导的无能。
要实现无损发布，这里的知识点相当多，包括但不限于：需求拆解、依赖剥离、同源异构、特性切换、灰度发布、快速回滚、高贵降级、热更新等。
还是那句话，如果你对这个话题感兴趣，请在评论区留言，聊起来干货满满。
12
数据收集DataCollection
终于到达最后一个链接了！
虽然很多团队在最后一个环节（发布）就已经完成了迭代，但实际上，在“持续交付”双循环中，一切才刚刚开始。
还记得我们在软件开发之前所做的“指标开发”吗？
没错，当时制定的指标就是为了这个环节的“数据采集”。 通过日志、监控、埋点上报等方式，收集一系列关键指标数据进行统计分析。 对迭代结果进行评估和考虑，并指出你的软件产品的下一步迭代方向。
这就是著名的“数据驱动”！
你是否已经听过这个词一百遍了，但你就是不知道它是什么样子？ 哈哈，从头再读一遍我的文章，你就会知道数据驱动的本质和技巧了。
这不仅是最后一个环节，也是新一轮迭代的第一个环节。
以终为始，才是“XX驱动”的精髓。
好的！ 本来想写一篇简单的文章给大家展示一下大厂的研发过程。 没想到，虽然我极力控制字数css流程图，甚至跳过了很多地方，但还是控制不了长度。
这个简化的开发过程模型的每个环节都值得写一篇大文章，而且篇幅有限。 我只能带你看这里，然后点到最后。
如果您有兴趣，欢迎留言。 如果呼声高的话我会花时间把这个系列完整的写下来。
明天就酱了，你学业有失吗？
