⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 zhuanlan.zhihu.com/p/485029198 「Bai Bing」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

遗憾的是，我转正后看到了大家的能力和努力，也意识到在预期的时间内难以达到我想要的高度，最终经过各方面的考虑，决定放弃这个职位，重新回到外企找回适合我的节奏。

依依不舍的离职后，回想起来，觉得我在华为的经历特别珍贵，所以在此做个记录。

试用期与加班工资

一般而言，试用期持续的时间为3-6 个月，工资、奖金都按正式员工的标准计算。据我所知，唯一的区别在于，试用期的员工，周末加班不能转调休，相当于白加班。因此，不到最忙的时候，组长（PL）不会叫试用期的员工周末加班，如果非得加班，也会通过外出公干的方式让他们调休。

我听前辈们说，在2019年~2020年的时候，由于华为被美国制裁，曾采取过所谓的战时状态，那时候的压力是最大的。作为补偿，华为也额外划拨了资金进行激励：正式员工周末加班，会直接换算成双倍工资下个月发。如果周末两天都加班，双倍工资就是4天，这样相当于基本工资涨80%，接近翻倍了。当然，这种连续的周末加班也很消耗精力，无论你有多么强的体魄或是多么年轻，最终都不得不承认：命要紧。

现在周末加班，依然按双倍工资计算，但不会下月发，而是给你累计，直到8年一次换工号，或者离职的时候，才会统一给你结清。并且，周末加班也需要主管审批，不再按打卡时间直接计算。

随着工作的深入，我逐渐开始理解华为制定一些政策的原因，开始理解它为了获得最大的收益而做出的取舍。

招聘

我们刚毕业那会，就听说过华为只要是985/211的学生就招，编程题通过就行，几乎不看你的个人经历。当时我不理解，觉得这样很容易招到一群废物进来啊？

进来以后我发现，华为会以不信任员工为基础，建立一套完善的制度和流程让员工把活干漂亮。承受不了压力的人被淘汰，承受住压力并遵从制度和流程的人能活下去，在这基础上智商、情商特别高的人会拿钱到手软。

在这边，每个员工都可能参与招聘，这几乎成了他们在华为职业生涯中的必经之路。他们会根据现有的人才库，挨个打电话询问就职意愿，并引导他们做面试题、在线编程并参与面试官的1对1面试。

我猜测可能是存储的预算不太够，因此招聘的时候倾向于招OD/WX的员工。OD的员工工号以300开头，WX的员工工号以WX开头，这两种员工都不算华为的正式员工，其中OD的员工相对更优秀些，主要从事开发工作。而WX开头的员工基本只能从事测试工作，他们按照测试文档一步步执行并查看是否符合预期，绝大多数WX员工并不知道自己为什么要这么执行，预期的结果代表着什么，因为他们没有资格参加方案的设计和串讲，也没有TDE(Test Design Engineer，负责设计测试用例的华为员工)愿意跟他们讲解。

由于存储这边的人员流失较大，因此招聘的任务就很重。同时，存储又倾向于招聘OD/WX的员工，所以招聘难度会很大。总结一下就是：有能力的人看不上OD/WX，没有能力的人又过不了在线编程等考核。

月度答辩和转正答辩

在试用期，每个月都会有一次月度答辩，你要做PPT详细描述在这一个月内你做了啥，学到了啥，并现场回答评委的问题。在转正那一次，又需要准备转正答辩，把整个试用期的工作进行总结。

幸运的是，由于项目过于紧张，最终我从试用期到转正仅仅参与过3次答辩，包括转正答辩。

在答辩过程中，评委们都会认真听你讲，并经过思考询问你一些问题，这种气氛还是不错的。实际上，答辩对绩效的作用并不是特别大，因为你平时做的事情大家都能看到，也能估算出分量。

