Life is a journey, not a destination

前阵子，一个95后的实习生看着我写SQL，突然来了一句：”老师，您这左手敲代码，右手转核桃的功夫是怎么练的？”我愣了一下，看着屏幕里那条写了十年的SELECT * FROM user WHERE status = 1，心里咯噔一声——我好像，真的写了太久同样的东西。 引言：那个让我失眠的”35岁问题”去年冬天，我负责的系统又双叒叕一次平稳上线。没有bug，没有性能问题，连运维同事都说”习惯了”。按理说这应该值得庆祝，但我却失眠了。躺在床上，脑子里全是同一个问题：如果这个项目再让我做三年，我还能学到什么？ 这个问题像根刺，扎在了每个工作十年左右的技术人心里。我们管这叫”第一曲线见顶”——你的技术栈、业务理解、甚至调试bug的直觉都达到了一个平台期。工资可能还在涨，但成长曲线已经趋于平缓。更扎心的是，下面一群年轻人正用他们没家没娃的优势，疯狂内卷。 我意识到，必须找到第二曲线了。 第一曲线见顶的三个危险信号别急着找解药，先确认自己是不是真的”病”了。我踩过的坑告诉我，以下三个信号出现时，说明你的第一曲线真的到顶了： 信号一：代码肌肉记忆 有次我边开会边写代码，半小时后提交，测试一次性...

前阵子，一位老朋友给我打电话，声音里透着焦虑：”我们那个十年的老系统，性能越来越差，代码像意大利面，老板终于批了预算，让我们重写。你觉得用微服务+云原生怎么样？” 我笑了笑，这场景我太熟悉了。过去二十年里，我参与过十几个遗留系统的改造，有的成功了，有的成了”世纪烂尾工程”。最让我心痛的一次，我们花了18个月重写，新系统上线那天，老系统欢快地跑着我们死活搞不定的复杂业务逻辑，而我们精心设计的微服务架构却在第一波真实流量下就趴窝了。 所以今天想聊聊，面对遗留系统，我们到底该怎么玩这场”现代化”的游戏。 战略篇：先当考古学家，再当建筑师1. 别被”技术债务”这个词骗了每次听到”技术债务”就想笑，这词太有迷惑性了，好像欠了钱还清就行。但真实的遗留系统更像是一座活着的城市——里面有错综复杂的地下管线（业务规则），有居民的生活习惯（用户操作路径），还有无数你不知道的”违建”（临时补丁）。 我现在的习惯是，接手一个遗留系统，前两周不写一行代码，就干几件事： 埋点监控：在关键接口埋上监控，看看真实流量长什么样。有一次我们发现某个”即将废弃”的接口每天被调用300万次，是一个第三方合作伙伴的核心...

作为一个在分布式系统里摸爬滚打了十几年的老程序员，我经历过太多关于一致性的灵魂拷问。还记得第一次向老板解释为什么我们的订单系统不能同时保证”绝对一致”和”永远可用”时，他那副”我不管技术细节，我就要两者兼得”的表情。那一刻我意识到，理解CAP定理是一回事，在现实中做出权衡又是另一回事。 今天想和大家聊聊这些年我在一致性问题上踩过的坑、流过的泪，以及那些血与泪换来的实战经验。 理论很美，现实很骨感刚接触分布式系统时，我和很多人一样，把CAP定理当作圣经。CAP说一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)三项中的两项。听起来很清晰对吧？但真正落地时，你会发现这简直是”魔鬼在细节里”的典范。 第一个坑：把CAP当成非黑即白的选择 早期我负责的一个用户积分系统，当时为了”强一致”，我们采用了两阶段提交(2PC)。结果在一次机房网络抖动时，整个系统卡死了三分钟。用户无法兑换积分，客服电话被打爆，老板的脸色比锅底还黑。那次之后我才明白，CAP中的C和A其实是连续光谱，不是开关按钮。 ...

