技术探索与实践的一些思考：一个光谷老码农的深夜复盘
去年十月的一个周五晚上，我在光谷软件园B2栋加班到快十一点。办公室空荡荡的，只剩我和隔壁组的小李还在对着屏幕发呆。他突然转过头问我：“哥，你说我们天天写这些 CRUD，到底图个啥？”
我愣了一下，手里的咖啡已经凉透了。那会儿我刚被裁三个月，靠积蓄和老婆的工资撑着，房租3500，房贷6800，孩子上幼儿园一个月还要3000多。每天假装正常上班，其实是在图书馆刷LeetCode、看源码、折腾各种新技术栈。听到小李这句话，我心里五味杂陈——这不就是半年前的我吗？
从“稳定”到“失业”：我的代码人生第一次崩盘
2021年之前，我一直觉得自己是个“稳”的程序员。大厂工作4年，技术栈锁定在Spring Boot + MySQL + Redis，项目虽然重复，但需求明确、流程规范、年终奖也还行。月薪15k，在武汉算不上高，但够用。我甚至开始考虑要不要在关山大道买个小两居。
转折点出现在2022年Q3。公司战略调整，我们整个中台团队被优化。HR找我谈话那天，窗外下着小雨，她说：“公司很认可你的贡献，但业务方向变了。” 赔偿N+1，总共拿了不到10万。当时真的很焦虑——32岁，上有老下有小，技术好像也没啥特别亮眼的地方。
回家路上，我一直在想：我写的代码，除了完成KPI，真的有价值吗？还是说，我只是个高级流水线工人？
重新出发：实战经验不是“做过”，而是“搞懂”
失业后，我给自己定了个死规矩：每天至少4小时深度学习，不刷短视频，不打游戏。第一个月，我把之前工作中用到的所有中间件都扒了一遍源码——Redis的事件循环、Kafka的副本机制、Netty的Reactor模型……很多东西以前只是“会用”，现在才真正理解“为什么这么设计”。
第二个月，我接了个外包项目，用Go重写一个高并发的短信网关。以前在Java生态里待久了，总觉得Go是“玩具语言”。结果一上手才发现，goroutine + channel 的组合在处理I/O密集型任务时，简直丝滑到飞起。虽然最后因为甲方需求反复变更只赚了8000块，但这次实战让我意识到：技术选型不是跟风，而是看场景匹配度。
后来跳槽面试时，面试官问：“你为什么觉得Go适合这个场景？” 我没背八股文，直接画了张架构图，对比了Java线程池和goroutine在10万并发下的内存占用和上下文切换开销。面试官眼睛一亮，当场约了二面。
最终我拿到了新offer，月薪22k，涨了近50%。老婆知道后松了口气，说：“终于不用偷偷给我妈塞钱了。”
吐槽时间：别被“技术趋势”绑架了
现在网上天天吹什么AIGC、Rust、WebAssembly、Serverless……搞得很多新人焦虑得不行，生怕自己落后。但我想说句实话：90%的业务，根本用不到这些“前沿”技术。
上周五晚上，我又在公司调一个线上慢查询。问题出在一个看似简单的分页接口上——前端传了个page=100000，后端直接select * from orders limit 1000000, 20。数据库CPU飙到90%，整个服务差点挂掉。
我花十分钟加了个游标分页（cursor-based pagination），问题解决。这种时候，你跟我谈LLM微调？谈WASM性能优化？对不起，我只想赶紧下班回家陪娃睡觉。
真正的技术探索，不是追新，而是解决问题的过程中，自然延伸出来的深度。比如你发现MySQL主从延迟影响业务，才会去研究Canal、Debezium；你遇到服务雪崩，才会深入理解Sentinel、Hystrix的熔断逻辑。这种“被迫成长”，比盲目学十个框架都管用。
实战经验 ≠ 项目数量，而是认知密度
很多人简历上写“参与XX大型项目，日活百万”，但一问细节就露馅。什么叫实战经验？举个例子：
- 初级：我会用Redis缓存热点数据。
- 中级：我用Redis缓存热点数据，设置了TTL和随机过期时间防止雪崩。
- 高级：我发现缓存击穿导致DB压力突增，于是引入布隆过滤器预检 + 互斥锁重建缓存，并通过监控告警自动触发预案。
差距不在工具，而在对问题本质的理解深度。
我在新公司带实习生时，常对他们说：“别急着写代码。先搞清楚用户为什么需要这个功能？系统瓶颈可能在哪？如果流量翻10倍，哪里会先崩？” 这些问题想清楚了，代码自然就“有灵魂”了。
代码人生：技术是手段，不是目的
最近读《禅与摩托车维修艺术》，里面一句话戳中我：“当你专注于把事情做好，而不是想着‘我在做好事’，事情反而做得更好。”
写代码也一样。不要为了“成为架构师”而学分布式，不要为了“进大厂”而刷算法。真正的驱动力，应该是对“如何用技术让世界运转得更顺畅”的好奇心。
比如我最近在研究eBPF，不是因为它火，而是因为我们线上服务偶尔会出现诡异的网络延迟，传统APM工具查不到根因。eBPF能无侵入地观测内核态行为，正好解决这个问题。这种“带着问题去找答案”的探索，才有持续的动力。
给同行的几点建议（血泪总结）
- 别把技术当宗教：Java、Go、Rust各有适用场景，别陷入语言鄙视链。能解决问题的就是好技术。
- 深度 > 广度：精通一个领域（比如数据库、网络、JVM），比泛泛了解十个框架更有竞争力。
- 输出倒逼输入：我坚持每周写一篇技术笔记（哪怕只有500字），半年下来，知识体系清晰多了。
- 关注业务价值：技术最终要为商业目标服务。能用简单方案解决复杂问题的人，永远稀缺。
- 保持“可被替代”的清醒：没有谁不可替代，但你可以让自己变得“难以替代”——通过深度思考和解决问题的能力。
写在最后
今天凌晨两点，我又改完一个紧急bug。走出软件园，夜风有点凉。抬头看到对面写字楼还有几盏灯亮着，不知道又是哪个倒霉蛋在和生产环境搏斗。
但奇怪的是，我不再像以前那样烦躁。因为我知道，每一次debug、每一次重构、每一次技术选型的纠结，都在塑造我的“代码人生”——它不光是一行行指令，更是我对世界的理解和回应。
技术探索没有终点，实践也不会停止。但只要我们还在认真对待每一行代码，还在为解决真实问题而兴奋，那就还没老，还能打。
共勉。
评论 0