别急着学新技术，先把这个做好
我是大厂里一个普通的后端开发者，从毕业到现在也快五年了。这些年我经历了初创团队的飞速成长、大型项目的重构攻坚、也踩过无数“新技术”带来的坑。
今天我想聊聊一个很多人可能没意识到的问题：如果你还处于职业生涯早期阶段，不要急着去学习那些看起来很酷的新技术。你可能会觉得我在逆潮流而动，毕竟现在的技术社区一天到晚都在推什么“XX已死”、“YY才是未来”。但作为一个走过弯路的人，我真的想劝你一句：先把基础打牢，再谈拥抱变化。
为什么我会这么说？
事情还得从两年前的一次项目重构说起。
我们当时负责的是一个电商系统中的订单中心模块。这个模块已经运行了四五年，代码结构臃肿、日志混乱、接口响应时快时慢，每次发布都像在玩俄罗斯轮盘赌——谁也不知道会炸哪里。
我们小组一共五个人，领导决定让我们来做一次彻底的技术升级和架构改造。当时的我刚刚接触微服务不久，又看到大家都在讲什么 DDD（领域驱动设计）、Saga 模式、事件溯源（Event Sourcing），一时热血上头，主动提出要用这些听起来就很高级的东西来重构整个订单中心。
说实话，那时候的我对这些概念并不理解透彻，甚至搞不太清楚 CQRS 和 Event Sourcing 的区别。但我就是被那股“不想重复旧架构”的冲动驱使着，带着几个组员埋头研究了一周，画了几张看起来非常专业的架构图，然后信心满满地开始了开发。
结果呢？重构过程一团糟。
架构太复杂，业务逻辑失控
订单系统本身是个典型的高并发、强一致性场景。我们在原有 MySQL 数据库的基础上加了一层 Kafka 做异步写入，用 Redis 缓存部分状态，为了追求所谓的“高性能”，还引入了 Event Sourcing 来做状态变更记录。
可实际开发中我们发现：
- 业务逻辑变得难以追踪：原本清晰的订单状态流转，在 Event Sourcing 模型下变成了一个个分散的事件。调试的时候得靠人脑拼接出最终状态。
- 错误处理异常复杂：比如某个订单创建失败，要回滚库存和用户账户余额。原来的事务控制可以搞定，现在却需要自己实现 Saga 模式，稍有不慎就导致数据不一致。
- 上线之后性能也没提升多少：反而因为引入太多组件，导致链路更长，接口平均响应时间还比原来多了 50ms。
更尴尬的是，由于采用了大量非主流的设计模式，其他组的同事根本看不懂我们的代码，协作变得极其困难。
最严重的一次故障发生在重构后的第三个月，用户反馈“订单支付成功后状态一直是待付款”，我们花了整整两天才发现是 Kafka 中的某条事件漏处理了。这期间客户投诉、运营催问、技术负责人脸色铁青……
那一刻我终于意识到：我犯了一个致命的错误——盲目追求技术先进性，忽视了解决问题的本质需求。
回归本质：把简单的事做到极致
痛定思痛，我们暂停了那次重构。我重新审视系统的现状，和产品、运维一起梳理了关键需求：
- 稳定性优先，不能影响核心交易流程
- 接口性能不能退化
- 日志清晰可追溯
- 能支持后续的数据分析需求
于是我们做了一个更务实的方案：
- 保留原有的数据库模型，做了合理的索引优化和 SQL 改写
- 将核心状态变更通过本地事务写入数据库，并添加定时核对任务保障一致性
- 引入消息队列只是用于通知类操作（比如推送站内信），不再用于关键状态更新
- 增加详细的日志记录和链路追踪，方便排错
这个版本虽然没有那么多炫酷的概念，但它稳定、可靠、容易维护。上线后接口稳定性大幅提升，P99 保持在 200ms 以内，线上报警次数明显减少。
后来我们才慢慢在新需求中逐步引入一些轻量级的抽象和封装，比如将状态机提取成统一的状态处理器，或者将库存扣减单独做成服务对外暴露接口。这些都是从实际业务出发做的改进，而不是为了炫技。
技术选择从来不是非黑即白
那次教训让我明白了几个道理：
1. 技术没有好坏之分，只有适不适合
- Event Sourcing 很强大，但它适用于状态变化频繁且需要审计日志的场景，比如金融领域的交易流水。
- 而我们这种以读为主、写相对集中的电商业务，强行引入 Event Sourcing 反而增加了不必要的复杂度。
2. 过度设计=慢性自杀
- 我们曾试图在一个简单的订单状态变更中实现“可扩展、高内聚、低耦合”的架构，结果不仅开发周期拉长，还让系统变得更加脆弱。
- 过早抽象会让代码失去表现力，别人读起来就像在看谜语。
3. 真正的工程师思维，是解决问题，而不是证明自己有多牛
- 技术人的成长不在于你能掌握多少热门框架，而在于你能否用合适的方法，解决真实的问题。
- 后来的我开始学会问：“这个问题最朴素的解决方案是什么？”、“有没有更简单的方式能实现目标？”
给刚入行同学的一些建议
如果你是刚开始工作一两年的同学，真心希望你别像我当初那样一头扎进各种新技术里。下面这些建议希望能帮你在成长路上少走点弯路：
✅ 先掌握一套完整的知识体系
编程不像画画，随便拿支笔就能表达情绪。它是有范式、有结构、有工程规范的。建议你花半年到一年的时间：
- 把一门语言吃透（比如 Java/Python/Go）
- 理解常见的设计模式、数据结构和算法
- 学会在 IDE 里高效调试代码
- 掌握 Git 的基本使用技巧
- 写好函数注释、命名有意义、结构清晰的代码
这些东西看起来很普通，但它们是你日后写出高质量代码的基础。
✅ 在实践中积累经验
光看书是学不会游泳的。你得亲自写代码、上线、遇到 bug、修复问题，才会真正成长。建议你：
- 多参与公司的真实项目，哪怕是小功能也好
- 主动请教老员工，多看看他们是怎么设计系统的
- 出现问题时第一时间查看日志、定位堆栈，而不是上来就百度
- 记录自己的问题和解决过程，形成笔记和文档
✅ 看清“趋势”背后的真相
很多人说，“你不学 Rust 就会被淘汰”，“Java 已经不行了，Golang 才是未来”。实际上这些说法往往带有营销成分，我们要学会理性看待。
举个例子，很多前端岗位都在要求你会 React、Vue、Angular……其实只要你理解了组件化开发的思想，换一个框架并不会太难。重点是理解原理和背后的设计理念。
不是否定新技术，而是要学会取舍
最后我想说明一点：我不是反对学习新技术，而是希望大家在合适的阶段做合适的事。
我现在也会关注新技术，比如最近 AIGC 非常火，我们内部也在尝试用 LLM 辅助写文档、生成测试用例；还有服务网格、云原生、Rust for backend 等等，我也在持续跟进。
但不同的是，我现在的判断标准变了：
- 它能不能解决我们当前的问题？
- 是否有足够的生态支持？
- 团队是否有能力驾驭它？
- 是否值得为此付出学习成本？
如果答案都是否，哪怕它再时髦，我们也不会轻易采用。
结语：稳扎稳打，走得更远
技术这条路很长，也很宽。有人擅长深度，有人喜欢广度。无论你想成为哪个方向的人才，我都希望你能记住一句话：
技术是为了解决问题而存在的，而不是为了炫技。
与其天天追着热点跑，不如沉下心来把眼前每一个小功能做好，把每一段代码写明白。
愿你在技术这条路上，走得踏实，走得久远。
评论 0