上周，一位前同事在LinkedIn上给我发消息：”老哥，写了十年业务代码，感觉走到头了。你们公司还招人吗？什么岗位都行，我想转行了。”看着这条消息，我愣了半天。十年前我们并肩作战，他写后端比我快，bug比我少。但现在，他说的”走到头”三个字，像一根刺扎在我心里。 这让我想起自己三年前那个焦虑的夏天——盯着屏幕上的增删改查，突然问自己：难道接下来二十年都要这样过吗？ 第一曲线终点的迷雾干了十五年开发，从JSP写到微服务，从jQuery折腾到React，我经历过技术的几轮更迭。但说实话，到了第十年左右，我开始感受到一种无形的天花板。不是技术上的，而是价值感上的。 你能想象那种状态吗？需求来了，你脑子里立刻浮现出表结构、接口设计、前端组件，像流水线工人一样熟练。产品经理夸你”交付快”，你笑笑，心里却空落落的。因为你清楚地知道，这套代码三年后会被重写，你的经验不过是下一轮循环的燃料。 更扎心的是招聘市场。去年我帮团队面试，一位35岁的候选人技术扎实，但面完总监悄悄跟我说：”他能力没问题，但就怕他只能做执行。”这句话像耳光一样扇在我脸上——我们引以为傲的”执行力”，在年轻人和AI的双重冲击...

前几天，一个刚入职的小朋友问我：”老师傅，这段代码明明能跑，为什么要花两周时间重构？”我看着他稚嫩的脸庞，仿佛看到了20年前的自己——那个以为”代码能跑就不要动”就是终极真理的少年。 我拍了拍他的肩膀，打开了我们系统的监控面板，指着那个在高峰期疯狂抖动的接口说：”你看，这个接口每次上线都像在走钢丝。上周我们加个简单的字段，结果引发了连锁反应，凌晨三点被叫起来救火。这就是技术债的利息，它不会消失，只会越滚越大，直到某一天你连本带利一起还。” 今天，我想聊聊这个让无数程序员又爱又恨的话题——技术债。不是那些教科书式的理论，而是我这20年摸爬滚打总结出的血泪经验。 技术债到底是什么？别被名字骗了很多人一听”技术债”就觉得是烂代码的代名词，其实不然。技术债就像房贷，本质上是一种权衡取舍。当年为了快速上线，你选择了复制粘贴而不是抽象封装；为了赶工期，你跳过了单元测试；为了兼容老系统，你留下了那段”魔法数字”——这些都是合理的商业决策。 但问题在于，我们往往只记住了”借”，却忘记了”还”。 我印象最深的是2015年负责的一个电商项目。当时为了抢在双11前上线，我们硬是把本该微服务化的架构做成...

周五晚上六点，我准时合上MacBook。屏幕黑下去的瞬间，IDE里那几十行没写完的代码还在我脑子里闪着光标，像霓虹灯一样挥之不去。同事在Slack上道着”周末愉快”，我回了个咖啡emoji，心里却在盘算：要不要趁周末把那个bug修了？ 走出写字楼，晚春的晚风带着白玉兰的香气扑面而来。我忽然想起，自己已经连续三个周末都在家”顺便”处理工作了。上周六下午，我本该在阳台看书，结果手贱看了眼监控告警，整个下午就交代给了日志排查。再上周日，本来说好陪老婆逛公园，却在长椅上抱着笔记本重构了一下午接口。 那一刻，我决定给自己按下暂停键。不是那种”假装下班”的暂停，而是真正的systemctl stop work.service。 周六早上的咖啡编译时光周六我破天荒起了个大早，不是为了赶deadline，而是为了等楼下的咖啡店开门。这家叫”慢时光”的咖啡馆，老板是个退休的物理老师，磨咖啡豆的时候总喜欢跟人聊量子力学。我点了杯手冲耶加雪菲，坐在窗边看着他用温度计测水温，用电子秤称粉重，水流画着圈注入滤杯，整个过程像极了一场精密的实验。 “你们写代码的，是不是也这么讲究？”老板把咖啡递给我时问道。 ...

上周团队复盘会上，小李苦笑着承认：”我当初坚持用上Kubernetes，纯粹是因为看了几篇大厂案例，觉得不上就落伍了。”话音刚落，会议室里响起一片会心的笑声。这不怪他，我们都一样——自以为理性客观的工程师，其实每天都在被大脑的各种认知偏差牵着鼻子走。 干了二十年开发，我最大的感悟不是技术有多难，而是认清自己有多难。今天想跟大家聊聊，那些年在技术决策中，我是怎么被自己的大脑”坑”的，以及后来学会的一些避坑方法。 锚定效应：那个该死的”第一印象”2018年，我负责重构公司的订单系统。第一次开会时，CTO随口说了句：”听说现在都用微服务了，挺火的。”就这一句话，像锚一样沉在我心里。接下来两周，我所有的调研都围绕着”怎么把单体拆成微服务”，而不是”我们的核心问题到底是什么”。 我选择性忽略了团队只有5个人、业务变化快、QPS不到500这些关键事实。当我洋洋洒洒拿出那份50页的《微服务化改造方案》时，老板问了个致命问题：”我们现在的问题，是单体架构导致的吗？” 我愣住了。真实情况是，我们的痛点是业务逻辑混乱、数据库设计不合理，跟单体还是微服务半毛钱关系没有。但那个”微服务”的锚，让我自动过...

