裁员的瓜吃到自己头上

裁员的瓜吃到自己头上

离职

2022 年 3 月 15 日老东家搬迁，没有跟过去选择了离职。

面试

接下来的一周准备准备了面试，平均每天一两个面试，一直面试到 4 月 8 号星期五。

疫情封控

周六早上起来看到租房群里都在说被封控了，让快去囤吃的，逛了逛看了看微博，是的广州白云区疫情爆发。我所住的村被封控，解封时间不确定。

下楼去买了两个包子一杯豆浆，想着去也去买点吃的吧，走到超市看到超市结账区排起了长龙，商品区的人们慌慌张张的往袋子里塞东西，左右捧，右手提。在门口看了看就走了，晚点再来看看吧，应该不至于饿死。

到了中午超市里人并不多，食品区的货架上大都是空的，泡面是不要想了，挂面还有少许，买了两筒挂面，应该是 1KG 装的，想着就算天天吃面，也能吃一两周了吧，就这样回了去，第二天去超市看看有没有青菜，怎么说呢，这应该算是有吧？就剩下辣椒了，原来微博看到的真不是段子。
好在广州的管控还算不错，线下超市、外卖、线上买菜都是没问题的，后面的日子都是在美团买菜，中间社区还发了一次青菜，2颗白菜、5颗生菜、5根黄瓜、5条胡萝卜，在还能方便买到菜的时间还能免费发放物资，还是很赞的。

封控的不确定性让我有些焦虑，还约了下周的面试，也不得不取消了。安慰自己封控期间可以好好的看看书，再准备充分一些。

中间有收到过 offer，但都不是很满意，原因如：薪资问题、试用期不购买社保、还有 PUA 的。

OFFER

封控前一天，面试的一家公司感觉还是比较满意的，公司环境看着也不错，主营业务为女性服装的跨境电商，技术栈为 php & java，一上午进行了 4 轮面试，分别是：技术小组长-技术主管-产研经理-HR，聊的也不错，也是能望能得到 offer 的。在周二收到了公司的口头 offer，进入背调流程，在周二收到成功收到了 offer，办理线上入职手续，解封后正式入职，最后 4 月 20 日解封，4 月 21 日入职。

入职后

入职后，HR 和技术主管为我介绍公司、技术状况，也了解到，由于海外业务发展不好，年后已经裁员了一半人，但没想到过第二波的裁员那么快的到来，而且幅度还那么大。

7 月 1 日通知，6 月的绩效总结要加上对上半年的总结以及下半年的展望，要进行汇报，面对php、java、产品、测试主管以及产研大佬的汇报工作内容。

仅仅过了几天就传出要裁员的消息，纷纷猜测，6 月的绩效总结和面谈是为了找出要裁员的人而准备的，我想着对我的评价都还是不错，应该不至于是我吧。

墨菲定律：“不管这种可能性有多小，它总会发生。”是的，它发生了，我也被裁员了。

由于公司的业务发展问题，主营的服装都是夏季的，马上到冬季了又因图片版权问题等问题，预估公司收入会直线下降，为了缩减开支，所以裁员幅度很大，幅度很大整个开发组大概20+人，java、测试、产品保留组长一人，php、前端保留组长 + 1~2 位组员。就剩下 9 个左右。一部分手头没工作的，接到通知的下一周就走了，也就是 15 号，有需求的处理完后 22 号离职，我就是 22 号，拿了半月工资补偿，卷铺盖了。

工作贡献

短暂的 3 个月转瞬即逝，3 个月做了十多个需求，其中较为完整的需求有 3 个，其中一个就是总结过的积分需求。

在做需求的过程中也发现了很多问题，其中：

1. 参数验证很混乱，在 Controller，Service 等多地方校验参数逻辑。
2. 异常处理，很多地方都 catch 了 \Exception 仅仅记录一个日志，然后 return 错误信息，很冗余，完全可以使用中央 Exception Handle 统一处理，统一返回。

发现这些问题后，有和我主管反应，也得到主管的支持，让我放手去优化，我也就放心改了。

