我们所有人都被一只手推着，在一条名为人生的路上狂飙。 -- 不知名的小孩。
2023 年，我经历了两次裁员，一次是在网易，属于意料之中，一次是在前司，属于意料之外。说实话，可以说是打乱了我原本的职业规划，而今年也恰好是我的而立之年，所以写篇文章来分享记录下这一年的心路历程。
不得不说，时间过的是真的很快，去年的 年终随笔 都还历历在目。转瞬之间，就到了 2023 年结束的日子。
你什么时候过期
你什么时候过期？
这是我所在的云音乐某团队，在 2023年年初，大家见面的第一个问题：你什么时候过期？
因为彼时，已经有很多同事被约谈，劳动合同到期的，全部不进行续签，可能可以算是变相裁员吧。
而我，是 6 月份到期。
但是团队没有事情做，其实是从年后就发现了。
那时候，使得流水翻了好几倍的一项业务，由于合规问题被叫停，就开始暗搓搓裁员的模式，能砍的业务线都砍掉，合同到期的员工均不续期。
而团队内部，也进入了人心惶惶的阶段。打招呼用语也是从早，好啊，改成了，兄弟，你什么时候过期？
我所负责的业务线，虽不是直接关联，但是也不免唇亡齿寒。
平时提需求的运营，产品，也都陷入了沉寂，年前规划的所有项目，均一动不动。
时不时就发现，这个同学的头像上展示已离职，那个同学的签名改成了江湖再见，那个同学的签名改成了 xx 业务已交接。
我当时的工作心态呢，应该大部分同学都一样，都比较平和。因为年终该发的，都已经发掉，和去年基本持平。
剩下的，就是静静等待通知。
就像 耗子叔说的：认真工作，等待裁员(原话不记得了，大概就是这么个意思)。
不出意外，我也被约谈了，基本是提前了 2个月就得知了自己不续签的消息。
虽然我上年度刚刚晋升，但是合同到期不续签，这一项合法合规，没有任何反驳的机会。并且公司还提前了 2个多月就提醒了我。也算是给我了充足的时间来寻找下家。
在此期间，我刷了 leetcode，我是跟着 代码随想录 刷的，不过说实话，后来面试都没用上，难度根本都达不到这个标准，有回溯基本算是顶天了，动态规划就没有见过，背包就更不用说了。
同时，我也刷了几遍 ts 类型体操。
至于为什么要刷 ts 类型体操，这种明显沾点学术派、炫技派的东西，是因为我偶然看到一句话：typescript 拥有一个图灵完备的类型系统，它是一门完整的编程语言。
在此之前，其实对于 ts，我本身总是觉得就是个工具，但是既然它可以被称作图灵完备，那么必然是一些设计在里面的。
所以我将其当作一门新语言进行对待，也开始了体操之路。
在其中，我创建了 TS 类型挑战通关手册，一方面分享自己刷题的思考，另一方面加深自己的理解。
至此，便告别了这待了三年的网易。也告别了这群可爱的同事。不过很快，江湖就会再见，他们也快过期了。
安心搞技术
从猪厂离职后，我加入了 applovin 公司。继续负责前端相关业务。
做出这一步的决断，当时的考虑是：觉得自己在猪厂待久了，像一颗螺丝钉，虽然在当下这个环境，可能选择大厂会更稳妥。
但是稳妥也意味着没有什么空间，所以选择了一家不大的公司，期望是能够找到自己生活中的那一丝丝可能的翻身的机会。
事实也是，来到这家公司，确实有了做一些以前没做过的事情的机会。
当时公司的一个需求，就是获取一些优惠信息，而这些优惠信息，是在 chrome 扩展中的，有些还需要经过很多交互之后，才能顺利获取。
这里面其实有几个问题，一个是目标的 chrome 扩展，它的元素，是借助了 shadow root 这样的方式进行挂载的，同时也并不是所有的元素都会挂载在页面的 dom 节点中，这就导致，难以通过常规的 js 脚本手段，获取优惠信息，更别提通过自动化的方式去获取了。
前人的方案是，通过 ocr 获取 chrome 扩展的相关交互按钮，而我们通过监听接口返回(扩展做的事情是自动调用当前网站的接口，获取优惠信息)，获取优惠信息。这里面就存在 接口返回千奇百怪的问题，只能人工维护一份 adapter 来对接口返回做统一处理。这种情况，如果目标网站只有几个，是没有问题的。但是实际量级远超于此。
故在我接手之后 (虽非我愿，但是我入职的当天，原本负责维护该项目的开发就离职了)，选择了下载原 chrome 扩展代码，修改其交互逻辑，在其代码中插入保存数据的逻辑，从而直接完成数据抓取的功能，就是所谓的逆向。
之后，借助无头浏览器完成自动化的能力。算是形成了这个项目的雏形。
后续的 ip 代理，任务下发模式，流量控制，扩缩容等能力的建设，就是后话了，此处不详细展开。
也是因为这个项目，我算是在公司站稳了脚跟，也顺利拿到了季度绩效的 3.75。
这里推荐一本书吧，也是我在做这个项目期间无意间看到的，本意是学习一些反混淆的技术，不想反而得到了比 babel 手册更详细的介绍 babel api 的书籍，确实受益匪浅。《反爬虫AST原理与还原混淆实战》。推荐对 babel api 感兴趣的同学阅读，说实话比官网反而来的更详细一些。
网页秒开还是太慢？
这是我在 applovin 收到的另一个挑战，即便我们页面 fcp 已经到达了 1s 内，但是依旧被认为不够快。
在我接手之前，其实有数据，p90 的 fcp 都是 1s 内，但是看起来，就明显还是很慢。
这里面其实有几个方向，一个是 fcp 的统计口径是否准确？另一个是，什么愿意你导致只能秒开，500ms 能不能做到，web 的极限是在多少 ms?
我接手之后的分析是：其实目前的 fcp 指标不能满足当下的情况，因为我们页面做了骨架屏，其实会导致 fcp 提前。
此时用户看到的只是骨架屏，并非真实页面，而我们理想的秒开，其实指的并非骨架屏，这也是导致产品团队认为页面太慢的原因。
据说这个骨架屏，最初就是因为页面太慢而加上，加上之后，确实能够提升 fcp 指标的统计，但是其实对于页面的真实展示时间，收益其实不大。从另一个角度上来说，还会一定程度上干扰对页面性能的判断。
在重新做统计之后，根据真正获取数据后展示在用户面前元素被挂载作为统计口径，真实的数据只有 p60 能够勉强达到 1s，是不太快。
而想要在移动端达到 500ms 打开，假设接口请求耗时 200ms 的话，其实留给前端的时间，就只有 300ms。(这里还有 ssr，但是我们的历史业务需要客户端发送请求，导致 ssr 收益不大)。
这就不免对 react 的耗时提出了比较大的要求。
同时由于是在移动端，这些设备一般性能并不够，导致 react 这种运行时比较重的框架耗时较久。
故我选择了 svelte 进行重构，从我当时得到的数据来看(测试机不同，差别会不同，还未来得及上生产人就被通知走人了)，大约有 100 - 300ms 的一个提升。
从我当时的感官来看，页面达到 300ms 打开后，从打开速度上几乎就难以识别出是 h5 还是 native 了。
意料之外的辞退
其实收到 hr 的约谈，其实还是很意外的，在会议室外，我犹豫了一下是否需要开启录音，但是内心最后的一丝善意催使下，还是没有打开。
结果等待我的确实是裁员。
之后我上脉脉发了帖子进行抗争，同时也准备好了仲裁的材料。
不过后来好在事情还是被很快解决掉了。这里非常感谢网友们的支持。
人不是活一辈子，而是活几个瞬间。这次的事情应该可以算是那几个瞬间中的一个吧。
关于这次的事情，我想说，公道其实一直都在的，我愿意永远相信这个世界。
幼稚也好，愚蠢也罢，我就是这样，我愿意相信这个世界的所有善意。
重新起航吗？
提前过年了，接下来会怎么样？
不确定。
不过今年确实经历了还挺多的。
下一步怎么做？我决定享受当下，以后的事，以后说吧。
谁还不能 gap 个几个月了。
谨以此文，送给 30 年来，一直在名为人生的路上狂飙的自己。是时候停一停，休息下了。
共勉！