Long time no see.

emmmm，虽然很久没写Blog了，但还是写点有价值一些的内容。

上班 as Huawei OD

Time line:

  • 2023/3：准备机考、resume和面试，3月底进行机考和面试
  • 2023/4/4：入职
  • 2025/2/6：离职

3月份花了小一个月的时间刷了下牛客的题，基本上做完了简单和一般的题，由于笔试选择的语言是C，所以花了不少时间和输入输出对线，期间抽空补习了下C语言的基本语法，再次推荐下这个网站：Linux C编程一站式学习，另外就是找了下C语言的一些八股文（虽然面试时候完全没用上）。

具体面试和笔试的一些东西可以看上一篇讲入职的，这里就不多讲了。

确定入职时间后其实过的都比较匆忙，记得当时给我的时间甚至没有一个星期。我前一天晚上预约了雅安的体检，第二天早上去体检中心搞完出来，马不停蹄往成都跑，中午在成都招商银行办完工资卡才吃上的午饭，完事马上又去看租的房子，看完马上交定金，拿到钥匙就赶往往家跑，甚至没赶上西站的动车，去南站坐的，等车期间头一次体验了把共享充电宝，评价是只能降低掉电速度……到了雅安已经很晚了，就临时找了个小的酒店住着，好像当时有个什么考试，人家都认为我是来考试的考生。回家躺了一天又去雅安拿体检报告，上传后又回家躺了一天就到成都上班了，总之搞的很匆忙。

部门结构概况

具体做什么业务就不提及了，部门结构还是可以讲讲。

一个部门其实是有很多PL组构成的，一个小的PL组有几个比较关键的角色：

  • PL，也可以说是直接主管（这些勾八缩写连PL自己都不清楚全称是啥，猜测是Project Leader？），统一管理和安排一个组的工作
  • DE，（Design Engineer？）有点像技术顾问的角色了， 主要去处理需求分解、疑难问题解决等
  • 版本接口人，因为华为内部推版本推的很快，一年要发布俩大的版本，所以可能一个组有俩接口人，分别接口不同版本，协调版本事务，搞需求需要哪个组配合就先找接口人协调人力
    • 维护，主要处理现网问题和维护补丁，和其他组员接触的东西基本分割，感觉一天都在会上。

这么看其实关键角色也就这四个，其他就都是组员了，人少的时候甚至PL身兼数职。

版本推进

一年俩大版本，分上半年和下半年，发布后的版本就转为维护版本。

一个大版本要经历6个TR点（Technical Review）每个点都有具体的达成指标，完成后即过点，这种版本演进模型据说还用的挺广泛的。

一般TR1，TR2就是在分解需求和特性设计，这个时候DE必须投入，一般来说这俩点会把整个版本要做的需求都大致分解完成，TR3就分解人力安排工作。

TR4、TR5就是主要投需求开发。

TR6就是最后一个点，对开发和测试来说就是把所有发现的问题全部处理完

需求开发

我是干开发的，就大概讲下做一个需求的一些流程。

一般是PL或者接口人分配给你一个需求，需求一般分为主导需求和配合需求，主导需求是一个部门的真正产出，PL或主管会与你“商讨”完成计划，包括Story设计完成时间、串讲时间、需求开发时长、转测时间，上库时间；而配合需求则需要跟着别人的计划走。我按照时间顺序简单梳理下步骤：

  • 找DE对齐方案，对齐这个词还用的挺多的，目的就是确保一个事：大家想的一样。
  • 拉群，把这个需求设计到的模块的开发、PL、接口人全部揽到一起，和依赖模块对齐接口实现、各种计划的具体时间。
  • Story设计：Story模型是敏捷开发的内容了，这部分你要求完成一个文档，这个文档里包含了所有开发的细节，包含了需求背景、场景分析、接口描述、逻辑视图、时序图、SFMEA（System Failure Mode and Effects Analysis）、Shard拆分、开发测试用例等。写的越详细越好，用这个文档指导开发。
  • 开发串讲：目的是给测试讲解需求，让测试知道他要测试什么内容，在测试的角度评价你的设计是否完善
  • 测试反串讲：目的是让开发知道测试准备怎么测你的需求，确保功能点不漏测
  • 需求开发：写代码啦，我们组实行的是Shard开发模式，以一种所谓小步快跑的方式上库代码
  • 联调：大家代码都写完了就把大家拉到一起借环境，烧上大家写的代码就测试基本功能，有问题改问题
  • 转测评审：看转测的必要条件是否达成，达成就可以发邮件转测啦
  • 上库评审：一个需求完成的标志，测试测完，所有测试时发现的要求必须解决的问题都解决了，代码都上到主干了，其他各种达标项都OK就宣布需求完成。

Code

代码仓管理其实跟GitHub也差不太多，通过Git进行分支管理，每个版本都有一个独立的开发分支，版本更替时会基于当前版本的分支新拉一个。每个部门有个自己的子系统，从个人分支合并到子系统的代码通过周期性的构建（也就是验证编译、LLT、测试用例验证等）无误后推往主干。

Code的PR或者叫MR运作其实也跟GitHub差不多，需要有人review你的代码，提出检视意见，修改后重新提交，直到目测功能无误，符合CleanCode标准后，检视人加分，committer合入。

收个尾

以上就是我认为需要记录一下免得忘了的东西，有些大厂的规范化操作我认为可能在自己组织项目的时候也是值得参考的。

把工作辞了之后，又开始捣鼓各种东西，感觉Blog这玩意儿，虽然没有一个人读，但感觉持续记录的习惯得保持。之后应该会更偏技术一些。