答辩最大的作用，在于防止新员工偷懒。当一名员工进入公司后，在完全熟悉流程，成为一颗忙碌的螺丝钉之前，会有短暂的空窗期。在这个阶段，由于你啥也不懂，没人会找你，也没法给你分配任务。这时，如果你知道每个月都需要报告工作和学习进展，就会产生足够的动力，尽快融入团队。

转正答辩完成后，基本上你已经是一颗标准的螺丝钉了，这时候不再需要答辩，通过绩效考核进行激励即可。

可信认证

对于存储的开发而言，每个人都需要通过可信考试。

可信考试分专业级和工作级，一共四门课，四个考试，往往新来的员工更容易通过，因为他们有更充足的时间；而老员工没有时间学习，几乎都是裸考，最多有一两个晚上的时间看资料，因此通过率更低。

我比较幸运，很容易就通过了专业级（毕竟要求17级及以上的员工必须通过专业级）。从我的角度看，可信认证的知识真的总结的挺好，是下了功夫归纳的，除了科目一的在线编程，其他科都是理论知识，涵盖的范围包括编程语言语法和技巧、编程语言规范、需求分析、安全红线、设计模式、敏捷开发等等。我在阅读那些学习课程和资料时，有强烈的似曾相识感觉，因为很多都是我经历过的场景，摔过的坑。这些经验被总结成精炼的语言，通过以考促训的思想灌输到每个员工的脑子里。

可惜的是，由于极大的工作强度，所有人都是以通过认证为目标。他们几乎不看课程和资料，直接在心声论坛里面搜索往期的考题，背答案，以尽可能快的速度通过考试，白白浪费了好多精典的资料，这一点挺遗憾的。

接口人

从入职到导师脱手，其实就差不多两个月时间。这段时间应该是最幸福的时光，最重要的任务就是通过可信考试。两个月后，开始接手一些简单的任务，修改问题单或者承担一些简单的功能开发。

但在一些部门，这时候往往会给你一个恐怖的任务--接口人。

一般而言，一个产品会被分为多个模块，每个小组维护一个或多个模块。当测试发现属于某个组的模块出现问题，或者别的模块依赖该模块的部分工作不正常时，他们需要有人能帮忙查看原因，这个人就叫接口人。

一个组大概10个人，负责的模块代码量在数十~数百万行的级别。乍一看，会觉得应该选一个经验丰富的员工，对组内负责的模块、历史情况等掌握很清楚的人作为接口人。但实际上，帮他人看问题找原因，是一种吃力不讨好的工作，因为领导看不到，身边的同事也感知不到。

在外企，这个接口人通常是主管(Manager)。他会对问题进行简单的分析，再根据组内成员的擅长领域、负载情况，选择合适的开发去分析该问题。在华为，类似的岗位是PL，为了绩效，他们不可能每天把时间浪费在这上面。同时，组内的每个人都忙得要命，最熟悉该领域的人可能正在完成紧急任务，根本没时间去分析。因此，PL通常会找组内资历浅一些的同事去充当接口人，并按固定期限轮换。

一个组维护的代码量不算小，让新员工去做接口人，美其名曰“锻炼”，实际上是让他去抗压。作为接口人，PL的要求就是尽可能不打扰到组内其他人，所有问题，除非真正是Bug，否则不能让测试提单。这样的要求看似简单，但对于新员工而言，很多时候测试咨询的问题你连他讲的啥意思都不明白，再加上设计又存在各种历史原因、特殊情况的考虑，新员工大多是懵逼的。想求助经验丰富的同事？如果项目不太紧张的时候还好说，项目紧张起来，每个人都戴着耳机在通话，你可能好几个小时都见不到他们空闲下来。而测试对你的响应时间是有要求的，一小时不给清楚解释？那就提单吧。

