我在创业公司当程序员的那些事
上周五晚上十点半，我坐在工位上盯着屏幕上那串 java.lang.OutOfMemoryError: Metaspace 报错，一边啃着冷掉的麦当劳巨无霸，一边在心里默默问候那个产品经理祖宗十八代。这不是第一次了——但这次不一样，因为这可能是我在这家创业公司的最后一个线上事故。
是的，我已经跳槽了。现在在一家杭州的上市公司做技术中台，每天用 Mac 写代码、喝瑞幸、开站会，偶尔还去隔壁网易园区蹭个饭（别问，问就是前同事请的）。但每次回想起那段在创业公司“打怪升级”的日子，总觉得有必要写点什么，不为别的，就为了提醒未来的自己：别忘了当初是怎么从泥潭里爬出来的。
创业公司的“综合”挑战：你以为你在写代码？
很多人以为创业公司程序员的工作就是 Coding + Debugging，其实大错特错。在那种地方，你得是“全栈战士”+“临时产品”+“半个运维”+“情绪垃圾桶”。
我记得刚入职时，CTO 拍着我肩膀说：“我们这里讲究‘综合能力’，你要能扛需求、能怼 PRD、能救火、还能画原型。” 我当时天真地以为这是在夸我潜力无限，后来才明白——这是在告诉我：没人帮你兜底。
有一次，产品凌晨两点在群里@我：“用户反馈首页加载慢到像 2G 网络，能不能优化下？” 我反手查了下埋点数据，发现 80% 的用户卡在首屏图片加载。结果一问设计师，说是新上的“高清大图”策略，每张图都 5MB 起。我当场裂开，只好连夜加了个懒加载 + WebP 压缩，顺手写了段 Service Worker 缓存逻辑。
第二天晨会，产品经理笑嘻嘻地说：“效果不错！用户留存涨了 3%，要不我们再加个视频轮播？”
我：？？？
这种“综合”能力，说白了就是：你不仅要解决问题，还要预判问题、制造解决方案、甚至说服别人别制造新问题。
产品思维？不，是“反产品思维”
在大厂，产品和研发是两条平行线，有明确边界。但在创业公司，边界？不存在的。你得学会用产品的语言说话，否则需求评审会上你连插嘴的机会都没有。
有次我们要做一个“智能推荐模块”，产品甩过来一份 20 页的 PRD，里面全是“提升用户体验”“增强用户粘性”这种虚词。我直接拉他到白板前：“你说的‘智能’，是指基于用户行为做协同过滤，还是简单按热度排序？数据源从哪来？实时还是离线？延迟容忍多少？”
他愣了三秒，然后说：“呃……要不你先做个 demo？”
这就是创业公司的现实：产品往往只有模糊方向，技术得把它变成可执行路径。久而久之，我养成了一个习惯——接到需求第一反应不是“怎么做”，而是“为什么做”。如果答不上来，这个需求大概率是伪需求。
后来我甚至开始偷偷帮产品改 PRD，加字段说明、加异常流程、加性能指标。测试同学看到后惊呼：“你是不是转岗了？” 我苦笑：“不，我只是不想半夜被 PagerDuty 叫醒。”
面试题里的“真实世界”：纸上谈兵 vs 生死实战
说到面试题，最近带实习生面试，问了个经典问题：“如何设计一个短链系统？”
候选人 A 背得滚瓜烂熟：哈希算法、Base62、Redis 缓存、MySQL 分库分表……逻辑清晰，术语精准。
候选人 B 说：“我在上家公司做过类似功能，但上线三天就崩了，因为没考虑重定向的 QPS 突增，后来我们加了 CDN + 本地缓存 + 限流熔断，还监控了每个短链的访问频次，防刷。”
我毫不犹豫选了 B。
为什么？因为在创业公司，没有“理论正确”，只有“线上活着”。你可以在 LeetCode 上刷 500 题，但如果没经历过“凌晨三点数据库主从同步断裂”“用户上传一个 10GB 文件导致服务雪崩”这种事故，你的系统设计永远缺一块血肉。
我自己就有过惨痛教训。早年做支付回调接口，为了“高可用”加了重试机制，结果没设幂等，用户一笔订单扣了三次款。那天客服电话被打爆，老板站在工位后面脸色铁青。从那以后，我对“幂等性”三个字刻骨铭心——比任何面试题都深刻。
性能优化：不是炫技，是生存技能
作为对性能优化有点执念的人（现在在中台团队天天调 JVM 参数、搞异步编排），其实在创业公司那会儿，优化根本不是“兴趣”，而是保命手段。
我们服务器预算有限，阿里云账单每月卡在 8000 块红线。一旦超支，CTO 就会发全员邮件：“本月成本超标，请各位节约资源。” 翻译过来就是：谁写的代码吃资源多，谁请全组喝奶茶。
于是我们自发搞了个“性能内卷小组”：
- 前端压缩 bundle 到极致，连 console.log 都删干净
- 后端把 JSON 序列化换成 Protobuf
- 数据库索引建得比头发还密
- Redis 缓存策略精细到按用户等级分级
最夸张的一次，我把一个慢查询从 2s 优化到 40ms，靠的是把 IN 查询拆成多个 EXISTS + 覆盖索引。上线那天，DBA 看着监控图愣了好久，最后发了个红包：“兄弟，你救了我们的 RDS 实例。”
这种优化不像大厂那样有完备的 APM 工具链，很多时候靠肉眼盯日志、手动压测、甚至“玄学调参”。但正是这些土法炼钢的经历，让我真正理解了：性能不是指标，是用户体验和公司成本的直接映射。
跳槽之后：回头看，哪些东西真正值钱？
现在坐在明亮的办公室里，用着 MacBook Pro M2 Max，跑着 Kubernetes 集群，再也不用担心服务器宕机自己得爬起来修——但说实话，我有点怀念那段“野蛮生长”的日子。
创业公司给我的，不是简历上的项目经验，而是三样东西：
- 快速决策力：没有层层审批，你说了算，但也得自己背锅。
- 技术闭环感：从 idea 到上线到复盘，全程参与，知道每一行代码的意义。
- 抗压韧性：被 deadline 追着跑、被 bug 折磨、被需求变更打脸……但活下来了。
当然，也踩了不少坑。比如过度设计（为了“未来扩展性”搞了一套复杂的插件架构，结果产品方向三个月一变）、忽视文档（交接时新人看代码如读天书）、技术债堆积（“先上线再说”成了口头禅）……
但正是这些坑，让我在面试新东家时能坦然回答：“我在上家公司搞砸过 XX 事，后来我们建立了 XX 机制来避免。”
给想进/正在创业公司的程序员几点真心话
如果你正打算加入一家创业公司，或者已经在里面挣扎，以下建议可能比任何面试题都有用：
- 别只盯着技术栈：看团队是否尊重技术、是否有基本工程规范、是否有清晰的业务方向。技术可以学，但文化毒瘤很难解。
- 建立自己的“逃生通道”：定期输出技术总结、维护 GitHub、刷题保持手感。创业公司不确定性太高，别把所有赌注押在一个地方。
- 学会说“不”：不是所有需求都值得做。用数据、用成本、用风险去沟通，而不是单纯抱怨。
- 保护身心健康：我见过太多人 burnout 后彻底离开行业。加班可以，但别让工作吞噬你的全部生活。我现在坚持每周三晚上打羽毛球——雷打不动。
最后分享一个真实对比：我在创业公司和现在中台团队做同一件事（接口性能优化）的差异：
| 维度 | 创业公司 | 上市公司中台 |
|---|---|---|
| 工具链 | 自己搭 Grafana + Prometheus | 全链路 APM + 自动化压测平台 |
| 协作方式 | 微信群吼一嗓子 | JIRA + Confluence + 跨团队 RFC |
| 优化目标 | “别挂就行” | P99 < 200ms, 错误率 < 0.1% |
| 成本意识 | 服务器贵，省着用 | 资源池充足，但要 ROI 证明 |
| 心态 | 救火队员 | 架构守门人 |
没有好坏，只有阶段不同。创业公司教会我“怎么活下来”，大厂教会我“怎么活得优雅”。
所以，回到开头那个 OOM 事故——最后怎么解决的？
很简单：Metaspace 太小，加上动态类加载太多（某个框架的锅），调大 -XX:MaxMetaspaceSize=512m，再干掉两个没用的第三方 SDK，搞定。
关机前，我给继任者留了份文档，标题叫《别碰这五个坑，除非你想通宵》。
然后合上电脑，走出办公室，抬头看见杭州凌晨四点的天空——灰蒙蒙的，但透着光。
那一刻我知道：无论在哪，程序员的故事，都是在 bug 和 deadline 的夹缝里，一点点写出自己的光。
评论 0