Javascript

你的错误处理只是安慰剂

打开任何一个前端项目,全局搜索 `catch`,你会看到什么?一大片空荡荡的 catch 块,偶尔跳出几个 `console.error`,再偶尔冒出一行 `message.error('系统异常')`。后端项目也好不到哪去,try-catch 包着业务逻辑,catch 里面的处理方式跟前端如出一辙——记个日志,打个错误码,然后呢?然后什么都没有。

我把这种写法叫"安慰剂错误处理"。它的作用不是解决问题,而是让写代码的人觉得自己处理了问题。就好像感冒的时候吃维C,你做了点什么,但那点什么跟治愈没有关系。

更残酷的事实是:大部分错误处理非但没用,还在制造新的问题。

 

try-catch 不是错误处理,是错误藏匿

 

先说一个很多人不愿意承认的事:try-catch 是所有错误处理手段里最廉价的那一种。它的成本最低,所以它的价值也最低。

我见过太多这种代码:一个函数内部包了三层 try-catch,每一层都把异常吞掉,最外层返回一个 `{ success: false, message: '操作失败' }`。调用方拿到这个返回值,判断 `success` 为 false,然后弹个 toast —— "操作失败"。用户看到这四个字,内心毫无波澜,因为他已经见过一千次了。

重构冲动:写下代码的那一刻才是你最清醒的时候

每个工程师都有过这种时刻——翻开一段半年前写的代码,眉头一皱,手指开始痒。"这什么写法?""这命名谁看得懂?""这段逻辑完全可以抽象成三个函数。"然后一个"重构"的念头冒出来,越来越强烈,像夏天傍晚的蚊子,赶不走。

这种冲动太普遍了,以至于我们很少质疑它。代码审查时建议重构,结对编程时讨论重构,技术债清单里排满了重构项,季度规划里少不了"代码优化"的工时。重构似乎天然正确,像一种工程美德。

但我的观察恰恰相反:大部分重构是错误的决定。不是重构这件事有问题,是驱动重构的动机和时机几乎总是错的。

 

丑代码不等于坏代码

 

先说一个多数人不愿意接受的事实:代码的审美和代码的质量,经常是两回事。

一段看起来笨拙的代码,可能在一个微妙的时间窗口里正确处理了并发竞争。一段到处是硬编码的代码,可能正是因为硬编码才避免了配置出错引发线上故障。一段三百行的函数,可能是经过六次需求变更后唯一还hold得住的逻辑形态——你把它拆成六个"优雅"的函数之后,任何一个需求的变更都会涉及三个函数的修改,追踪数据流变成了噩梦。

"丑"是主观判断,"坏"是客观后果。两者之间没有必然因果关系,但在重构决策里,它们经常被混为一谈。工程师看到不美的代码就判定它需要重构,这个推理本身就是逻辑谬误。

"能者多劳"是技术团队最隐蔽的陷阱

团队里总有那么一两个人,什么活都能干,什么锅都能扛。需求来了找他,线上出问题找他,新技术调研找他,代码评审也想拉他。他的日历永远排得最满,他的PR永远是别人等Review最久的那个。

大家都觉得这是"能力强、受重视"的体现。管理者也觉得,把重要的活交给靠谱的人理所当然——毕竟谁能放心把核心模块交给新人?

但我要说一个可能得罪人的判断:"能者多劳"不是在重用人才,是在消耗人才。而且这种消耗有一个特别迷惑人的地方——它看起来像是信任,感觉起来像是被需要,唯独结果不是被成全。

 

看起来是信任,实际上是惩罚

 

考虑一个很常见的场景。

项目要赶排期,核心功能必须本周上线。你会交给谁?当然是那个靠谱的资深工程师,因为交给别人你不放心,延期了你担不起。

线上出了Bug,排查要理解完整链路。你会交给谁?还是那个人,因为只有他能从数据库一路追到前端渲染。

新人入职需要导师,你会选谁?又是他,因为他技术好、有耐心、能讲清楚。

看起来这个人得到了最大的信任,承担了最重要的工作。但仔细想想,他得到了什么?更多的工作。更满的日历。更少的写代码时间。更晚的下班时间。而那些干得一般的人呢?他们的工作量反而更少,因为没人找他们。

AI代码助手的过度编辑:改得越多亏得越多