举个例子：你在分析A问题发生的原因，阅读完全陌生的代码，另外2个测试给你留言，找你咨询B、C问题。你简单扫了一下B、C问题，都不是你熟悉的领域，需要花时间去读代码，了解设计，才知道是不是问题，所以你暂时没回复。两分钟后，两个测试分别给你打电话，你很烦，不想接电话，但他们不停的打，并在留言中告诉你再不接电话就提单。你只能接起电话好言相劝，告诉他们现在真的很忙，只能请他们先登记，排队等你的消息。没多久，你读到A问题中一部分看不明白的逻辑，想找人问，一抬头组内所有人都在打电话。于是你咬咬牙一边跟A的测试确认测试用例的逻辑，一边忽略部分看不懂的代码去猜测后续的逻辑。这时候B、C的测试告诉你不能再等了，上面催着要提单，你只能暂时放下代码再次解释，给他们合理的截止期限并请求他们接受。突然电话又响了，是一个电话会议，问题很严重，线上四五个开发正在一起讨论，需要你做确认，TDE催促让你赶紧看，搞不定就往上捅。你赶紧放下A问题，一边读D问题的现象，一边凭你的理解去回答这几个开发的问题。D问题的难度不大，但涉及的条件特别多，变量也多，逻辑很绕，你得理一下，正在理的过程中，A测试的TDE气愤的给你留言：都看了两个小时了怎么还没结果？必须提单了。

如果实在搞不定了，测试等不及要提单，一般是要跟PL讲的。但作为新员工，你要做好心理准备，因为这时候免不了一顿臭骂。因为PL永远是忙得要死，他有方案要讨论，有设计要做，还有大量组内杂事，本来已经焦头烂额，你不仅不能帮他分担，还告诉他现有的某个问题搞不明白，他也是很崩溃的。但这顿骂往往又是值得的，因为PL会快速给你指明方向，因为如果是定位偏了，他会快速纠正你的方向（顺带着烦躁的大骂几句）。

这大概就是接口人的工作状态。上午9：40~11：30，中午14：30~18：00，晚上19：30~21：30是高峰期。

问题单

刚才提到很多次“提单”，就是指的问题单。测试提的问题单，一般代表某个模块的功能有Bug。

问题单的跟踪，华为有一套系统叫DTS，测试提单，开发解决的流程大致如下：

测试外包员工在DTS系统中创建一个问题单，填写产品、版本、问题描述等信息。
问题单提给负责该模块的测试TDE（华为正式员工）审核。
测试TDE把问题单转发给负责该模块开发的组内PL。
组内PL再把问题转发给需要解决该问题的开发。
开发把问题解决，提交代码，填写根因分析并把问题单转给组内PL。
开发同时需要与测试TDE预约时间，与测试TDE串讲问题单发生的原因和修改后的影响。
组内PL等串讲完成并且最新的Build包含开发的CommitId后，将问题单转给测试TDE。
测试TDE将问题单转交给测试外包员工进行验证。

这么一套流程走下来，感觉脱了层皮。这大概就是所有开发都闻问题单色变的原因吧。

对于上级领导来说，他不需要知道细节，只需要要求一个组的问题单的目标数量即可。比如今天整个组剩下40个问题单，明天的要求是35个，后天是30个...

于是，为了达成目标，PL非常反感问题单走到自己组头上。有的问题单涉及到模块间的协调处理，测试提单的时候发现的是A模块的问题，但A模块经研究后发现，实际问题出在A模块依赖的B模块身上，B模块由另一个组维护，于是跟B模块的接口人沟通。这种情况，即使已经基本确定是B模块的问题，B模块的PL、接口人也会想尽一切办法拖延问题单走给B模块的时间，定位问题根因和修改方案后，才会同意问题走到B模块。毕竟每天的问题单目标放在那里，多一个在自己头上，都是沉重的负担！这种时候，A模块的PL肯定也不希望问题单在自己组，所以这时候就看他们两个PL的PK了，作为PL，至少都在华为奋斗了好几年，大家像战友一样有感情，互相理解下，这次留给你，下次留给我，互相不撕破脸。

