互联网寒冬下的自我提升
互联网寒冬下，我用“技术自卷”挺了过来
我是张远，在一线大厂做了五年多的后端开发。经历过风口期的疯狂招聘、高薪抢人，也目睹了过去两年裁员潮的血雨腥风。曾经那个动不动就百万年薪招人的行业，如今连老员工都成了“包袱”，整个行业的生存环境急转直下。
背景：当裁员通知成为常态
2022年Q3，我们部门突然宣布要进行“组织架构调整”，紧接着就有十几个同事陆陆续续被优化。我那时候刚跳槽过来不到半年，还没完全适应新系统的代码结构，心里其实挺慌的。
那段时间每天早上进公司，第一件事不是打开IDE写代码，而是看看工位上的人是不是还在。有几次午休的时候听到办公室里有人哭，后来才知道是HR谈话的结果。
更糟糕的是，业务线也开始收缩。原本计划中的几个新项目都被砍掉，团队从原来的40多人缩到只剩15个核心成员。老板说，“现在活下去才是最重要的”。听起来像鸡汤，但确实是我们所有人当时唯一的目标。
挑战：既要活下去，又要想办法“活得好”
现实情况摆在那儿：
- 团队规模缩小，人少了事却一点没少
- 项目资源受限，不能随便申请新的服务器、数据库或者外包支持
- 技术栈老旧，系统复杂度越来越高，维护成本剧增
- 高管开始强调“产出效率”，对交付周期要求越来越紧
最让我印象深刻的是一次需求评审会上。产品提了一个看似简单的功能：“用户中心新增一个消息提醒模块，点击后可以查看历史通知。”这个需求在两年前也就是一天的工作量，但在我们现有系统中——别笑，真的——它牵扯到了至少六个不同的服务模块，每个都得做适配和数据结构调整。
最后技术负责人拍板：不改了，直接加个前端弹窗凑合用吧。
这不是玩笑，是真的无奈之举。
转折点：逼着自己“卷起来”的三个选择
在这个节骨眼上，我意识到两个问题：
- 如果你没有不可替代性，随时可能被裁
- 如果系统没有持续演化能力，最终也会被抛弃
于是，我给自己定了三个目标：
- 打通技术壁垒，掌握跨模块的全链路知识
- 拿出实际项目成果，提升个人在团队中的影响力
- 持续学习新技术，为未来做好储备
一、接手“烂尾工程”，搞懂整套架构细节
之前有个服务叫做notification-service，负责处理所有用户的消息推送逻辑。这个服务原本由另一个团队维护，后来因为人员变动没人接手，逐渐变成了“黑盒”。
我主动提出去接这个坑，理由很简单：我想知道整条推送链路是怎么跑通的。
接手第一天我就被现实打了一记重拳。系统日志混乱、文档缺失，代码中有大量硬编码的配置项。更糟的是，依赖的 Kafka 主题名称还写了两三种拼写方式，简直是个灾难现场。
但我坚持干了整整两个月，把这套服务重构了一遍，并且做了以下几件事：
- 引入 Spring Boot Admin 做统一监控
- 将 Kafka 相关逻辑封装成独立模块
kafka-utils - 使用 MongoDB 存储推送失败记录用于后续补偿机制
- 改用 RocketMQ 代替部分 Kafka 场景，解决了高峰期丢包的问题
最终上线效果非常明显：
- 推送成功率从 86% 提升到 99%
- 延迟时间从 15ms 平均降到了 5ms
- 出现异常时能立刻通过后台界面查看失败原因
这件事之后，我的名字在部门技术例会上开始频繁出现。虽然不是什么大事，但它让我从一个普通的“码农”，变成了别人眼中“能解决疑难杂症”的工程师。
二、主导重构旧系统，打造可扩展架构
接下来的挑战来自业务侧：运营反馈我们老系统的一个模块响应速度太慢，影响了活动转化率。这个模块主要负责用户积分计算和兑换流程，底层用了 MySQL，存储的数据量已经达到 1.7亿 条。
最开始的解决方案很简单：加索引 + 分页优化。但测试发现查询依然很慢，特别是在高峰期，经常出现锁表的情况。
于是我们决定来一次全面升级：
- 数据层引入 ElasticSearch，将积分明细数据异构一份出去，供读接口使用
- 写操作依旧走 MySQL，但增加了 Redis 缓存层（主要是用户当前积分）
- 采用 Canal 做数据同步，保证 ES 和 DB 的一致性
- 前端调用接口全部改为异步拉取 + 缓存命中，用户体验大幅提升
这中间踩了不少坑，比如初期 Canal 同步延迟严重，一度导致 ES 查询结果不准。我们后来给同步任务加上了版本号机制，每次更新前会比对版本号，避免脏数据。
这个项目做完以后，整体性能提升了将近三倍，页面加载时间从平均 1.8s 下降到 500ms 左右。更重要的是，这个架构也为后续的扩展打下了基础。
三、边工作边学新技术，抓住趋势才能不被淘汰
在做系统重构的同时，我也开始系统地学习一些前沿技术，比如：
- Go 语言：作为微服务的语言选择，我用 Go 重写了部分 Python 脚本，性能直接翻倍
- Docker/K8s 自动化部署：自己搭了个私有镜像仓库，研究 CI/CD 流水线设计
- AI 辅助编程：尝试用通义灵码做一些代码生成和自动注释，效率提升不少
- 低代码平台：研究过内部的低代码框架，发现有些通用型需求可以直接拖出来实现
这些技能在后来的技术分享会上都派上了用场。有一次我在部门内部做了一场关于“如何用 DDD 设计微服务”的分享，反响还不错，甚至有其他组的人专门来拷课件。
效果总结：熬过寒冬，迎来春意
这一年的折腾下来，收获不小：
- 技术方面：从只会 CRUD 到能主导大型系统重构，技术水平明显跃升
- 职业发展：晋升到高级工程师，带起一个小团队，薪资涨幅超过行业平均水平
- 心理层面：不再焦虑被裁，反而开始思考自己的长期发展方向
- 人脉积累：通过各种技术分享结识了不少同行，有的还成了后面创业的朋友
更重要的是，我在整个过程中建立起了自己的技术认知体系。以前遇到问题第一反应是问度娘或者Stack Overflow，现在我能更理性地分析问题本质，评估不同方案的利弊，再做出适合当下场景的选择。
给开发者的几点建议
如果你现在也在经历类似的处境，或者正在考虑怎么提升自己，下面是我这几年的一些经验，希望能帮到你：
1. 不要只做“执行者”，要敢于参与决策
很多初级工程师习惯于被动接收任务，从来不问为什么要这么做。其实你可以主动参与技术评审、方案讨论，哪怕只是旁听也是进步。
我自己就是从一次次的“旁听会议”中慢慢理解了产品经理为什么这么设计功能、运维同学为什么对某些部署方式不满。这种多角色视角的切换，会让你思考问题更加全面。
2. 多写文档、多讲给别人听
很多人觉得写文档没用，尤其是小公司。但恰恰相反，正是小公司才需要文档，因为你不可能一直在同一个岗位，交接的成本是非常高的。
我每完成一个比较复杂的模块，都会写一份详细的“模块说明+架构图+调用链路图”，不仅帮助新人快速上手，也让自己梳理思路。
另外，定期做技术分享，哪怕是部门内部的口头分享也好。你会发现，当你能把一个复杂的技术点讲清楚时，才算真正掌握了它。
3. 关注技术趋势，但不要盲目追热点
这几年 AI 炒得很热，很多人都在焦虑不会写 prompt、不会用 RAG 架构就落后了。但其实大部分普通开发者的日常工作并不需要天天玩大模型。
我的建议是：关注趋势，但先练内功。比如我现在每天下班后花半小时刷一下 GitHub Trending，了解最新的开源工具和框架。但这并不意味着我要马上学一遍，而是保持对技术发展的感知力。
至于要不要深入某个方向，取决于它是否对你的项目有帮助。比如我们在做智能客服推荐的时候就试过 LLM，结果发现性能还不如规则匹配。这时候就不用强求新技术，回归本质更好。
4. 做好副业准备，但别丢了主业根基
我一直认为，程序员要有“第二收入来源”，尤其是在这个不确定的时代。不管是开博客、写公众号、做小程序、还是接外包项目，都能让你多一条退路。
但前提是：你必须首先是一个靠谱的工程师。我见过太多人一边忙着写自媒体，一边在公司摸鱼混日子。这样的人在寒冬来临时最容易被淘汰。
所以我的建议是：先把自己的本职工作做到极致，再去拓展其他渠道。
写在最后
互联网的冬天确实来了，但春天也不会永远不来。关键在于我们能不能在冬天里找到自己的火种。
对我而言，这段“技术自卷”的历程，不是为了对抗谁，也不是为了卷赢谁，而是为了让自己的职业道路走得更稳一点、看得更远一点。
或许你现在正面临着失业、找不到新工作、技术卡壳等种种困境，但请相信：只要你在技术这条路上坚持下去，终会有破局的一天。
共勉。
评论 0