凌晨两点，你被告警叫醒。打开代码库，函数命名清晰、注释完整，但你需要同时打开七个文件、记住四个隐式约定，才能确定这行日志该不该删。这不是技术债——这是组织结构的倒影。

为什么聪明人总写复杂代码

如果"无聊代码"才是好代码，为什么它如此罕见？复杂代码并非聪明工程师的产物，而是奖励"聪明"的组织的后果。大多数团队之所以能忍受复杂代码，是因为它缓慢累积。但这个缓冲空间正在消失。

无聊代码是组织的体检报告：代码库不仅反映组织——它暴露组织。

因果被说反了

标准职业建议把无聊代码框定为资深工程师苦修得来的美德。这搞反了因果关系。它出现在领导者消除"聪明"激励的地方，一旦激励回归，它便无法存活。

多数绩效考核奖励交付、速度、功能上线。简化几乎从不出现。当有人简化系统，这应该出现在绩效评估里——而不只是团队回顾会。

无聊代码是结构属性，不是审美标准

可读性定义不足。它衡量外观，而非理解。你追踪引用、追逐抽象，实际逻辑却无处可寻。仪式吞噬了代码。

即便找到逻辑，它也不告诉你它知道什么。一个文件可以完美可读，却仍要求你在脑中同时保持五个不变量才能安全改动。这使无聊代码成为系统属性，而非任何单文件的属性。

最简单的诊断：一次改动需要打开多少文件，有多少不变量活在人脑中而非代码里。

前者在版本控制中可读——共变模式、依赖范围。那些总是共变却在类型系统中互不依赖的文件，是组织边界在代码中的显影。它们一起变动并非因为领域要求耦合，而是因为同样的隐性知识需求支配两者。提交图谱是组织架构的自我主张。这不是可读性问题——这是上下文。它先在版本控制中显现，再在任何其他地方出现。

后者难以观测，但症状明显：代码评审中的"这个不能动，因为…"、新人反复踩的同一个坑、那个"你问老王"的系统角落。

组织如何杀死无聊代码

三个信号预示无聊代码正在消亡：

第一，"快速修复"成为美德。紧急补丁绕过正常流程，留下隐式约定。三次之后，约定变成债务。

第二，专家成为瓶颈。当只有一个人能改动某模块，知识未嵌入代码，而是锁在人脑中。这不是人才密度，是单点故障。

第三，简化提案被质疑"价值"。如果重构需要说服三层管理层，系统只会向更复杂漂移。

重建的结构条件

无聊代码需要三件事：时间压力的真实缓解、简化行为的可见奖励、以及允许说"这太复杂了"的安全文化。

前两者是政策问题。第三个是领导问题。当高管在评审中追问"为什么不能更简单"，文化才开始转向。

代码不会自我简化。它需要组织先简化自己。