我最近注意到一个挺有意思的现象:团队里用AI编程工具最积极的那几个人,代码变更量差不多是其他人的3倍,但需求交付速度并没有快3倍。仔细看了一下,有些人的单个bug修复,diff比需求本身还长。

这不是个例。当你跳出"AI提效"的叙事,认真看AI代码助手在项目中留下的痕迹时,会发现一个被忽略的问题——AI有天然的过度编辑倾向,而且这种倾向正在悄悄地侵蚀代码库的健康度。

 

AI的"讨好型人格"

 

先说一个可能很多人没太注意的事:AI代码助手本质上是有讨好倾向的。

你让AI修一个空指针异常,它不光改了那行判空逻辑,还顺手调整了方法签名,给相关变量补了类型注解,甚至把异常处理的模式也给重构了。每一步看起来都合理,每一步单独拎出来都是"改进",但加在一起,你只是为了改一个判空,变了三十行代码。

AI为什么这样?因为它的训练体系中,"提供有价值的回答"是一个核心信号。对AI来说,只改一行和改三十行,哪个更像"用心回答"?更关键的是,你问AI"还有没有可以改进的地方",它几乎不可能说"没有了,当前代码已经很好"——它会找出所有能优化的点,然后一股脑全给你改掉。

前端性能优化的尽头是架构问题

每次聊性能优化,话题总是很快滑向具体的技术手段:懒加载、代码分割、图片压缩、Tree Shaking、虚拟列表……这些当然有用,但我想说一个可能让不少人不太舒服的判断——当你在做这些"优化"的时候,大概率已经晚了。 真正决定性能天花板的,不是你用了多少优化手段,而是系统架构在最初就给你画了多高的天花板。

性能问题从来不是前端单方面的问题。但很多团队把它当成了前端的问题,于是前端工程师就像一个装修工人,在毛坯房里拼命贴墙纸——墙纸再好看,承重墙没打好,房子一样不牢。

 

优化手段的天花板

 

先承认一个事实:常规的性能优化手段确实能解决一部分问题。一个从没做过任何优化的项目,加上代码分割和懒加载,首屏时间砍一半不稀奇。图片做个WebP转换、加个CDN,LCP直接降几百毫秒。这些是低垂的果实,摘了就是摘了,没人否认。

但问题是,这些优化有上限。你的首屏要从3秒优化到1.5秒,代码分割和懒加载就够了。但如果你要从1.5秒到800毫秒,甚至到500毫秒以内,单靠前端手段就力不从心了。因为剩余的耗时大头不在前端——它在网络请求、在服务端处理、在数据组装、在协议开销。

当配置比代码还复杂:配置化平台的真实边界

配置化平台这两年在金融和电商领域特别火。业务方想要灵活调整页面,需求排期又排不开,于是"配置化"三个字成了万能解药——做活动页?配置化。改文案?配置化。调整布局?配置化。好像只要搞一个配置平台,所有迭代效率的问题就烟消云散了。

但我想说一个可能得罪人的判断:大部分团队的配置平台,最终都变成了另一个更难维护的代码库。 只不过这个代码库没有版本控制,没有代码审查,调试靠肉眼,回滚靠运气。

 

配置化的承诺

 

先承认一个事实:配置化的出发点是对的。

在金融业务里,一个理财产品的详情页可能每周都要调整——改一个利率展示规则、加一个风险提示文案、换一个活动入口。这些需求的特点是:变频繁、逻辑简单、但等不及排期。 如果每次都走完整的需求-开发-测试-发布流程,前端团队光是接这些零碎需求就别干别的了。

配置化要解决的核心问题很清楚:把高频、低风险的变更从开发流程中剥离出来,让业务方自助完成。

这个思路本身没问题。问题出在执行上。

 

第一个陷阱:配置化的范围蔓延

 

几乎所有配置平台都经历了同样的演化路径。

你以为在管人,其实你还在管事

博客分类: 

有个现象我一直觉得很有意思:很多技术Leader当了Leader之后,比当个体贡献者时更忙了。

这不正常。

如果你的管理是有效的,你应该比以前更闲才对——因为你把事情分出去了,别人在做。但现实是,大部分Leader的日常是这样的:早上站会听进度,上午review代码,下午排需求优先级,晚上还要处理线上问题。忙得脚不沾地,但回头一看,团队离了你好像啥也干不了。

你以为这是"能者多劳",其实这是一个信号:你根本没在管人,你还在管事。

 

