精华社 · 藏经阁

外观

简单是难的事

约 1154 字

简单是难的事

达芬奇那句被引用烂了：「简单是复杂的终极形式」。 年轻时觉得是鸡汤，现在信了 —— 因为见过太多 「把简单搞复杂」的现场，包括我自己。

一、复杂是默认的

为什么复杂这么容易？

代码：
  加功能 → 加 if → 加参数 → 加配置 → 加「以防万一」的抽象
  每一步都「就加一点」，一年后没人看得懂全貌

生活：
  买工具 → 装插件 → 配工作流 → 优化「优化」本身
  每步都「就升级一点」，最后折腾代替了产出

写作：
  堆术语 → 加从句 → 引用名言 → 写「全面的」长文
  最后自己都不想读

复杂是「加法思维」的默认终点 —— 不动脑子就会滑向它。简单需要「主动的减法」， 而减法比加法难：加东西有快感，删东西有痛感。

二、简单的三个层次

1. 代码的简单

// ❌ 复杂：为「未来可能的需求」提前设计
class AbstractOrderProcessorFactory {
  create(strategy: Strategy): Processor { … }
}
// 实际只有一种订单，一个函数能写完

// ✅ 简单：现在的需求，现在的形状
function processOrder(order: Order): Result { … }

原则：先写「够用的丑」，等第二个需求来了再抽象。 「以防万一」的抽象，万一没来，你就养了一辈子。 （本站的工具疲劳 讲的是同件事。）

2. 系统的简单

微服务、中台、各种「先进架构」 ← 复杂
「一个服务 + 一个数据库 + 缓存」   ← 简单

架构的复杂度应该匹配「当前规模」，不是「想象中五年后」。 五个人的团队搞微服务，是把运维成本乘以五， 换「听起来先进」。

本站就是「简单」的实践：一个静态站， 没有运行时、没有微服务、没有花活 —— 但稳定跑了很久。

3. 表达的简单

❌「本文旨在探讨一种基于响应式原理的状态管理范式转换」
✅「数据变了，页面自己会更新。Vue 就是这么干的。」

说人话是表达层的简单，也是我写文章的死磕项 —— 每个术语都想翻译成大白话，除非「术语本身就是 最简洁的说法」。

三、怎么做减法

代码里

  1. 删优于改：重构时先问「这段能删吗」 —— 没人调的代码，删（小心反射调用， 重构实录 的坑）；
  2. 配置优于硬编码，但「不用配置」优于配置 —— 加配置项 = 加复杂度，先问「真的需要可配吗」；
  3. 一个概念一个名字：同一个东西三个别名， 是复杂度批发商；
  4. 定期「大扫除」：季度一次， 「三个月没用过的功能/参数/抽象」，删。

生活/工作里

  1. 工具少而熟：三个用烂的工具 > 三十个尝鲜的 （效率工具 的结论）；
  2. 会议默认 25 分钟：时间是零和的， 短会逼出简洁；
  3. 「待办」不超过 5 条：排优先级就是排人生， 什么都做 = 什么都做不好；
  4. 信息源精而少：三个 Newsletter > 三十个订阅。

四、简单 ≠ 容易

澄清一个误解：简单的结果，过程可能很艰难。

把 3000 行改成 800 行    ← 简单的结果，一个月的活
（[重构实录](./refactor-story/)）

一句话讲清一个原理      ← 简单的表达，三天的查证
（本站每篇文章的背后）

苹果遥控器一个按钮       ← 简单的设计，十年的打磨

「简单」是「复杂被消化之后的样子」。 Skipping 消化的「简单」是简陋， 消化完的简单才是简单。

五、检验标准

怎么知道「够简单了」？三个问题：

1. 新人能一眼看懂结构吗？（代码/文档/系统）
2. 改动时，需要「记住的上下文」少吗？
3. 解释它，需要超过三句话吗？

三个都是「是」，就是简单。 本站的文章标准是第三条 —— 三句话讲不清的， 是我还没想明白，不是读者笨。

六、写在最后

越来越觉得，「会做减法」是成熟工程师的标志：

  • 年轻时比「谁加的功能多」；
  • 现在比「谁能删的代码多、谁能把话讲短、 谁能把系统搞小」。

复杂是世界的默认状态，简单是你的作品。 每次「删掉一个抽象」「砍掉一个配置」「把长句改短」， 都是在对抗熵增 —— 手感很好，推荐试试。