前端项目重构后的绩效困境

我重写了整个项目，但没人感谢我！

之前带过大大小小的业务线： 一个前端工程师，花了整整三个月，把团队一个跑了四年的祖传项目从 Webpack 4 迁移到了 Vite ，顺手把 JavaScript 全量改成了 TypeScript ，修了 300 多个类型错误，重构了整个请求层，接入了 Sentry 错误监控，搭建了完整的 CI/CD 自动化流水线。 迁移完成后，构建时间从 4 分钟降到了 12 秒，线上报错率下降了 60%，新人上手时间从两周缩短到了三天👋。 然后到了季度绩效评审，他却拿到了一个 符合预期😃 。 做的越多越好吗？ 基建工作有一个极其残酷的性质—— 它的成功，是以什么都没发生来衡量的。 你搭建的 CI/CD 流水线，在每次合并 PR 时自动跑完测试、自动构建、自动部署。当它正常运转时，没有人意识到它的存在。只有当它挂了的那天，所有人才会突然想起来： 哦对，这个东西是谁维护的？🤔 你重构的请求层，把所有接口的错误处理、竞态取消、Token 刷新统一收口了。上线后，线上白屏事故从每周两三次降到了零。但没有事故这件事，在绩效评审的叙事里是 不存在的 ——因为你没办法证明 如果我没做这件事，会出多少事故 。 绩效的底层逻辑什么？ 你必须理解一个极其冷酷的事实：绝大多数公司的绩效评审系统，底层逻辑是 输入 → 产出 → 业务结果的线性因果链 。 这条链对功能开发极其友好： 产品提了需求 → 我开发了分享按钮 → 分享率提升 15% → 商业价值 因果清晰，归因明确，老板一看就懂🤔。 但基建工作的价值链是这样的： 我迁移了 TypeScript → 团队的类型错误减少了 → 线上 Bug 率下降了 → 用户投诉少了 → 客服成本降低了 → …… 你看到问题了吗？从你的工作到最终的商业结果之间，隔了 四五个因果环节 。每多一个环节，归因就模糊一层。到了老板那里，他看到的是本季度客服投诉下降了，但他会把功劳归给客服团队的培训优化，或者产品的流程改进，绝不会想到是三个月前一个前端工程师做的 TypeScript 迁移。 技术语言是最昂贵的沟通障碍！ 我见过太多这样的述职 PPT ： 本季度完成了项目从 Webpack 到 Vite 的全量迁移，构建产物从 CommonJS 统一为 ESM ，开发环境冷启动时间从 240 秒优化到 12 秒，HMR 热更新从 3 秒降到 200 毫秒。同时完成了全量 TypeScript 迁移， strict 模式覆盖率 100%，消除了 327 个隐式 any 类型。 评审委员会里坐着的，大多是业务方向的技术管理者。他们听完的第一反应是： 然后呢？这些对业务有什么影响？ 你说构建时间从 240 秒降到 12 秒，他不知道 240 秒意味着什么。你说消除了 327 个 any ，他不知道 any 是什么😑。你以为这些数字极其震撼，但在对方的认知框架里，这些就是一堆无法和商业价值挂钩的技术黑话。 如何破局 如果你已经在做基建工作，或者即将承担一项重大的技术迁移，以下是你必须在 第一天 就开始做的事情——不是写完之后补，是从立项那一刻就同步进行👇。 迁移之前，先去量化代价 在你动第一行代码之前，先花一天时间，把旧系统造成的痛苦 用数字记录下来 ： 迁移之后呢？ 同样的工作，换一种语言，在绩效评审中的得分是天壤之别。 最后说一句不太好听的话 如果你做完了以上所有事情——量化了价值、翻译了语言、做了过程可视化——你的 Leader 和公司依然觉得基建工作不值一提🤔…… 那这不是你的表达能力问题， 这是组织的价值观问题 。 一个不愿意为基础设施投入尊重和资源的公司，最终一定会为此付出极其惨烈的代价——当线上事故因为年久失修的基建接连爆发时，那些曾经做过基建、被寒了心、最终离开的工程师，不会再回来救火🫡。 共勉🙌 喜欢我的文章，也欢迎关注我的微信公众号：【前端技术官】。 主要分享： 前端架构 · AI 编程 · 职场认知 · 开发者成长 微信扫码关注 👆 不定期更新，不刷屏，聊点真正有用的干货。