周一早上打开日历，发现这一周已经被各种颜色的色块填满了。晨会、周会、评审会、对齐会、架构讨论会、需求评审会……还没坐下来写一行代码，一天就过去了。剩下的时间再打开 Slack 回几条消息，真正专注的时间碎片化到不可能做任何需要深度思考的事情。

这不是某个人的问题，是整个技术团队的通病。几乎所有技术管理者都抱怨过"会议太多"，但有意思的是，抱怨完之后，大多数人还是继续安排会议、接受会议，甚至主动拉会。这种言行矛盾本身就值得琢磨。

信息同步？别自欺了

会议最常用的理由是"信息同步"或者"对齐"。但仔细想想，你上一次在会议中真正获得关键信息是什么时候？绝大多数会议的信息流向是单向的：一个人讲，其他人听。这叫广播，不叫同步。

更常见的情况是，会议的前十分钟在等人，中间二十分钟在重复上周说过的话，最后十分钟草草收场。真正有信息量的部分，可能五分钟就能说完。但五分钟的会议不符合惯例，也显得不够重视。

我曾经观察过一个现象：技术团队里信息传递效率最高的时刻，往往不是在会议中，而是在工位上随口问一句、在 IM 里发一条消息、或者在 MR 的 comment 里写一段话。这些非正式的信息交换反而更精准、更及时，因为它们是在具体问题的上下文中发生的，不是为了开会而开会。

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

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

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

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

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

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

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

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

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

丑代码不等于坏代码

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

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

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

又一起线上事故。凌晨三点的告警，值班同学爬起来处理，应急响应、回滚、止血，一气呵成。第二天上午，事故复盘会准时召开。PPT做得很漂亮，时间线梳理得清清楚楚，根因分析写得明明白白，action items列了七八条。所有人都认真地点了点头，表示"以后一定注意"。

三个月后，同一个系统，同一类事故，再次发生。

这个场景太熟悉了。每个经历过线上事故的技术人，大概都对这种循环不陌生。复盘会开了一轮又一轮，文档写了一篇又一篇，"改进措施"列了一条又一条，但该来的事故还是会来，该踩的坑还是会踩。

问题到底出在哪？

复盘变成了一场仪式

大部分复盘会的真实目的，早就不是"从错误中学习"了。它承担的职能更接近一种组织仪式——事故发生了，总得有个交代。复盘会就是一种交代：你看，我们重视了，我们分析了，我们有改进计划了。

这种仪式感会带来一个隐蔽的副作用：它让所有人都觉得事情正在被处理。管理者觉得团队在反思，团队觉得管理者在推动改进，大家心里都松了一口气。但"感觉在改进"和"真实在改进"之间，隔着一道巨大的鸿沟。