去年夏天，我接手了一个”经典”的遗留系统改造项目。经典到什么程度呢？前端是jQuery+ASP.NET WebForms，后端是2008年的SQL Server存储过程，代码里还藏着对IE6的兼容逻辑。更绝的是，整个系统的业务逻辑有70%写在数据库里，一位离职十年的DBA留下的注释成了我们团队的”考古文献”。 老板的要求很简单：”保持业务不中断，六个月完成现代化改造。”我笑了笑，想起二十年前第一次做类似项目时的意气风发，以及随后被现实按在地上摩擦的惨痛经历。这次，我决定把这些年踩过的坑、流过的泪，都化作一套可落地的战略战术。 战略先行：别急着写代码年轻十岁的我，接到这种项目会立刻打开IDE，想着”先重构几个类再说”。但现在我会先泡杯咖啡，拉着业务方聊三天。 第一个血泪教训：技术债务的利息是复利计算的。 我们花了两周时间做系统全景扫描，结果触目惊心：核心订单流程涉及23张表的隐式关联，一个”简单”的库存查询会触发7层嵌套视图，最底层还有一个触发器在默默改数据。如果贸然动手，相当于在承重墙上砸洞。 我们制定了三条铁律： 业务价值驱动：只改造阻碍业务发展的部分。那个IE6兼容代码虽然...

前阵子团队聚餐，新来的实习生突然问我：”老师，您说分布式系统的一致性到底该怎么保证？我看网上都说CAP定理，但真到写代码的时候，感觉还是一头雾水。”他这一问，把我拉回了三年前那个折腾订单系统的深夜。当时我们为了解决一个库存超卖问题，整整熬了三个通宵，最后发现罪魁祸首竟是一个看似无害的重试机制。今天，我就结合这些年的踩坑经历，聊聊分布式一致性这个”说起来容易做起来难”的话题。 理论很美，现实很骨感记得第一次接触CAP定理时，我信心满满地在架构评审会上说：”我们要强一致性，所以牺牲可用性！”结果被老板一句话怼回来：”用户下单页面打不开，你负责？”那一刻我才明白，CAP不是非黑即白的选择题，而是灰度空间的平衡艺术。 CAP定理真正的精髓在于：在网络分区（P）不可避免的前提下，一致性（C）和可用性（A）是连续光谱，不是二元开关。我们早期做金融转账系统时，为了追求强一致，用了两阶段提交（2PC）。结果一次机房网络抖动，所有事务协调器卡住，整个系统停摆20分钟。用户疯狂刷新页面，客服电话被打爆。那次之后我深刻认识到，强一致性的代价往往是系统的脆弱性。 后来我们转向BASE理论（基本可用、软状...

早上七点半，我被雨声叫醒，不是闹钟。窗外灰蒙蒙一片，雨点打在玻璃上，发出”沙沙”的声响，像极了我那台老机械键盘的敲击声。我翻了个身，猫已经抢先一步占据了床尾的最佳位置，眯着眼看我，仿佛在说：”今天不用通勤，对吧？” 我笑了。是啊，周六，而且这雨势，显然是要下一整天的节奏。手机上有几条工作消息，我瞥了一眼，都是些不紧急的bug，索性标记为”稍后处理”。这一刻，我突然想起年轻时那个倔强的自己——曾经在一个台风天，硬是拖着笔记本去公司，因为”线上环境有问题”，结果整栋楼就我一个人，对着服务器发呆。二十年过去了，我终于学会了在雨天给自己按个暂停键。 程序员这个职业，说起来有点讽刺。我们创造了无数让人”上瘾”的产品，自己却最容易陷入那种”永远在线”的焦虑。Push通知、Issue追踪、CI/CD流水线……这些本该是工具的东西，慢慢变成了枷锁。而雨天，尤其是那种不紧不慢、没有雷暴的细雨，反而成了我最好的”断网”理由。 我煮了杯咖啡，深烘的豆子，苦味重一些。猫闻了闻，嫌弃地走开了。我窝在书房那张已经坐出凹痕的扶手椅里，从书架上抽出一本书。这个动作本身就有仪式感——不是打开Kindle...