在这套流程中，开发最不喜欢的步骤就是测试串讲。这个设计的初衷是好的：担心你的改动造成的影响测试不清楚，从而无法对受影响的场景进行测试。但遗憾的就是这个规定太死板，绝大多数的串讲根本没有意义，只需要测试进行原场景复现，并检查问题是否解决即可。

我觉得之所以问题单的设计如此复杂，依然是对员工的不信任。在外企，流程就简单多了：

测试创建问题单，填写产品、版本、问题描述等信息。
问题单提给需要解决该问题的开发者。
开发把问题解决，提交代码，填写根因分析和需要重点测试的场景，把单转回给测试验证。

步骤的简化，就对员工的素质要求高。就拿问题单与测试的串讲来说，一般开发人员觉得这个改动的影响比较大，可能需要重点测试一些场景的时候，就会在问题单上注明；同理，测试如果意识到开发人员的改动有风险，或者对开发人员的根因分析不太理解时，也会主动找开发人员沟通。

华为的流程复杂，它的基本逻辑是：信任DE/TDE这种在华为干了很长时间的优秀员工，新员工不值得信任。配套的激励也是倾向于PL/DE/TDE，这会让新员工做得很憋屈，但这没关系，因为总会过滤出一批忍得住憋屈，愿意遵从规则坚持努力下去的人。外企的流程简单，每个员工都干得很开心，但是如果出现一些想偷懒的员工，公司的确没有太多拿得出手的整治方法，顶多就是长期不涨工资。

复杂的流程导致了一个问题，就是测试TDE的繁忙程度超乎想象。因为一个测试TDE往往负责多个模块，也就是对应着多位开发，当问题单较多的时候，容易形成了单点瓶颈。举个例子，假设一名TDE手上有10个外包测试员工，分别测出了10个问题，这10个问题对应着8个开发，那这8个开发人员修复完问题后，跟外包测试员工串讲并不算数，必须排队给这名TDE串讲，从而形成了单点瓶颈。

测试TDE忙得找不着北，脾气自然也不会太好。开发更是一点也不敢得罪测试，如果TDE不爽你，别的不说，就单单在串讲里给你挑刺、或者把你的串讲排到最后，都会大大拖慢你的工作进度和工作热情。

代码检视与Committer

代码检视，也就是Code Review。每个开发写好代码后，都必须发代码检视才能合入主干分支。

在外企，一般开发会找对这个领域比较熟悉的两个开发进行检视，得到两个Approve以后，就顺手合入了。

在华为，代码合入理论上需要以下步骤：

选择两个开发检视
检视通过后选择一个Committer审核
审核通过后，选择具有合入权限的人合入。

一般Committer是在一个团队里的资深员工，技术比较强，并且做事仔细认真。

在一般开发阶段，权限会放松很多，步骤简化为：

选择一个开发检视
检视通过后找一个Commiter检视并审核再合入。

Committer的数量是很少的，大概占20%左右。100个人要合入代码，都得找这20个人进行代码审核。这部分人基本已经是DE(Design Engineer)，主要承担方案设计、困难问题攻关等任务，同时还要帮大量的同事检视代码。所以他们大多也会忙到找不到北。

这些Committer一方面承担着方案设计等项目上对自己未来有利的工作，另一方面检视所有人的代码，有任何问题得会得到耐心的解释（不解释清楚就不会给你审核通过），所以他们的进步会很快。而新员工大多只是执行者，对整体规划、背景原理等都搞不清楚，他们想让Committer耐心解释是不可能的，只有在审核代码的时候，能学到点东西，但也是零零碎碎的。

这样以来，新员工和老员工(Committer)的差距就拉开了。最终导致的结果就是知识断层，新员工很容易流失，因为他们只能在繁琐的工作之余进行自学，老员工没时间教他们；同时他们得到的激励也相对较少，除非拼死拼活爬到Commiter这个位置，否则未来的发展一片渺茫。

功能开发

