来OD两年了，从最初觉得自己"还行"，到现在觉得自己"还差得远"。
这篇文章不是鸡汤，就是一个普通开发者的技术成长复盘。如果你也在考虑要不要来OD，或者正在OD但感觉成长遇到瓶颈，可以看看。
来之前：我在小公司是"技术最强的人"
不是凡尔赛。之前那家公司，前端后端运维一肩挑，整个技术部就5个人，我算是里面写得最好的。
那时候觉得自己挺厉害的——独立负责过3个项目，带过2个新人，还能给团队做技术分享。简历上写"全栈工程师"，面试的时候底气也足。
第一个暴击：Code Review
不是格式问题，不是命名规范，是设计层面的。mentor说："你这个方案能跑，但如果数据量翻10倍呢？并发上来呢？这里为什么用同步调用而不是异步？超时怎么处理？"
在小公司的时候，我的代码能跑就行，没人关心你内部怎么设计的。但在这里，每个关键模块的设计都要考虑扩展性、容错性、可观测性。这不是"过度设计"，是因为业务体量决定了你必须考虑这些。
那次之后我意识到：我之前不是"技术好"，只是"没见过好的"。
第二个暴击：身边的同事
一个哥们在来OD之前是某985的 ACM 金牌选手，算法能力碾压级别的存在。问他任何问题，他都能给你一个清晰的分析框架。
一个姐姐从某大厂跳过来的，分布式系统的经验极其丰富。有次线上出了问题，她10分钟定位到了根因，我们几个人还在看日志。
还有几个看着比我年轻但代码写得极其漂亮的。他们的代码读起来像散文——逻辑清晰、命名精准、注释恰到好处。
在这种环境里，你不成长都难。不是被逼的，是耳濡目染。
对了。想一起共事的，前后端-测试均有机会，全国一线及双线城市坑位任选，待遇和稳定性还不错，感兴趣可以看看。
我的技术成长路径
在OD做大体量业务，你必须学会从全局视角思考。一个需求来了，不是直接写代码，而是先想：这个模块的边界在哪？跟上下游怎么交互？数据流向是什么？异常怎么处理？
我现在的习惯是拿到需求先画架构图，再写代码。这个习惯是OD给我养成的。
以前我觉得代码能跑就行。现在我会主动考虑：这段代码半年后我自己能看懂吗？新人来了能快速理解吗？性能瓶颈在哪？
Code Review文化真的很重要。你每次提交都被严格审视，时间长了自然就形成标准了。
线上环境比本地复杂100倍。网络抖动、缓存穿透、数据库慢查询、内存泄漏……这些问题你在本地根本遇不到，但在OD的业务体量下，几乎每周都能碰到。
两年下来，我的排查能力从"看日志瞎猜"进化到了"先看监控定范围，再逐步缩小"。这种能力是实战喂出来的，不是看教程能学到的。
关于内部培训和技术氛围
新人有系统的培训计划，不是那种走形式的PPT过一遍，而是有实操、有考核的。每个技术栈都有对应的学习资料和mentor辅导。
定期有技术分享，都是内部同事讲的。有人讲数据库内核优化，有人讲大规模并发处理经验，有人讲自己的踩坑复盘。质量普遍不错，因为是真实项目里摸爬滚打出来的。
还有一点我比较欣赏的是——内部鼓励技术博客和专利申请。你写的技术方案如果有创新点，可以走专利申请流程。这个对小公司出来的我来说，以前是想都不敢想的事。
闽公网安备 35020302035485号
