别再追新框架了：长期价值导向才是工程师的避坑底牌

上周组里刚毕业的小周，熬了两个通宵回滚系统，眼睛肿得像核桃。他花了三周把跑了三年的日志组件换成了最近社区爆火的新工具，上线当天还在群里发了庆祝的表情包，说性能比老栈快32%。结果第十天，那个开源项目的核心维护者在仓库发了个公告，说自己拿了融资要去做AI创业，项目从即日起停止维护。连个适配新操作系统的补丁都没人提，最后全组只能啃着冷咖啡回滚，小周坐在工位上掉眼泪的时候，我都没好意思戳破他。

你以为的长期，是把代码写得“够先进”

很多人对长期价值导向的误解，从根上就歪了。觉得要长期，就得选最前沿的技术，用最酷的架构，把所有能堆的技术名词都堆上去，才算对得起自己的职业成长。

我刚工作那会赶上微服务的风口，全公司从上到下都在喊“要把单体拆成微服务”。一个管着全公司200人审批流程的小系统，总共三个开发，硬生生拆成了12个服务。光服务之间的调用超时配置就写了三页文档，每次改个审批节点的逻辑，要跨五个仓库提PR，等所有流水线跑完要俩小时。

过了两年部门缩编，原来的三个开发走了俩，剩下的小孩接手的时候，光摸清楚哪个服务管哪个节点就花了一周。有次系统崩了，排查了三个小时才发现，是其中一个服务的依赖包版本升级，把原来的校验逻辑改了。

现在想想都离谱。

这哪是长期价值。

这是给未来的自己挖了个填不上的坑。

你在技术社区刷到的“某某工具性能吊打同类产品”的测评，大概率是项目维护者自己写的引流稿。等你真把它接到生产系统里，才会发现那些benchmark的测试场景，在你的真实业务里根本不会出现。你花了几周时间迁过去，省下来的那点性能，根本抵不上你未来要花在维护上的时间。

工程师深夜排查微服务拆分故障现场

真正的长期价值导向，从不是追求技术的先进性，是算清楚“你未来要为这个选择付多少成本”。

你选一个开源组件，别光看它现在star多高，要看看它的维护团队有没有稳定的收入来源，有没有持续在补安全漏洞，有没有足够多的人遇到问题能给出解决方案，甚至——有没有可能它的文档是普通人能看懂的，新来的实习生不用翻梯子就能把它跑起来。

我之前选开源的消息队列的时候，没有选当时吹得最凶的那个新一代产品，选了已经跑了快十年的老项目。当时组里有人说我保守，说那个老项目已经技术过时了。结果过了两年，那个吹得最凶的新项目，因为核心团队解散，连个严重的内存泄漏bug都没人修，好几家公司因为这个系统出了线上故障，我们这边安安稳稳跑了快五年，连个大的报警都没有过。

把长期价值导向焊在代码里，不是熬时间

很多人觉得要做长期价值，就得搞那种能写进公司年报的大项目，要做能拿行业奖项的架构升级。

根本不是。

我2020年写的那个内部权限SDK，现在还在被全公司十几个业务线用。当时写的时候根本没想什么“长期价值”，就是嫌每次写权限校验的代码太麻烦，把所有重复的逻辑抽成了个公共函数。没有搞复杂的依赖注入，没有搞花里胡哨的事件驱动，就是最朴素的封装，注释写得跟聊天似的：“这里别随便改，改了所有后台登录都会炸”。

四年了，中间换了三批开发，每次有人接手，翻十分钟代码就能改，从来没因为这个SDK出过线上故障。你说这个东西技术含量高吗？一点都不高，没有用任何前沿技术，甚至连个正式的设计文档都没有。但是它就是能一直用，省了不知道多少重复的工作量。

工程师手写的公共SDK代码注释截图

我见过太多所谓的“架构升级项目”，花了半年时间，把原来跑的好好的系统拆得七零八落。最后为了证明项目的价值，拉着各个业务线做无意义的迁移，迁完了发现业务量根本没涨，原来的系统再跑十年都没问题。这半年的人力成本，就这么打了水漂。没人会给你发奖状。代价是实打实的。

上次小周回滚完，坐在工位上啃包子，跟我说早知道不追那个新工具了。我跟他说，你别觉得追热点是错的，但是每次想引入一个新技术的时候，先花十分钟问自己三个问题：这个项目的维护者有没有稳定的收入来源？如果三个月后这个项目停更了，我能不能花一周时间把它换掉？有没有可能，这个技术的核心特性，我现在的老系统花两天就能实现80%？

想清楚这三个问题再动手，比你看十篇技术博客都有用。

别把长期价值导向，做成拒绝改变的挡箭牌

当然也有另一种极端。

很多人一听到要讲长期价值，就开始守着自己十年前写的老代码，说这个东西稳定，不能动，要长期维护。结果呢？那个代码跑在十年前的Python2版本上，连个安全补丁都打不了。去年我们做等保检查，扫出来这个系统十几个高危漏洞，整改的时候才发现，原来写这个代码的人已经离职五年了，连个能正常跑起来的环境都搭不起来，最后只能花了三个月重写。

这哪是长期价值。

这是懒，是怕担风险。

真正的长期价值导向，从来不是让你抱着老东西不放，也不是让你追着新东西跑。是你在做选择的时候，给未来的自己留够转圜的余地。

比如你写后端选技术栈，不是选那个最酷的新语言，是选那种哪怕三五年后，你想换工作，或者公司业务变了，你能很快找到接手的人，不会出现“全公司只有我会写这个，我走了系统就炸”的情况。

比如你写代码的时候，别为了追求“优雅”，搞那种只有你自己能看懂的奇技淫巧。你今天写的炫技代码，半年后你自己回来都要愣半天，更别说后来接手的人了。

技术选型短期长期成本对比手绘表格

我电脑里现在还存着2019年写的一个小脚本，就是用来自动同步服务器日志的。当时写的时候就是嫌每次手动下日志太麻烦，花了两个小时敲完的，没有什么严格的代码规范，甚至连个错误处理都写得很糙。结果到现在，每次服务器出问题，我还是会先跑这个脚本。比后来花了几十万买的商业日志系统好用——因为我知道这个脚本每一行是干嘛的，出了问题五分钟就能改。那些商业系统，找个客服都要等半小时。

说实话，干了快八年开发，我越来越觉得，所谓的长期价值导向，根本不是什么高大上的战略。就是你写每一行代码，做每一个技术选择的时候，别只想着今天能省多少事，要想想，半年后、三年后，你或者别的同事，碰到这个代码的时候，是会感谢你，还是会骂你。

就这么简单。