管事和管人,不是同一件事的两种叫法

 

我见过不少刚做管理的朋友,聊起来都说"我在带团队"。但你仔细看他们的工作内容:拆任务、派活、盯进度、review产出、解决技术卡点……这些是管事还是在管人?

都是管事。

区别很简单:管事关注的是"事情有没有做好",管人关注的是"人有没有成长"。前者是项目管理的范畴,后者才是团队管理的核心。

这个区分听起来像废话,但大部分技术Leader从来没认真想过这个问题。因为在工程师的世界观里,把事情做好就是一切。升Leader之后,自然也觉得"把团队的事情管好"就是管理。

晋升体系的谎言:为什么优秀工程师升不上去

博客分类: 

上个月团队晋升答辩,有个同事没通过。技术能力很强,项目执行也不错,但评委说"影响力不够"。我问他怎么看,他说:"我就是想写好代码,为什么非要搞那些虚的?"

我能理解他的委屈。在很多公司,晋升体系名义上是"能力导向",实际上是另一套游戏规则。技术好不一定能升职,会讲故事、懂包装、有人脉的反而更容易上去。

但这真的是体系有问题吗?还是我们对晋升本身就有误解?

 

晋升评的不是技术能力,是组织价值

 

大部分工程师对晋升的理解是:我技术能力达标了,就应该升职。但公司的逻辑是:你对组织的贡献达到下一个级别了,才值得升职。

这两个标准完全不是一回事。

一个高级工程师可能写代码能力很强,但如果他只是完成分配的任务,没有带来超出预期的价值,那在组织眼里他就是"合格的高级工程师",而不是"应该晋升的资深工程师"。

组织价值不是技术能力的简单加法,而是:在当前级别,你解决了多少原本不属于你职责范围内的问题。

技术决策的囚徒困境:为什么正确的方案总是输给能落地的方案

做了这么多年技术,我发现一个挺有意思的现象:几乎每次技术方案评审,都会有人提出一个"理论上最优"的方案,但最后落地的,往往是那个"看起来不够优雅"的方案。

这不是偶然。背后有一套残酷的逻辑。

 

那个"完美方案"为什么总是死在会议室里

 

上周技术评审会,前端团队提出要引入微前端架构,理由很充分:模块解耦、独立部署、技术栈自由、团队自治。PPT做得精美,架构图画得漂亮,甚至连落地路线图都准备好了。

然后架构师问了一句:"谁来维护基座?iframe降级方案谁负责?跨应用通信出问题谁排查?"

会议室安静了30秒。

最后的决定是:继续用现有的Monorepo + 模块化方案,虽然不够"先进",但团队都熟悉,出问题知道怎么修。

这不是个例。我见过太多"技术上正确"的方案,死在各种现实问题上:

- 服务化改造,拆到一半发现团队根本撑不起这么多服务
- TypeScript全面迁移,三个月后发现一半团队还在用any
- GraphQL替代REST,半年后发现后端团队都不会写resolver
- Kubernetes上云,结果运维团队连基本的Pod调试都不会

产品经理说的和工程师听到的为什么总是两回事

有个场景在金融科技公司几乎每周都会上演:产品经理说"这个需求很简单,就是加个按钮",工程师听到的是"又要改架构"。

会议室里的氛围瞬间凝固。产品经理觉得技术团队在找借口,工程师觉得业务方根本不懂技术。双方都没说错,但都没说对。

这不是沟通技巧的问题,是认知框架的断层。

 

信息在组织边界丢失

 

我观察过一个现象:同一个需求,产品经理在需求评审会上讲五分钟,工程师回去讨论要两小时。

不是工程师理解力差,是信息在跨部门传递时发生了质变。

产品经理说"支持用户自定义理财目标",他脑子里是一个完整的业务场景:用户设定目标金额和期限,系统推荐合适产品,定期提醒达成进度。这个场景在产品原型里是完整的,在用户故事里是清晰的。

但工程师听到的是什么?

前端听到的是:新增表单、字段校验、状态管理、埋点上报。后端听到的是:数据库表设计、接口规范、权限校验、数据迁移。全栈工程师听到的更复杂:前后端联调、缓存策略、异常处理、监控告警。

同样五个字,解析出来的工作量相差十倍。

这就是组织边界的代价。产品经理思考的是"用户价值",工程师思考的是"技术实现"。两者的抽象层级不在同一个维度,信息当然会失真。

页面