啃烂摊子项目让编程能力突飞猛进

我的编程能力真正开始「突飞猛进」，是从被迫啃下一个「烂摊子项目」开始的。

2019年我在一家创业公司做后端开发，当时接手了一个运营三年的电商秒杀系统。接手前只听说「偶尔会崩」，实际接触后才发现：代码里到处是拍脑袋写的线程池（核心线程数全凭感觉设20），缓存逻辑用HashMap硬扛（连本地缓存框架都没用），数据库里堆着百万级的未归档订单（查询慢到超时）。最离谱的是，关键链路的注释写着「这段代码别改，改了会出大事」——但没人知道具体会出什么事。

最初我也想「缝缝补补」应付，但某次大促前压测，系统在500并发时直接OOM。领导拍着我肩膀说：「这次必须彻底解决，否则项目组可能解散。」压力之下，我不得不跳出「完成需求」的思维，开始用「解决问题」的逻辑重新梳理整个系统。

第一个转折点是「拆解问题到原子层」。我用APM工具（当时用的Pinpoint）把整个调用链路打穿，发现90%的耗时集中在三个点：Redis缓存穿透导致的数据库压力、订单生成时的锁竞争、日志写入阻塞主线程。以前写代码总想着「先跑起来」，这次必须搞清楚每个环节的底层原理——比如为什么本地缓存要加Guava的LoadingCache？看源码才知道它内置了异步刷新和淘汰策略；为什么分布式锁不能用简单的setNx？读Redlock论文才明白时钟漂移的影响。

第二个突破是「主动重构代替被动补丁」。原来的订单服务有个「防重复提交」逻辑，用的是HTTP请求头里的UUID做内存校验——但分布式部署后根本不生效。我没有像以前那样加个Redis去重，而是从头设计：先分析重复提交的场景（网络重试、用户手抖），再根据业务容忍度（允许5分钟内重复但不超过3次），最后用Redisson的RateLimiter实现限流+去重。这一步让我真正理解了「业务场景驱动技术选型」的逻辑。

最关键的是「建立知识连接网」。以前学的JVM调优、MySQL索引、分布式事务都是零散知识点，这次为了定位OOM，我从堆内存溢出查到元空间占用（发现是动态生成的CGLIB代理类没及时回收），再顺藤摸瓜优化了Spring的AOP配置；为了优化慢查询，从explain执行计划看到索引覆盖不足，进而重构了订单表的字段冗余策略。这些操作像拼图一样，把原本孤立的知识串成了体系。

三个月后系统大促扛住了8000并发，更重要的是我发现自己看代码的视角变了：以前拿到需求先想「用什么框架」，现在会先问「用户真实场景是什么？瓶颈可能在哪里？」；以前改代码只关注功能实现，现在会考虑「是否可观测？是否易扩展？出问题怎么快速定位？」。这种思维转换，比学会某个新框架有用十倍。

后来我才明白，编程能力的「突飞猛进」从来不是靠学多少新技术，而是被迫进入「解决复杂问题」的场景——当你必须为系统的稳定性兜底，必须搞懂每一行代码的底层逻辑，必须为错误承担后果时，能力的边界自然会被撕开一道口子。那些熬通宵看的源码、反复推翻的设计文档、被监控报警叫醒的凌晨，最后都会变成你写代码时的直觉。