每天一条软件法则：复杂度守恒定律

由于vibe coding已让编码变得不再是问题，但是具备良好的软件思维却比以往更加重要，这里每天更新一条软件法则，让我们一起每天进步一点点。

第 9/56 条
1️⃣ Tesler’s Law (Conservation of Complexity)（特斯勒定律 / 复杂度守恒定律）

2️⃣ 核心定义
每个应用都存在一定数量无法消除的内在复杂度；设计能做的不是让复杂度凭空消失，而是决定由用户、产品、代码、平台或运维中的哪一方来承担它。

3️⃣ 解决的问题
它解决的是“把界面做简单就等于系统简单”的误解。很多复杂度来自问题本身，比如权限、支付、排期、状态流转、数据一致性和异常恢复。你可以把它藏到默认值、算法、自动化流程或后台任务里，也可以把它交给用户手动处理，但总有人要承担这部分复杂度。

4️⃣ 软件工程实践案例
会议排期本身很复杂：参与人时区不同、日程冲突、会议室可用性不同。一个简单的邮件来回确认方案，把复杂度丢给用户；一个排期工具则把复杂度放进系统内部，自动读取空闲时间、处理时区、生成候选时间并发送邀请。用户体验变简单了，但系统内部需要承担更多规则、集成和异常处理。

5️⃣ 一条建议
今天评审一个功能时，不只问“能不能再简单一点”，还要问“这部分复杂度现在被谁承担”。如果复杂度落在用户身上，看看能否通过合理默认、自动校验、后台计算或渐进式表单把它移回系统。边界也要清楚：不是所有复杂度都应该由系统承担；对低频专家功能、强合规场景或需要人工判断的决策，保留显式步骤反而更安全。

6️⃣ 思考题
你当前产品里有没有一个看似“灵活”的设计，实际是在让用户承担本该由系统处理的复杂度？如果要把这部分复杂度移回系统，最小的一步是什么？