一个需求过来，需要评估完成的时间。但这只是一个参考，每一级都会想办法把时间往短了压。导致最后到开发者这一层，几乎是不可能完成的任务。

举个例子，一个任务，参与设计的开发和测试预估12+4天，版本给的要求是10+3天，但当这个任务真正给到参与实现的开发和测试时，可能只剩下6+1.5天。

中间的时间到哪儿去了？从上到下，每一层领导都担心任务完不成，所以想预留一点缓冲。所以时间从10+3天传达到下层变成8+2.5天，逐渐往下最终变成6+1.5天。

所以，功能的开发极其紧迫，你想在规定的时间里完成几乎是不可能的。

一开始，我会因为完不成任务非常焦虑。后来我发现，原来大家都完不成，目标放在那儿成了摆设，虽然目标时间快到了就开始催，但实际上做不完也不会怎么样。不过，催你的人心里是有底线的，这个底线就是他的上级给他的要求，只是这个底线他永远不会告诉你。

出征海外

出征海外，一般是指的上一线去海外销售我们的存储产品，可以选择的驻扎地很多，几乎全球都可以。但是选择欧洲那些条件好的国家，补贴很少，选择非州那些条件不好的国家，补贴很给力。

在存储这边，每年需要出征海外的人数是有指标的，几乎每个团队都要出人。

除了极少数愿意舍家弃子去海外打拼的小伙伴，绝大多数人是不愿意去的。所以，要求你去海外，和逼你离职差不多，基本成了淘汰人的方式。

我看过几个能力还不错，经验也比较丰富的员工，被要求出征海外。他们虽然没有Committer这么拼，但五年左右的时间也让他们积累了很多知识，也算是骨干员工。无奈的是，由于这个硬性规定，不得不选择离开开发岗位。

其实我很不理解，这些工作五年左右的员工，对他工作过的模块应该是很熟悉了。好不容易达到了这样的水平，也适应了华为的工作强度。这时候应该是他们发光发热的最佳时期，但华为却让他们出征海外，重新招新员工进来再经历一次痛苦的学习和适应过程。

实际上，这些开发者的知识对海外销售而言起不到多大作用：你掌握了产品中你们组负责的某个模块，里面包含数百个结构体和数千个字段，你能理解每个字段的含义和设计它们的原因。所以呢？那又怎样？在销售的时候，客户对此是不感兴趣的。客户感兴趣的内容，还是需要参加培训才能掌握。那为什么不直接让新人去做销售呢？

选择离开

其实对我而言，钱给到位以后，最在意的有两点：

工作轻松
前途光明

这两点只要满足一点，我就不会考虑离职，如果两点都满足，那我会誓死效忠。

首先，主要是我自己的原因，因为我一直知道华为工作不轻松的。

我家离公司车程大约40公里，虽然楼下就有班车，但班车以早上08:30到达为目标（以行政的标准上班时间08:30~18:00为准）。所以发车时间为早上07:10，也就是说，我最迟06:50就得起床，刷牙洗脸后赶紧下楼上班车，然后在班车上摇摇晃晃的睡觉。

我有好几次做噩梦，梦到因为莫名其妙的原因导致没赶上班车，内心崩溃到了极点。

两个月后，我实在受不了，决定在公司附近租房，平时骑自行车上下班。这样，早上可以睡到08:50，每周末回去一次。一开始还好，但随着工作压力逐渐变大，周末慢慢开始变成单休，相当于我周六晚上回家，周日晚上10点左右，又得坐地铁回出租屋（为了周一早上睡个懒觉）。本来这样也能适应，但我女儿满一岁以后，变得越来越可爱，我舍不得那种离开她的感觉。我在家里客厅安装了一个360摄像头，每天吃晚饭的时候，就看着我妈和女儿玩耍，有时候透过摄像头喊一声“甜甜”，女儿以为摄像头就是我，经常仰着头对着摄像头喊爸爸，令人心酸。

