去年秋天有个刚毕业的学弟跑来问我哥我想走工程师这条路但每天就是写业务代码、改Bug感觉跟我想象中的工程师差太远了。到底怎么才算一个合格的工程师我想了很久决定把这些年的真实经历、踩过的坑、想明白的事一次性写出来给所有正在或者准备走这条路的同学做个参考。这篇内容不是教科书也不是成功学是我从一个只会写CRUD的初级开发一步一步成长为能独立负责系统架构、带团队解决问题的老工程师的完整复盘。我会尽量说人话把那些没人告诉你但你必须知道的东西讲清楚。无论你是刚入行的新人、工作两三年遇到瓶颈的同学还是想转行做技术的人这篇文章都值得你花二十分钟慢慢看。1. 重新认识工程师从会写代码到会解决问题的分水岭很多新人最大的误区是以为工程师的价值等于写代码的速度和数量。我刚入行那会儿也是这么想的天天刷算法、背框架觉得自己技术很牛。但真正工作了才发现公司里最受认可、工资最高的那批人往往不是敲键盘最快的人而是能让事情落地、能把复杂问题拆解清楚、能让系统稳定运行的人。1.1 工程师和码农的本质区别在哪码农关注的是这个功能我怎么实现工程师关注的是这个问题该怎么解决才是最优解。听起来差不多实际差着十万八千里。举个很简单的例子。产品经理过来说用户反馈首页加载太慢我们要优化一下。码农思维找到首页接口加个缓存完事儿。至于缓存和数据一致性怎么保证、缓存击穿怎么办、压测做了没有统统不管。工程师思维先确认慢的定义是什么——是首屏时间慢还是接口响应慢是网络问题还是服务端问题是在什么机型、什么网络环境下慢先量化问题再定位瓶颈最后才动手。做完之后还要压测验证、上线观察、设置监控告警。同一个需求前者的方案可能上线两个小时就出问题后者能保证系统稳定跑一年。这就是差别。我后来带团队面试的时候特别喜欢问一个问题你最近解决过最复杂的一个线上问题是什么能把这个讲清楚的人基本都具备工程师的核心素养。因为他需要描述问题的表象、排查的思路、根因分析、解决方案、复盘总结这一整套链路走下来才是完整的解决问题能力。1.2 解决问题的闭环思维定位、拆解、实施、复盘我总结了一套自己一直在用的解决问题方法论四个环节缺一不可定位先搞清楚问题到底是什么。这里有个很关键的原则——不要凭感觉猜原因要用数据说话。日志、监控、链路追踪、用户复现步骤能拿到的信息都先拿到。很多问题表面上是代码Bug根子上是数据问题表面上是性能问题根子上是设计问题。定位不准后面全白做。拆解把大问题拆成小问题。比如系统响应慢拆出来可能是A服务耗时高、B服务连接池不够、C表现在索引失效了。把每个子问题单独分析逐个击破。拆解的过程也是对问题加深理解的过程很多时候拆着拆着根因自己就浮现了。实施从影响最小、收益最大的方案开始做。不要想着一步到位重写整个系统先用最小的代价让系统恢复稳定再考虑根治方案。这个原则在线上故障处理时尤其重要。复盘问题解决了不算完要问三个问题——为什么会出现这个问题为什么当时没发现怎么做才能避免下次再犯然后把答案沉淀成文档、监控项、代码规约让问题真正变成团队的经验资产。1.3 技术选型背后的取舍逻辑才是工程师的功力能不能写某个框架是入门水平能不能在多个方案之间做出合理选择才是真正的功力所在。我见过太多人学了一堆技术但遇到实际问题时不知道选哪个或者选了但说不出理由。技术选型的核心是取舍。我有一次要做一个数据同步组件候选方案有三个自研定时任务、用消息队列异步同步、引入现成的开源同步工具。自研最灵活但维护成本高消息队列方案可靠但增加了链路复杂度开源工具省事但定制能力受限。最后我选了消息队列方案理由是我们的业务有实时性要求而且团队对消息队列已经很熟运维能力跟得上。选型没有绝对的对错关键是你知道自己放弃了什么、得到了什么、为什么这么选。工程师的成长本质上是不断积累这种取舍判断力的过程。写代码只是把决策落地的手段决策本身才是价值所在。2. 基本功是护城河调试、重构、深度工作一个都不能少现在很多同学热衷于学新框架、新技术但基本功却很不扎实。代码写得飘遇到线上问题手忙脚乱重构代码改一处崩十处。我是坚定的基本功至上派因为这几年下来我发现花里胡哨的技术都是暂时的基本功才是那个能扛住时间考验的东西。2.1 调试能力的实战方法论别再用print猜谜了调试可能是很多新手最头疼的环节。代码写完一跑报错了看一眼报错信息懵了然后开始在代码里到处加print加了删删了加折腾半天也没找到问题在哪。我分享一下我自己的调试流程这套方法是跟一个架构师老前辈学的帮我解决过大量线上故障。第一步是读懂报错。不要只盯着最后一行看要看完整的堆栈信息。从最上层的调用入口往下捋找到第一个自己写的代码所在的栈帧那才是问题的起点。很多新手一看到报错就慌其实80%的问题通过仔细读堆栈就能定位。第二步是二分定位。如果你没办法直接确定问题位置不要从头到尾一行一行读代码用二分法。在程序中间位置加日志看数据流到这里对不对。如果对说明问题在后面的逻辑如果不对问题在前面的逻辑。每排查一次就能排除一半代码效率翻倍。第三步是构造最小复现。线上问题最难搞的就是无法复现。我的经验是不要试图在完整业务逻辑里找Bug写一个最小化的demo只保留出问题的路径把外部依赖都mock掉不断简化场景直到能稳定复现。能稳定复现的问题基本就解决了一半。最后一步是追溯数据流。很多隐蔽Bug不是语法错误是数据在层层传递过程中变了形。你以为是String传着传着成了null你以为list是空的结果里面有脏数据。沿着数据从源头到终点的完整路径捋一遍每一步都确认一下数据内容是否符合预期问题自然就现形了。2.2 重构不是大扫除是有纪律的渐进式改进很多同学一提到重构就兴奋觉得可以把以前写的屎山代码全部推翻重来。但我吃过亏这里必须告诉大家一个血泪教训大规模重写往往就是大型翻车现场。我以前刚能独立负责模块的时候看之前同事写的代码特别不顺眼觉得变量命名不规范、函数写得太长、设计模式用得一塌糊涂主动申请了两周时间彻底重构。结果呢重构过程中发现很多以前代码里隐含的业务逻辑比如某个看似没用的if分支其实是用来兼容历史数据的某个神秘的魔法数字其实是跟外部系统约定好的偏移量。这些隐含逻辑一旦丢了系统上线就出各种诡异问题。最后我花了一个多月才把所有功能恢复原样血亏。正确的重构姿势应该是这样的每次重构只做一类改动。改结构就不动逻辑改逻辑就不动结构。混在一起出了问题你根本不知道是哪一步引起的。每完成一步都要能编译能运行能测试通过。小步快跑随时可以停下来。改动前先想清楚这个函数有没有人在别的地方用你以为它是私有的结果别的模块已经import了它一改全崩。重构前先补测试。没有测试保护的重构就是裸奔改了半天你都不知道自己有没有改坏东西。我后来给自己定了一条铁律重构是为了让代码更容易理解和维护不是为了满足自己的洁癖。没有充分理由的重构坚决不做。2.3 深度工作习惯和文档意识长期被低估的竞争力我观察过一个很有意思的现象同样是入职三年的同学差距特别大。一个每天能专注写代码四五个小时另一个过十分钟刷一次手机、过半小时看一次消息看似也在工位坐了一整天但有效产出可能只有两三个小时。三年下来前者的代码量、解决问题能力、技术深度远远甩开后者。深度工作不是什么玄学就是一段不被打扰、全身心投入复杂任务的时间。我建议所有工程师每天至少保留两小时的纯代码时间关掉聊天软件、手机静音、戴上耳机集中精力处理最难的那个任务。这个习惯我保持了快十年效果谁用谁知道。再强调一个很多人不重视的点——文档意识。我要求团队里的每个人都要写设计文档和复盘文档哪怕只是几句话都行。因为写文档的本质是逼自己把思路理清楚。你脑子里想的和纸上写出来的往往是两种状态。能写清楚说明你真想明白了写不清楚说明你还没想明白这时候动手写代码大概率要返工。另外文档还有一个重要的价值它是你跟未来的自己和其他同事之间沟通的桥梁。你现在写的注释和文档三个月后就是别人理解你代码的唯一途径。我见过太多代码读起来像天书注释更是写了等于没写这种代码换谁接手都想骂人。做工程的讲究的是留下来的东西要能传承文档不是给别人添麻烦是给自己省麻烦。3. 学习路线的选择与时间管理如何持续升级又避免焦虑技术圈有个怪现象学习焦虑比学习本身还让人焦虑。今天出来一个新框架明天出来一个新语言好像不学就落后了学了又用不上最后学了个寂寞。这个事我想展开聊聊因为我个人从重度学习焦虑患者到现在能比较从容地规划学习路径中间花了不少时间试错。3.1 以终为始让业务场景决定技术学习而不是反着来我犯过的最大的学习错误就是因为新所以学。有一段时间我每天刷技术资讯看到新的东西就去研究结果学了一堆当时很热门、现在基本没人用的技术投入产出比惨不忍睹。现在的我奉行一个原则你正在做的业务需要什么你就深入学什么你的业务未来需要什么你就提前学什么。技术学习一定要以终为始先在脑海里画好我的发展需要哪些能力再倒推该学什么。举个例子我当年做电商订单系统的时候发现业务对数据一致性要求很高分布式事务是绕不开的问题。于是我系统性地学了分布式事务的各种方案两阶段提交、三阶段提交、TCC、本地消息表、事务消息。每种方案的理论基础是什么、适用场景是什么、业界是怎么实现的我都研究得很透。后来系统真出问题的时候我因为在学习阶段已经见过各种案例排查起来非常快。这种学习有业务锚点学完了马上能用用上了就忘不掉。如果你是做前端的业务里最需要的是复杂状态管理那就把状态管理吃透不要整天追着写CSS的新工具如果你是做后端的业务里最需要的是高并发处理那就把并发、缓存、消息队列、分库分表这些搞明白不要看到一个微服务框架就两眼放光。技术是工具能解决业务问题的工具才是好工具学了用不上的东西过两个月就跟没学一样。3.2 基础原理和底层功力的重要性框架会过时原理不会多同学喜欢问我我应该学Java还是Go我应该用Spring全家桶还是别的框架说实话这种问题问错了方向。语言和框架都是可以快速切换的真正值钱的是那些换什么都没用不上的东西。以Java为例不管你用Spring Boot还是Vert.x还是Quarkus底层都是Java的内存模型、并发机制、JVM调优、垃圾回收原理。框架是招式这些是内功。招式可以随时学内功不行得一点一点磨。我自己经历过一个很深刻的教训。有一年公司要上一个高并发项目初期预估QPS到5000我们用单实例Spring Boot加MySQL就扛住了。到了业务爆发期QPS一下到了5万系统直接雪崩频繁Full GC数据库连接池被打满。当时我们团队里有人提议换语言换框架说Go性能好云原生能力强。但我冷静分析了一下问题其实不在语言和框架而是我们对JVM内存模型理解不到位对象的生命周期管理太粗放导致GC压力巨大数据库这块索引和SQL写得也不好慢查询太多拖垮了整个系统。后来我们花了三周做JVM调优、改代码降低内存分配频率、优化SQL和索引系统稳定扛住了5万QPS。如果当时真去换语言换框架周期至少三个月业务早就崩了。这件事让我彻底明白基础原理才是帮你救火的东西框架再酷也只是平时帮你干活儿。所以我建议每个工程师技术上至少要打好四块地基一是你所用语言的核心机制比如Java的JVM、Go的GMP、Python的GIL二是计算机网络尤其是TCP、HTTP、DNS这些应用层协议三是操作系统进程线程、内存管理、IO模型四是数据结构和算法不是为了面试是为了写代码的时候脑子里有复杂度这个概念。这四样东西打扎实了学什么框架都是顺手拈来跳槽面试也不怕考技术深度。3.3 学习闭环和碎片化的时间利用输入、内化、输出缺一不可我的一个习惯变化是从收藏即学会到输出即学会。我发现很多人收藏了一堆技术文章关注了一堆公众号看起来每天都在学习但实际成长很有限因为学习闭环没有走完。有效的学习闭环应该是输入 - 内化 - 输出三个环节缺一不可。输入就是看书、看文章、看源码、看视频。内化是把输入的内容用你自己的话复述一遍或者跟已有知识体系做关联。这个环节最容易被跳过。输出是通过写技术博客、做技术分享、写demo代码来检验自己是不是真的懂了。费曼学习法大家都听过它的核心就是用自己的话讲给别人听。我在团队里带人的时候也发现了最有效的学习方式就是你来给团队做一次技术分享。准备分享的过程你会把这个技术吃得透透的比你自己闷头看十篇文章都管用。说回碎片化时间。工程师确实忙大块完整的学习时间很难找。我的做法是化整为零通勤时间适合听技术播客、看技术视频了解是什么和有什么。这个阶段属于信息扫盲不需要太专注。午休碎片时间适合看技术文章、刷源码片段理解怎么用。这个阶段需要部分专注。晚上或者周末的大块时间用来啃源码、做实验、写demo搞懂为什么。这个阶段必须全神贯注。时间是挤出来的关键是你要知道自己现在处于哪个阶段然后匹配相应的时间段。别指望在地铁上啃源码那是低效自虐。我还有一个习惯每年年初会给自己列三个年度技术主题写在备忘录里比如深入理解K8s存储机制系统学习性能优化方法论研究事件驱动架构在业务中的应用。这一整年所有碎片学习、技术输出、业余项目都优先围绕这三个主题。年底复盘的时候看着自己今年的学习成果成就感特别真实。4. AI时代工程师的生存框架借助工具增强能力但不能丢掉看家本领AI写代码这个话题现在不提都不行了。我身边有人欢呼效率翻倍也有人在焦虑工程师是不是要失业了。经过半年多的实际使用我的判断是AI确实会重塑工程师的工作方式但真正值钱的依然是基本功、判断力和工程素养AI只是把你的下限提高了上限还得靠你自己。4.1 先说实话AI到底能帮你干什么我日常使用的AI辅助工具主要是两大类一类是智能编程助手可以补全代码、解释代码、生成单测、重构建议另一类是大语言模型对话工具可以查资料、写正则、生成SQL、排查问题的思路建议。实际应用中我觉得它比较高光的场合格外多。比如写正则表达式以前靠记靠查现在直接描述需求AI生成得又快又准。比如写重复性的模板代码我给它一个现有的函数说按这个风格生成另一个模块的类似逻辑生成出来通常微调就能用。比如排查报错把完整堆栈丢给它它能给出很合理的排查方向比你自己瞎猜快很多。再比如写单元测试它能把边界情况考虑得比我手写还全省了大量时间。这个时代不会用AI辅助工具的工程师效率确实会很吃亏。我现在的习惯是写需求之前先让AI生成一个初版我负责把关设计和边界然后再把代码能力体现在查漏补缺、修bug和优化上。4.2 但为什么说基本功反而更重要了以前有个说法叫面试造火箭工作拧螺丝很多人觉得面试考的东西工作用不上。但AI时代最残酷的点在于螺丝钉的活儿AI都能干了你需要做的是设计火箭、验证火箭、检修火箭。而这些工作全都要以扎的基本功为基础。我们用AI写代码有一个最基本的逻辑前提你得能看懂它写得对不对。如果AI生成了一段代码使用了你不理解的API采用了你没见过的写法你能判断它是否正确吗如果它生成的代码有并发安全问题、有内存泄漏隐患、有SQL注入漏洞你能发现吗很大程度上AI生成代码的质量上限等于你的评审能力。而你的评审能力来自于你对语言机制的理解、对设计模式的掌握、对安全问题敏感性、对业务逻辑的熟悉程度。这些恰恰都是基本功。我刚用AI辅助开发的时候有一次让它写一个并发下载的模块。它生成的代码看起来挺工整但仔细一看共享变量的可见性没有用volatile同步存在多线程数据不一致的风险。如果不是我之前对并发编程有比较深的理解这种问题根本不可能发现。像这种兄弟场景我还遇到不少。所以我的态度很明确AI不是让你不用学基本功的借口反而是你必须更深入学习基本功的理由。因为以前你可能靠勤能补拙、靠效率去竞争现在那部分价值链已经被AI大幅压缩了。你唯一还能竞争的就是AI暂时还做不好的部分——深度判断、系统设计、业务理解和工程实践。4.3 如何建立自己的AI辅助但不依赖的工作流走了一些弯路之后现在我已经建立起一套比较成熟的工作流拿AI当高级辅助来用而不是当自动驾驶。核心原则有这几条第一AI生成的代码必须通读一遍不懂的先搞清楚再决定用不用第二重要的模块不直接用AI生成的主体逻辑而是让它生成单元测试和辅助工具代码主心骨自己写第三AI生成的结果永远只作为初稿必须经过自己的调试和验证才能提测第四不在AI代码里写任何自己看不懂的东西哪怕它运行正确。我还坚持一个底线核心架构、核心算法、关键业务逻辑都必须自己亲手写、亲手调。因为代码只是结果真正的能力在思考和执行过程中。写核心代码的过程就是你深入理解这个系统的过程这个内功是你后续所有判断的基础。四年后你会遇见什么样的问题、需要什么样的解决方案都要靠这些内功来驱动。你把核心逻辑交给AI等于把最珍贵的成长机会也交出去。有人说我这是不够拥抱AI效率太低。但我想得很清楚效率要服务于长期成长如果为了短期效率放弃了基本功训练那我的职业生涯就是杀鸡取卵。就好比一个司机如果全程依赖自动驾驶三年后你再让他手动开车他可能连倒车入库都不会了。我不想做那个不会倒车入库的工程师。5. 写给年轻人的十条实战叮嘱与长期主义的自我规划最后这章我想聊聊心态和职业规划。技术能力决定了你走多快而心态和规划决定了你走多远。很多同学刚入行一年半载就开始焦虑工资涨得慢、项目没意思、感觉同龄人比自己强。这些焦虑我都经历过说几句掏心窝的话。5.1 心态篇耐心、复盘、对自己坦诚第一个心态是接受前期平庸。工程师的能力增长曲线不是线性的前两三年你可能会觉得很吃力写代码慢、出Bug多、看到别人做的东西感觉自己一辈子也做不出来。但只要你一直在做、一直在学到了三到五年会突然有一种开窍的感觉很多东西能融会贯通了看到新技术的本质速度也快了。这是很正常的成长节奏不用慌也不用比较。别人一年学到的东西你学两年保证学会了、学扎实了眼里有光那你就已经赢过80%的人了。第二个心态是止损式自省。每个季度我都会花半天时间做一次个人复盘内容很简单回答三个问题我这季度最高光的时刻是什么最低谷的时刻是什么如果重来一遍哪些事情我会做得不一样这套复盘我坚持了很多年。它的核心价值在于帮你对自己坦诚。你可能会发现自己一直在逃避某件事比如系统设计这块一直不擅长但一直没去补或者发现自己把大量时间浪费在了一些毫无产出的事情上。及时发现、及时调整你在成长上的复利效果会非常惊人。第三个心态是正确面对失败。工程师这份职业会持续不断地遇到失败线上事故、代码被当场骂、方案被推翻、绩效不如意。我把这事说透吧你不可能避免失败你只能保证每次失败都有它价值。线上出事故了那就把全链路复盘做扎实让这个事故变成团队最宝贵的教材方案被推翻那就搞清楚推翻的理由下一次方案质量和思考深度都会上一个台阶。逃避失败的人会越来越怕做决策都是事故中生猛历练出来的老同志才能坐到那个位置。5.2 规划篇职业纵深比折腾更重要关于职业发展这几年我越来越认同一个词——纵深。你可以做业务开发也可以做中间件开发还可以做算法工程、数据工程、运维开发但一定要有一个方向是你比其他人都懂的。全栈听起来很酷但什么都懂皮毛其实比较吃亏因为你的可替代性强。我自己是做高并发后端系统出身的这几年来不管环境和业务怎么变化我始终围绕高并发系统的设计、优化、稳定性保障这个主线在纵深积累。框架换了就换呗底层原理没变业务变了就变呗高并发性能优化的方法论没变。这条纵深主线让我的经验可以复利积累越到后面你的核心竞争力越难被替代。给个具体建议入行前三年可以多尝试前端后端运维数据都接触一下找到自己最爱、最擅长、市场也最需要的那块之后三年就要开始做减法锁定一个主攻方向狠狠地扎下去。不要在五年后再纠结我是做前端好还是后端好那是浪费时间。我身边混得好的工程师都有一个共同特征在这家公司能解决的问题换成下一家公司同样能解决。他的能力跟着自己走而不是跟着平台和职务走。如果你发现自己在这家公司干的事儿换家公司就完全不知道怎么干了那你就要警惕了很可能你只是在依赖特定的业务逻辑和环境而没有沉淀出通用性的能力。5.3 年轻工程师最容易犯的五个典型错误这节单独列出来因为我觉得如果是老师傅一句句骂出来的教训同学们能少走很多弯路。结合我带过的十几个新人和我自己的经历我总结出五条典型错误看看你有没有中枪。第一陷入语言或框架之争。哪个语言最好、哪个框架牛逼天天在网上跟人对线。但实际上工具是载体核心是工程能力。总在争论的人多半是因为除了争论没有拿得出手的项目经历。第二拼命堆代码量和工时来凸显价值。看起来很努力实际产出可能很低。工程师的价值从来不是工作时间而是解决问题的能力。与其盲目写十个小时的代码不如花两个小时想清楚方案再花三个小时高质量地把代码写完。第三不做Code Review或者只在交代码前走形式。CR这是学习他人代码的好机会也是发现自己不足的镜子。真正的的成长往往发生在Review的讨论里别人指出你代码问题的那个瞬间就是你进步的那一瞬间。第四忽视业务理解。工程师不是实现需求的机器你应该懂你的业务知道你的需求方在说什么、用户要什么、行业在怎么发展。只懂技术不懂业务的工程师很容易写出技术上优秀但业务上无用的东西然后自我感觉很良好。第五不注重身体健康。这个必须说工程师久坐、熬夜、吃外卖是常态但我见过太多30岁出头一身毛病的同行了。我现在已经强迫自己每周至少运动两次能不熬夜就不熬夜。这条路的赛程很长身体是咱们的全部固定资产。写到这里该说的基本都说了。工程师这条路没有捷径但确实可以走得更聪明、更从容。如果你正在路上或者准备上路希望这些东西对你有用。也算是我这十几年经验的一个交代交给后面的人。 
长河君 · 2026/10/31 6:27:00 · 阅读 1.2k 从CRUD到架构师：工程师核心能力进阶与实战复盘指南
去年秋天有个刚毕业的学弟跑来问我哥我想走工程师这条路但每天就是写业务代码、改Bug感觉跟我想象中的工程师差太远了。到底怎么才算一个合格的工程师我想了很久决定把这些年的真实经历、踩过的坑、想明白的事一次性写出来给所有正在或者准备走这条路的同学做个参考。这篇内容不是教科书也不是成功学是我从一个只会写CRUD的初级开发一步一步成长为能独立负责系统架构、带团队解决问题的老工程师的完整复盘。我会尽量说人话把那些没人告诉你但你必须知道的东西讲清楚。无论你是刚入行的新人、工作两三年遇到瓶颈的同学还是想转行做技术的人这篇文章都值得你花二十分钟慢慢看。1. 重新认识工程师从会写代码到会解决问题的分水岭很多新人最大的误区是以为工程师的价值等于写代码的速度和数量。我刚入行那会儿也是这么想的天天刷算法、背框架觉得自己技术很牛。但真正工作了才发现公司里最受认可、工资最高的那批人往往不是敲键盘最快的人而是能让事情落地、能把复杂问题拆解清楚、能让系统稳定运行的人。1.1 工程师和码农的本质区别在哪码农关注的是这个功能我怎么实现工程师关注的是这个问题该怎么解决才是最优解。听起来差不多实际差着十万八千里。举个很简单的例子。产品经理过来说用户反馈首页加载太慢我们要优化一下。码农思维找到首页接口加个缓存完事儿。至于缓存和数据一致性怎么保证、缓存击穿怎么办、压测做了没有统统不管。工程师思维先确认慢的定义是什么——是首屏时间慢还是接口响应慢是网络问题还是服务端问题是在什么机型、什么网络环境下慢先量化问题再定位瓶颈最后才动手。做完之后还要压测验证、上线观察、设置监控告警。同一个需求前者的方案可能上线两个小时就出问题后者能保证系统稳定跑一年。这就是差别。我后来带团队面试的时候特别喜欢问一个问题你最近解决过最复杂的一个线上问题是什么能把这个讲清楚的人基本都具备工程师的核心素养。因为他需要描述问题的表象、排查的思路、根因分析、解决方案、复盘总结这一整套链路走下来才是完整的解决问题能力。1.2 解决问题的闭环思维定位、拆解、实施、复盘我总结了一套自己一直在用的解决问题方法论四个环节缺一不可定位先搞清楚问题到底是什么。这里有个很关键的原则——不要凭感觉猜原因要用数据说话。日志、监控、链路追踪、用户复现步骤能拿到的信息都先拿到。很多问题表面上是代码Bug根子上是数据问题表面上是性能问题根子上是设计问题。定位不准后面全白做。拆解把大问题拆成小问题。比如系统响应慢拆出来可能是A服务耗时高、B服务连接池不够、C表现在索引失效了。把每个子问题单独分析逐个击破。拆解的过程也是对问题加深理解的过程很多时候拆着拆着根因自己就浮现了。实施从影响最小、收益最大的方案开始做。不要想着一步到位重写整个系统先用最小的代价让系统恢复稳定再考虑根治方案。这个原则在线上故障处理时尤其重要。复盘问题解决了不算完要问三个问题——为什么会出现这个问题为什么当时没发现怎么做才能避免下次再犯然后把答案沉淀成文档、监控项、代码规约让问题真正变成团队的经验资产。1.3 技术选型背后的取舍逻辑才是工程师的功力能不能写某个框架是入门水平能不能在多个方案之间做出合理选择才是真正的功力所在。我见过太多人学了一堆技术但遇到实际问题时不知道选哪个或者选了但说不出理由。技术选型的核心是取舍。我有一次要做一个数据同步组件候选方案有三个自研定时任务、用消息队列异步同步、引入现成的开源同步工具。自研最灵活但维护成本高消息队列方案可靠但增加了链路复杂度开源工具省事但定制能力受限。最后我选了消息队列方案理由是我们的业务有实时性要求而且团队对消息队列已经很熟运维能力跟得上。选型没有绝对的对错关键是你知道自己放弃了什么、得到了什么、为什么这么选。工程师的成长本质上是不断积累这种取舍判断力的过程。写代码只是把决策落地的手段决策本身才是价值所在。2. 基本功是护城河调试、重构、深度工作一个都不能少现在很多同学热衷于学新框架、新技术但基本功却很不扎实。代码写得飘遇到线上问题手忙脚乱重构代码改一处崩十处。我是坚定的基本功至上派因为这几年下来我发现花里胡哨的技术都是暂时的基本功才是那个能扛住时间考验的东西。2.1 调试能力的实战方法论别再用print猜谜了调试可能是很多新手最头疼的环节。代码写完一跑报错了看一眼报错信息懵了然后开始在代码里到处加print加了删删了加折腾半天也没找到问题在哪。我分享一下我自己的调试流程这套方法是跟一个架构师老前辈学的帮我解决过大量线上故障。第一步是读懂报错。不要只盯着最后一行看要看完整的堆栈信息。从最上层的调用入口往下捋找到第一个自己写的代码所在的栈帧那才是问题的起点。很多新手一看到报错就慌其实80%的问题通过仔细读堆栈就能定位。第二步是二分定位。如果你没办法直接确定问题位置不要从头到尾一行一行读代码用二分法。在程序中间位置加日志看数据流到这里对不对。如果对说明问题在后面的逻辑如果不对问题在前面的逻辑。每排查一次就能排除一半代码效率翻倍。第三步是构造最小复现。线上问题最难搞的就是无法复现。我的经验是不要试图在完整业务逻辑里找Bug写一个最小化的demo只保留出问题的路径把外部依赖都mock掉不断简化场景直到能稳定复现。能稳定复现的问题基本就解决了一半。最后一步是追溯数据流。很多隐蔽Bug不是语法错误是数据在层层传递过程中变了形。你以为是String传着传着成了null你以为list是空的结果里面有脏数据。沿着数据从源头到终点的完整路径捋一遍每一步都确认一下数据内容是否符合预期问题自然就现形了。2.2 重构不是大扫除是有纪律的渐进式改进很多同学一提到重构就兴奋觉得可以把以前写的屎山代码全部推翻重来。但我吃过亏这里必须告诉大家一个血泪教训大规模重写往往就是大型翻车现场。我以前刚能独立负责模块的时候看之前同事写的代码特别不顺眼觉得变量命名不规范、函数写得太长、设计模式用得一塌糊涂主动申请了两周时间彻底重构。结果呢重构过程中发现很多以前代码里隐含的业务逻辑比如某个看似没用的if分支其实是用来兼容历史数据的某个神秘的魔法数字其实是跟外部系统约定好的偏移量。这些隐含逻辑一旦丢了系统上线就出各种诡异问题。最后我花了一个多月才把所有功能恢复原样血亏。正确的重构姿势应该是这样的每次重构只做一类改动。改结构就不动逻辑改逻辑就不动结构。混在一起出了问题你根本不知道是哪一步引起的。每完成一步都要能编译能运行能测试通过。小步快跑随时可以停下来。改动前先想清楚这个函数有没有人在别的地方用你以为它是私有的结果别的模块已经import了它一改全崩。重构前先补测试。没有测试保护的重构就是裸奔改了半天你都不知道自己有没有改坏东西。我后来给自己定了一条铁律重构是为了让代码更容易理解和维护不是为了满足自己的洁癖。没有充分理由的重构坚决不做。2.3 深度工作习惯和文档意识长期被低估的竞争力我观察过一个很有意思的现象同样是入职三年的同学差距特别大。一个每天能专注写代码四五个小时另一个过十分钟刷一次手机、过半小时看一次消息看似也在工位坐了一整天但有效产出可能只有两三个小时。三年下来前者的代码量、解决问题能力、技术深度远远甩开后者。深度工作不是什么玄学就是一段不被打扰、全身心投入复杂任务的时间。我建议所有工程师每天至少保留两小时的纯代码时间关掉聊天软件、手机静音、戴上耳机集中精力处理最难的那个任务。这个习惯我保持了快十年效果谁用谁知道。再强调一个很多人不重视的点——文档意识。我要求团队里的每个人都要写设计文档和复盘文档哪怕只是几句话都行。因为写文档的本质是逼自己把思路理清楚。你脑子里想的和纸上写出来的往往是两种状态。能写清楚说明你真想明白了写不清楚说明你还没想明白这时候动手写代码大概率要返工。另外文档还有一个重要的价值它是你跟未来的自己和其他同事之间沟通的桥梁。你现在写的注释和文档三个月后就是别人理解你代码的唯一途径。我见过太多代码读起来像天书注释更是写了等于没写这种代码换谁接手都想骂人。做工程的讲究的是留下来的东西要能传承文档不是给别人添麻烦是给自己省麻烦。3. 学习路线的选择与时间管理如何持续升级又避免焦虑技术圈有个怪现象学习焦虑比学习本身还让人焦虑。今天出来一个新框架明天出来一个新语言好像不学就落后了学了又用不上最后学了个寂寞。这个事我想展开聊聊因为我个人从重度学习焦虑患者到现在能比较从容地规划学习路径中间花了不少时间试错。3.1 以终为始让业务场景决定技术学习而不是反着来我犯过的最大的学习错误就是因为新所以学。有一段时间我每天刷技术资讯看到新的东西就去研究结果学了一堆当时很热门、现在基本没人用的技术投入产出比惨不忍睹。现在的我奉行一个原则你正在做的业务需要什么你就深入学什么你的业务未来需要什么你就提前学什么。技术学习一定要以终为始先在脑海里画好我的发展需要哪些能力再倒推该学什么。举个例子我当年做电商订单系统的时候发现业务对数据一致性要求很高分布式事务是绕不开的问题。于是我系统性地学了分布式事务的各种方案两阶段提交、三阶段提交、TCC、本地消息表、事务消息。每种方案的理论基础是什么、适用场景是什么、业界是怎么实现的我都研究得很透。后来系统真出问题的时候我因为在学习阶段已经见过各种案例排查起来非常快。这种学习有业务锚点学完了马上能用用上了就忘不掉。如果你是做前端的业务里最需要的是复杂状态管理那就把状态管理吃透不要整天追着写CSS的新工具如果你是做后端的业务里最需要的是高并发处理那就把并发、缓存、消息队列、分库分表这些搞明白不要看到一个微服务框架就两眼放光。技术是工具能解决业务问题的工具才是好工具学了用不上的东西过两个月就跟没学一样。3.2 基础原理和底层功力的重要性框架会过时原理不会多同学喜欢问我我应该学Java还是Go我应该用Spring全家桶还是别的框架说实话这种问题问错了方向。语言和框架都是可以快速切换的真正值钱的是那些换什么都没用不上的东西。以Java为例不管你用Spring Boot还是Vert.x还是Quarkus底层都是Java的内存模型、并发机制、JVM调优、垃圾回收原理。框架是招式这些是内功。招式可以随时学内功不行得一点一点磨。我自己经历过一个很深刻的教训。有一年公司要上一个高并发项目初期预估QPS到5000我们用单实例Spring Boot加MySQL就扛住了。到了业务爆发期QPS一下到了5万系统直接雪崩频繁Full GC数据库连接池被打满。当时我们团队里有人提议换语言换框架说Go性能好云原生能力强。但我冷静分析了一下问题其实不在语言和框架而是我们对JVM内存模型理解不到位对象的生命周期管理太粗放导致GC压力巨大数据库这块索引和SQL写得也不好慢查询太多拖垮了整个系统。后来我们花了三周做JVM调优、改代码降低内存分配频率、优化SQL和索引系统稳定扛住了5万QPS。如果当时真去换语言换框架周期至少三个月业务早就崩了。这件事让我彻底明白基础原理才是帮你救火的东西框架再酷也只是平时帮你干活儿。所以我建议每个工程师技术上至少要打好四块地基一是你所用语言的核心机制比如Java的JVM、Go的GMP、Python的GIL二是计算机网络尤其是TCP、HTTP、DNS这些应用层协议三是操作系统进程线程、内存管理、IO模型四是数据结构和算法不是为了面试是为了写代码的时候脑子里有复杂度这个概念。这四样东西打扎实了学什么框架都是顺手拈来跳槽面试也不怕考技术深度。3.3 学习闭环和碎片化的时间利用输入、内化、输出缺一不可我的一个习惯变化是从收藏即学会到输出即学会。我发现很多人收藏了一堆技术文章关注了一堆公众号看起来每天都在学习但实际成长很有限因为学习闭环没有走完。有效的学习闭环应该是输入 - 内化 - 输出三个环节缺一不可。输入就是看书、看文章、看源码、看视频。内化是把输入的内容用你自己的话复述一遍或者跟已有知识体系做关联。这个环节最容易被跳过。输出是通过写技术博客、做技术分享、写demo代码来检验自己是不是真的懂了。费曼学习法大家都听过它的核心就是用自己的话讲给别人听。我在团队里带人的时候也发现了最有效的学习方式就是你来给团队做一次技术分享。准备分享的过程你会把这个技术吃得透透的比你自己闷头看十篇文章都管用。说回碎片化时间。工程师确实忙大块完整的学习时间很难找。我的做法是化整为零通勤时间适合听技术播客、看技术视频了解是什么和有什么。这个阶段属于信息扫盲不需要太专注。午休碎片时间适合看技术文章、刷源码片段理解怎么用。这个阶段需要部分专注。晚上或者周末的大块时间用来啃源码、做实验、写demo搞懂为什么。这个阶段必须全神贯注。时间是挤出来的关键是你要知道自己现在处于哪个阶段然后匹配相应的时间段。别指望在地铁上啃源码那是低效自虐。我还有一个习惯每年年初会给自己列三个年度技术主题写在备忘录里比如深入理解K8s存储机制系统学习性能优化方法论研究事件驱动架构在业务中的应用。这一整年所有碎片学习、技术输出、业余项目都优先围绕这三个主题。年底复盘的时候看着自己今年的学习成果成就感特别真实。4. AI时代工程师的生存框架借助工具增强能力但不能丢掉看家本领AI写代码这个话题现在不提都不行了。我身边有人欢呼效率翻倍也有人在焦虑工程师是不是要失业了。经过半年多的实际使用我的判断是AI确实会重塑工程师的工作方式但真正值钱的依然是基本功、判断力和工程素养AI只是把你的下限提高了上限还得靠你自己。4.1 先说实话AI到底能帮你干什么我日常使用的AI辅助工具主要是两大类一类是智能编程助手可以补全代码、解释代码、生成单测、重构建议另一类是大语言模型对话工具可以查资料、写正则、生成SQL、排查问题的思路建议。实际应用中我觉得它比较高光的场合格外多。比如写正则表达式以前靠记靠查现在直接描述需求AI生成得又快又准。比如写重复性的模板代码我给它一个现有的函数说按这个风格生成另一个模块的类似逻辑生成出来通常微调就能用。比如排查报错把完整堆栈丢给它它能给出很合理的排查方向比你自己瞎猜快很多。再比如写单元测试它能把边界情况考虑得比我手写还全省了大量时间。这个时代不会用AI辅助工具的工程师效率确实会很吃亏。我现在的习惯是写需求之前先让AI生成一个初版我负责把关设计和边界然后再把代码能力体现在查漏补缺、修bug和优化上。4.2 但为什么说基本功反而更重要了以前有个说法叫面试造火箭工作拧螺丝很多人觉得面试考的东西工作用不上。但AI时代最残酷的点在于螺丝钉的活儿AI都能干了你需要做的是设计火箭、验证火箭、检修火箭。而这些工作全都要以扎的基本功为基础。我们用AI写代码有一个最基本的逻辑前提你得能看懂它写得对不对。如果AI生成了一段代码使用了你不理解的API采用了你没见过的写法你能判断它是否正确吗如果它生成的代码有并发安全问题、有内存泄漏隐患、有SQL注入漏洞你能发现吗很大程度上AI生成代码的质量上限等于你的评审能力。而你的评审能力来自于你对语言机制的理解、对设计模式的掌握、对安全问题敏感性、对业务逻辑的熟悉程度。这些恰恰都是基本功。我刚用AI辅助开发的时候有一次让它写一个并发下载的模块。它生成的代码看起来挺工整但仔细一看共享变量的可见性没有用volatile同步存在多线程数据不一致的风险。如果不是我之前对并发编程有比较深的理解这种问题根本不可能发现。像这种兄弟场景我还遇到不少。所以我的态度很明确AI不是让你不用学基本功的借口反而是你必须更深入学习基本功的理由。因为以前你可能靠勤能补拙、靠效率去竞争现在那部分价值链已经被AI大幅压缩了。你唯一还能竞争的就是AI暂时还做不好的部分——深度判断、系统设计、业务理解和工程实践。4.3 如何建立自己的AI辅助但不依赖的工作流走了一些弯路之后现在我已经建立起一套比较成熟的工作流拿AI当高级辅助来用而不是当自动驾驶。核心原则有这几条第一AI生成的代码必须通读一遍不懂的先搞清楚再决定用不用第二重要的模块不直接用AI生成的主体逻辑而是让它生成单元测试和辅助工具代码主心骨自己写第三AI生成的结果永远只作为初稿必须经过自己的调试和验证才能提测第四不在AI代码里写任何自己看不懂的东西哪怕它运行正确。我还坚持一个底线核心架构、核心算法、关键业务逻辑都必须自己亲手写、亲手调。因为代码只是结果真正的能力在思考和执行过程中。写核心代码的过程就是你深入理解这个系统的过程这个内功是你后续所有判断的基础。四年后你会遇见什么样的问题、需要什么样的解决方案都要靠这些内功来驱动。你把核心逻辑交给AI等于把最珍贵的成长机会也交出去。有人说我这是不够拥抱AI效率太低。但我想得很清楚效率要服务于长期成长如果为了短期效率放弃了基本功训练那我的职业生涯就是杀鸡取卵。就好比一个司机如果全程依赖自动驾驶三年后你再让他手动开车他可能连倒车入库都不会了。我不想做那个不会倒车入库的工程师。5. 写给年轻人的十条实战叮嘱与长期主义的自我规划最后这章我想聊聊心态和职业规划。技术能力决定了你走多快而心态和规划决定了你走多远。很多同学刚入行一年半载就开始焦虑工资涨得慢、项目没意思、感觉同龄人比自己强。这些焦虑我都经历过说几句掏心窝的话。5.1 心态篇耐心、复盘、对自己坦诚第一个心态是接受前期平庸。工程师的能力增长曲线不是线性的前两三年你可能会觉得很吃力写代码慢、出Bug多、看到别人做的东西感觉自己一辈子也做不出来。但只要你一直在做、一直在学到了三到五年会突然有一种开窍的感觉很多东西能融会贯通了看到新技术的本质速度也快了。这是很正常的成长节奏不用慌也不用比较。别人一年学到的东西你学两年保证学会了、学扎实了眼里有光那你就已经赢过80%的人了。第二个心态是止损式自省。每个季度我都会花半天时间做一次个人复盘内容很简单回答三个问题我这季度最高光的时刻是什么最低谷的时刻是什么如果重来一遍哪些事情我会做得不一样这套复盘我坚持了很多年。它的核心价值在于帮你对自己坦诚。你可能会发现自己一直在逃避某件事比如系统设计这块一直不擅长但一直没去补或者发现自己把大量时间浪费在了一些毫无产出的事情上。及时发现、及时调整你在成长上的复利效果会非常惊人。第三个心态是正确面对失败。工程师这份职业会持续不断地遇到失败线上事故、代码被当场骂、方案被推翻、绩效不如意。我把这事说透吧你不可能避免失败你只能保证每次失败都有它价值。线上出事故了那就把全链路复盘做扎实让这个事故变成团队最宝贵的教材方案被推翻那就搞清楚推翻的理由下一次方案质量和思考深度都会上一个台阶。逃避失败的人会越来越怕做决策都是事故中生猛历练出来的老同志才能坐到那个位置。5.2 规划篇职业纵深比折腾更重要关于职业发展这几年我越来越认同一个词——纵深。你可以做业务开发也可以做中间件开发还可以做算法工程、数据工程、运维开发但一定要有一个方向是你比其他人都懂的。全栈听起来很酷但什么都懂皮毛其实比较吃亏因为你的可替代性强。我自己是做高并发后端系统出身的这几年来不管环境和业务怎么变化我始终围绕高并发系统的设计、优化、稳定性保障这个主线在纵深积累。框架换了就换呗底层原理没变业务变了就变呗高并发性能优化的方法论没变。这条纵深主线让我的经验可以复利积累越到后面你的核心竞争力越难被替代。给个具体建议入行前三年可以多尝试前端后端运维数据都接触一下找到自己最爱、最擅长、市场也最需要的那块之后三年就要开始做减法锁定一个主攻方向狠狠地扎下去。不要在五年后再纠结我是做前端好还是后端好那是浪费时间。我身边混得好的工程师都有一个共同特征在这家公司能解决的问题换成下一家公司同样能解决。他的能力跟着自己走而不是跟着平台和职务走。如果你发现自己在这家公司干的事儿换家公司就完全不知道怎么干了那你就要警惕了很可能你只是在依赖特定的业务逻辑和环境而没有沉淀出通用性的能力。5.3 年轻工程师最容易犯的五个典型错误这节单独列出来因为我觉得如果是老师傅一句句骂出来的教训同学们能少走很多弯路。结合我带过的十几个新人和我自己的经历我总结出五条典型错误看看你有没有中枪。第一陷入语言或框架之争。哪个语言最好、哪个框架牛逼天天在网上跟人对线。但实际上工具是载体核心是工程能力。总在争论的人多半是因为除了争论没有拿得出手的项目经历。第二拼命堆代码量和工时来凸显价值。看起来很努力实际产出可能很低。工程师的价值从来不是工作时间而是解决问题的能力。与其盲目写十个小时的代码不如花两个小时想清楚方案再花三个小时高质量地把代码写完。第三不做Code Review或者只在交代码前走形式。CR这是学习他人代码的好机会也是发现自己不足的镜子。真正的的成长往往发生在Review的讨论里别人指出你代码问题的那个瞬间就是你进步的那一瞬间。第四忽视业务理解。工程师不是实现需求的机器你应该懂你的业务知道你的需求方在说什么、用户要什么、行业在怎么发展。只懂技术不懂业务的工程师很容易写出技术上优秀但业务上无用的东西然后自我感觉很良好。第五不注重身体健康。这个必须说工程师久坐、熬夜、吃外卖是常态但我见过太多30岁出头一身毛病的同行了。我现在已经强迫自己每周至少运动两次能不熬夜就不熬夜。这条路的赛程很长身体是咱们的全部固定资产。写到这里该说的基本都说了。工程师这条路没有捷径但确实可以走得更聪明、更从容。如果你正在路上或者准备上路希望这些东西对你有用。也算是我这十几年经验的一个交代交给后面的人。