• 其中 封装了 Request 统一验证请求的参数。
• 将异常处理改为 Exception Handle 统一处理

当然这些改动都是基于新开发的代码应用，老代码还是保持以前的逻辑。

工作收获

每份工作都会有一定收获，这份最大的收获就是：确认开发一个需求后，对需求要有一个整体的统筹规划，花些梳理清楚之后再动手开发。

开发模式

通常的开发模式一般都是：评估需求-确认需求-估算开发时间-后端开发-前端对接-测试。

在之前公司是：后端估算开发时间，然后就着手开发，如果到时间还没开发完成，就再适当延期，开发完成之后与前端数据对接，再提测，在时间上其实还是很宽松

比如：10 天完成，好像还要2天，那就延期2天，和前端对接，对接测试，提测。

但新公司是：后端估算开发时间 -> 给到前端，前端排期 -> 给到测试，测试排期 -> 给到产品，产品排期验收，安排上线时间。这样就有一个问题，如果其中一方延期了，就会产生连锁反应。

比如：后端：1 月 10 日完成，前端：1 月 15 日完成，测试：1 月 20 日完成，产品：1 月 22 日验收，1 月 25 发版。

起因

在接手第一个较为完整的需求，前后端的接口开发。因为没有对需求有所具体的预估，所以前期的估时间有所偏差，导致需求延期了 2 天。临近和前端对接时间时，前端会经常过来问接口进度，前端的时间少了后，临近测试，测试也会催前端，所以会产生连锁反应，影响到其他同事的进度，对此很不好意思。

改变

完成任务之后，也去请教了主管对需求开发时间评估的经验：

1. 复杂的需求技术用文档记录下来，开发的过程中可以回忆起当时分析的场景。
2. 一定不要着急写代码，哪怕需求分析需要花 1 天时间，
3. 前面两点是前提，分析代码主要一点就是切分功能点，然后把每个功能点的时间记录下来，最后加起来，再适当的预留 1~2 天应对突发状况。
   1. 对不熟悉的功能点先看去看相关代码，看完之后记录时间再继续分析。
   2. 是否需要对数据库进行更改，改变需不需要对数据进行迁移、填充。
   3. 是否有三方对接的系统要一并更改。
4. 对于不懂的、不知道的点一定要问出来，不要觉得问题很傻，而不好意思问，自己埋头苦啃。

大概是这些，以前基本是过了一边需求就开始动手写代码了，会出现写到一般方向错了，然后推翻重写，在开发时间宽裕的前公司这样没问题，但现在不行，也不好。

正所谓磨刀不误砍柴工，花半天一天对需求进行分析，看似浪费了半天开发时间，很可能已经帮自己把前方开发过程的坎坷道路填平了。

离职后

因为学历是专科，前两年参加了专升本的成考，7 月底要交论文初稿，一直没时间写，知道要被裁员后也不着急了，离职后花了一个星期把论文的初稿提交了，要求查重小于 30%，论文查重20+%，算是通过了，终稿等到 9 月底，也不着急了。

然后写了三篇博客，填了自己之前写过的一个 Go 生成水印的 Demo ，两个是在被裁员的公司总结，和大家交流的同时也是对自己过去一段时间的总结。

Go生成图片水印demo，既然比PHP慢一倍？

使用pipeline设计模式实现用户积分任务需求

封装 Laravel 自定义表单请求

展望

接下来要开始复习找工作了，希望能找到与 Go 相关的工作，但之前面试似乎对 Go 开发要求较高，所以没有成功面试到 Go 的工作。当然继续 PHP 我也很乐意，毕竟是最好的语言，哈哈哈。

希望自己和大家都有个好工作，好生活。

结束

保存时，脑海里突然冒出《暗时间》开篇的一段话：

每个人的生命就像沙漏，里面装的沙子总量大致相当，不同的是，有的沙漏颈部较细，有的沙漏颈部较粗。

颈部较细的沙漏能够抓住每一粒时间之沙，即使沙子总量一样，也能够拥有更长的生命。

本作品采用《CC 协议》，转载必须注明作者和本文链接