其实在入职前，这个问题我也有想过。当时的想法是，在华为如果能安定下来，就在郫县租一套好点的房子，把一家人都接过来，每天中午可以跟家人吃个饭，晚上偶尔也可以跟家人一起吃饭。但后来我妈不太愿意搬走，我老婆也迟迟没有找到合适的房源，最后不了了之。另外，每天中午、每天晚上都要骑行5公里左右回去看一眼女儿，确实也挺折腾，加上工作越来越忙，人也越来越疲劳，哪怕真的兴师动众的搬到郫县，效果也不大了。

记得那段时间，最难受的就是每天晚上吃过晚饭，从园区散步回公司的那一刻。我会问自己，天已经黑了，我为什么还不能休息？我干的事情有多大价值，对我到底有多大吸引力？每天都这样，我该怎么享受生活？当时有句话特别火，叫青春才几年，疫情占三年。那种感觉类似于此。

其次，就是个人职业的发展问题了。

作为新员工，我所在的部门，我只能勉强跟入职一年左右的同事共事。有一种说法：你的绩效在PL给你分任务的时候就已经确定了，PL可以分给你有价值、有曝光度的重要任务，也可以分给你吃力不讨好的杂事。作为新人，自然是要从打杂开始，而身边的人都兢兢业业，我擅长的知识在这里又起不了作用，发展的前景可想而知了。

我仔细思考过，如果我要达到骨干的水平，至少也要两年的时间，这么长时间没有自己的生活，而且年龄越来越大，还面临被派去海外的风险，实在不值得。

跟我同级别的同事，基本都是DE，他们在存储工作的时间大概是8~12年。我的工作年限差不多，但作为新人加入，要学习各种工具，了解华为的存储架构、代码细节甚至是各种设计的历史原因，哪怕拼尽全力也要5年才能达到他们的水平。

最关键的是，这些工作了10年甚至更长时间的员工，还一个比一个卷：你以为每天晚上2点回家很卷了？又冒出连续工作30小时的。你觉得任务太重，一周完成是不可能的，人家可以五天完成还顺带做了很多其它任务。相比之下，我充分认识到自己精力、智力和能力的差距。

这种巨大的竞争压力，也使得我神经上出现了些问题。我记得有一次晚上10点，我坐地铁回出租屋，到出租屋快12点了，我洗漱完后想着玩会手机困了就睡，结果一直到2点也丝毫没有困意。我玩半小时，试着睡半小时，反反复复好几次，一看时间，已经5点了。那种时候是最恐惧的：眼看着天快亮了，一点睡意也没有！

那天我一直挨到天亮，早上7点过，才在外面熙熙攘攘的车流声、人流声中睡着，这应该是我这辈子唯一一次失眠。闹铃在08:55准时响起，我又得拖着疲惫的身体骑车奔向公司，经历从早上09:30到晚上22:30的忙碌一天。

在轻松和前途两头都不占的情况下，我最终还是决定投降放弃。其实，还存在转岗到其他部门，开发新产品，大家在同一起跑线的机会。如果新的工作机会晚点出现，我可能会提出转岗，或许就不会离开华为了。

总结

总体而言，华为的竞争力真的比外企强太多。它通过残酷的内部竞争，让员工把活尽可能干漂亮。这虽然换来了大量员工的抱怨，但不妨碍公司的快速发展和进步。

最终离开华为，回想起来还是非常不舍，想起跟大家一同奋斗的场景：站会时PL跟我们挨个定目标，同事间的讨论和帮助，测试串讲，Story设计，多个模块的同事共同实现的功能等等，还是让我觉得这是一段珍贵的经历。

只能说为了家庭和生活，我做出了妥协，放弃了作为奋斗者的机会。最后，希望跟我一同奋斗的小伙伴们都能得到自己想要的，不留遗憾！

芋道源码 —— 纯源码解析博客

华为，再见了！