《Unix 编程艺术》笔记：无为而治的操作系统版——不写多余的代码

方糖猫 方糖猫
- 约 26 分钟读完 - 全文 10335 字

《Unix 编程艺术》笔记：无为而治的操作系统版——不写多余的代码

目标读者：写过一两年代码、开始困惑"为什么有的系统越改越烂"的程序员。
参考书籍：Eric S. Raymond《The Art of Unix Programming》（TAOUP，2003）
阅读目标：把 Unix 哲学从"背口诀"变成"做决策的直觉"，知道什么时候不写代码才是正确答案。

0. 写在前面：这本书其实在讲"无为"

老子的"无为而治"常被误解成"什么都不做"。它的真实意思是：不妄为、不多为、让事物按自己的规律运转，治理者只搭最小的框架。这篇博客的姊妹篇（道家经典笔记）里聊过这个，但当时我没想到，技术世界里有一套哲学和它是镜像关系——Unix 哲学。

《Unix 编程艺术》这本书表面上是讲操作系统历史、讲工具、讲惯例，但通读下来，它的主线只有一句话：

好的设计，是让每样东西只做一件事、把它做好，然后靠组合解决大问题——你写的代码越少，系统越长寿。

这就是"无为"的操作系统版：

  • 无为 ≠ 不写代码，而是不写多余的代码（吝啬原则、经济原则）；
  • 无为而治 ≠ 没有规则，而是规则极少且稳定，万物在规则下自由组合（组合原则、文本流接口）；
  • 为而不恃 ≠ 没有接口，而是接口低调透明，不强迫用户感知它（透明原则、缄默原则）。

后面所有的原则、公案、争论，都是这一条主线的展开。先记住主线，再看细节，就不会把 17 条原则背成口诀表。

1. 一句话理解 Unix 哲学

关于 Unix 哲学有很多版本的一句话总结，流传最广的是 Doug McIlroy（管道的发明人）在 1978 年《Bell System Technical Journal》里写的那段：

让每个程序只做好一件事。要做新功能，就写个新程序，而不是给旧程序加"特性"把旧程序搞复杂。

再加两句配套的：

让每个程序的输出，都能成为另一个（还没写出来的）程序的输入。不要因为无关信息把输出搞得花里胡哨。

以及后世程序员最爱引用的简版：

Do one thing and do it well.（做一件事，把它做好。）

注意 McIlroy 原话里最关键、也最容易被忽略的半句：“要做新功能，就写个新程序”。这不是审美洁癖，而是工程判断——往旧程序里加功能，会把原本干净的工具变成一坨没人敢动的遗留代码。这条在后面 cat -v 之争里会血淋淋地再出现一次。

2. 十七原则全景：哪些是"宪法"，哪些是"实施细则"

TAOUP 第一章把 Unix 哲学整理成了 17 条原则。我不打算逐条复述（那是目录，不是消化），先给一张全景图，再挑出真正管用的五条深讲。

mindmap
  root((Unix哲学<br/>无为=不写多余代码))
    核心五条
      简单原则
        能简单就别复杂
        KISS
      组合原则
        程序互相连接
        文本流是通用接口
      透明原则
        一眼看穿在干嘛
        可调试可维护
      缄默原则
        没话就别说话
        输出即接口
      经济原则
        程序员时间最贵
        宁写一次脚本不重复劳动
    设计姿态
      模块原则
        清晰接口的简洁部件
      分离原则
        策略与机制分离
        接口与引擎分离
      吝啬原则
        小即是美
        除非必要别写大程序
    工程纪律
      清晰原则
        清晰胜过机巧
      稳健原则
        稳健源于透明加简单
      补救原则
        出错要吵要死得早
      优化原则
        先求跑通再求跑快
    生态智慧
      表示原则
        把知识叠进数据
      通俗原则
        最小惊讶原则
      生成原则
        能生成就不手写
      多样原则
        拒绝唯一正确方式
      扩展原则
        为将来留余地

2.1 哪些是宪法？

17 条不是平权的。我自己的判断（也是 Raymond 书里的隐含排序）：

  • 宪法级：简单、组合、分离。这三条决定系统的基本骨架，违反了就救不回来。
  • 日常纪律级：透明、缄默、吝啬、经济、清晰、补救。这些决定你每天写代码的手感。
  • 生态智慧级：表示、生成、多样、扩展、优化、通俗、稳健。这些决定系统活十年之后的样子。

下面只深讲五条最核心、也最容易被违反的。

2.2 简单原则（Simplicity）：能简单就别复杂

原文：Design for simplicity; add complexity only where you must.

这是所有原则的根。复杂软件的问题不是"难写"，而是难改、难测、难理解——复杂度是利息，每次改动都在还息。

程序员最常见的自欺是：“这个功能以后肯定用得上，先设计成通用的。“结果通用框架写好了三年，那个"以后"从没来过，而每个新人都得先学懂这个没人用的框架才能干活。

避坑指南：当你设计一个系统需要超过一页纸才能向新同事解释清楚时，先怀疑设计，而不是怀疑新同事。

2.3 组合原则（Composition）：程序要能被"接"起来

原文：Design programs to be connected with other programs.

这条是 Unix 真正的独创，也是它和同时代其他操作系统最大的区别。别的系统里，程序是一个个孤岛，各干各的；Unix 里的程序天生设计成可以被串起来——输入是文本流，输出也是文本流，于是任何两个程序都能被一根管道接起来，哪怕写第一个程序的人根本不知道第二个程序的存在。

这条原则的威力在第 4 节的 McIlroy 公案里会展现得淋漓尽致。先记住一个推论：

一个程序如果不能被组合，它的能力上限就是它自己的代码量；一个能被组合的程序，能力上限是整个系统里所有程序的能力之积。

2.4 透明原则（Transparency）：一眼看穿系统在干嘛

原文：Design for visibility to make inspection and debugging easier.

透明性的标准是：系统的行为能不能被一个普通工程师"看出来”，而不是"猜出来”。

反面教材：配置写在一个神秘的二进制数据库里、错误码只有厂商文档能查、出了问题只能重启看运气。正面教材：配置文件是文本、日志是人话、strace 一看就知道进程在干什么。

工程连接：现在面试常考的"可观测性"（observability）——metrics、tracing、structured logging——本质上就是透明原则在云原生时代的重新发明。50 年前 Unix 用文本和管道做的事，今天我们用 OpenTelemetry 再做一遍。

2.5 缄默原则（Silence）：没话就闭嘴

原文：When a program has nothing surprising to say, it should say nothing.

这条最反直觉，新手程序员最爱犯：程序跑成功了，打印一行"操作成功完成！"；循环处理一万条数据，每条打一行进度。

为什么这是错的？因为 Unix 程序的输出是接口。ls | wc -l 能数出目录里有几个文件，前提是 ls 不会在末尾加一行"共 42 个文件，查询成功！"。一句多余的人话，对人是客气，对下游程序是脏数据。

工程连接：这条在今天的对应物是日志纪律——INFO 级别不该打印"一切正常"的心跳废话，告警不该在无事发生时刷屏。告警疲劳（alert fatigue）就是缄默原则被违反的现代版本：狼来了喊一千次，真的狼来了没人理。

2.6 经济原则（Economy）：程序员的时间比机器的时间贵

原文：Programmer time is expensive; conserve it in preference to machine time.

1970 年代机器慢、人便宜，这条原则在当时是革命性的；今天机器快得离谱、工程师年薪以十万计，这条原则更加正确。推论是：

  • 能用 shell 脚本十分钟糊出来的临时工具，就别开 IDE 建工程写三天；
  • 能用高一级的语言（当年是 C vs 汇编，今天是 Python vs C++）表达，就别用低一级语言省那点机器时间；
  • 机器闲着的每一秒都不值钱，你加班的每一小时都很值钱。

这条原则是"无为"最直接的落地：能不做就不做，能少做就少做，把省下来的时间花在那件真正值得做的事上。

3. 管道与过滤器：Unix 哲学的物理化身

3.1 一夜诞生的管道

管道（|）的故事是软件史上最著名的"一夜奇迹"之一，值得完整讲一遍：

  • 1964 年，Doug McIlroy 就在贝尔实验室的内部备忘录里写下了类似的想法：“我们应该有某种方法，能把程序像花园水管一样接起来——把一段数据拧进另一段。"（“We should have some ways of coupling programs like garden hose."）
  • 想法提了快十年，一直没人实现。
  • 1973 年的一天，McIlroy 又一次向 Ken Thompson 提起这个想法。Thompson 当晚回家，一夜之间修改了 Unix 内核和 shell，把管道做了出来，顺手改了一批工具让它们能配合管道工作。
  • 第二天早上，管道就成了 Unix 的永久居民。

McIlroy 后来回忆，那是 Unix 历史上最重要的时刻之一——一个想了十年的概念，被一个理解它的人用一晚上变成了现实。这个故事同时也是经济原则的最佳注脚：想清楚了再动手，动手就是一夜的事；没想清楚的团队，开会开十年。

3.2 文本流：最简陋也最长寿的通用接口

管道为什么能串起一切？因为所有程序约定了同一个数据格式：字节流，惯例上是按行组织的文本。

这个接口"简陋"到可笑——没有 schema、没有类型检查、没有版本号。但正因如此：

  • 1970 年写的程序，输出可以被 2023 年写的程序消费，中间隔了半个世纪、几代程序员、无数硬件更迭；
  • 任何新程序只要读 stdin、写 stdout，立刻自动获得与系统里所有工具组合的能力，不用跟谁谈判、不用签接口协议。

对比一下同时代的其他方案：IBM 的作业控制语言 JCL 要你先定义数据集格式，各种 RPC 框架要你先对齐接口定义。它们都更"严谨”，也都更快地死掉了。文本流活了 50 多年，至今是你每天 kubectl get pods | grep xxx | awk '{print $1}' 时正在用的东西。

一句话理解：文本流是接口设计里的"中庸之道”——结构刚好够工具处理（按行、按空格分列），又松散到谁都能产生、谁都能消费。

3.3 过滤器模式：把程序写成水管中间的一截

管道催生了一种程序形态：过滤器（filter）——从 stdin 读，变换一下，往 stdout 写。grep、sort、uniq、awk、sed、tr 全是过滤器。

过滤器的可怕之处在于乘法效应：系统里有 N 个过滤器，理论上就有 N! 种串法（当然实际有意义的少得多，但数量级是对的）。每新增一个过滤器，系统的总能力不是 +1，而是 ×N。

flowchart LR
    A["输入: 任意文本<br/>(文件/网络/进程输出)"] --> B["过滤器1<br/>grep/sed/tr"]
    B --> C["过滤器2<br/>sort/awk"]
    C --> D["过滤器3<br/>uniq/wc/head"]
    D --> E["输出: 依然是文本<br/>可继续被消费"]
    B -. "每个程序只做一件事" .-> B
    C -. "接口统一为文本流" .-> C
    D -. "组合出无限可能" .-> D

工程连接：这个模式的后代到处都是——MapReduce 的 map/reduce 是大规模版过滤器，Kafka 的 stream processing 是分布式版管道，React 的数据流、shell 出身的 Unix 老兵们设计的 CI/CD pipeline，全是同一张脸。

4. 经典公案：六行 shell 挑战 Knuth

这是软件史上我最喜欢的公案，没有之一，必须完整讲。

4.1 背景：Bentley 出题，Knuth 接招

1986 年，Jon Bentley 在《Communications of the ACM》的"Programming Pearls"专栏出了一道题：给定一个文本文件和一个整数 N，输出出现频率最高的前 N 个单词及其次数。

出题的目的不是真缺这个功能，而是想展示当时最时髦的编程方法论。Bentley 请来了 Donald Knuth——图灵奖得主、《计算机程序设计艺术》作者——用他发明的**文学编程（literate programming）**来解答。

Knuth 交了一份大约十页的 WEB 程序（Pascal 代码与散文交织），精心设计了哈希表、用 trie 变体做词频统计，数据结构精巧、行文优雅，是文学编程的样板戏。

4.2 McIlroy 的评论：六行管道

Bentley 随后请 Doug McIlroy 写评论。McIlroy 先客气地称赞了 Knuth 的程序，然后平静地指出：这个任务，用 Unix 工具六行就能做完，而且更好——因为每一行都是久经考验的现成工具，没有一行是新写的、可能有 bug 的代码：

tr -cs A-Za-z '\n' |
tr A-Z a-z |
sort |
uniq -c |
sort -rn |
sed ${1}q

逐行翻译：

  1. tr -cs A-Za-z '\n'：把所有非字母字符换成换行——文本变成"每行一个词"；
  2. tr A-Z a-z：全部转小写——“The"和"the"算同一个词；
  3. sort：排序——相同的词现在挨在一起；
  4. uniq -c：合并相邻重复行并计数——每行变成"次数 单词”；
  5. sort -rn：按数字逆序排——高频词浮到顶部；
  6. sed ${1}q：只保留前 N 行（N 从命令行参数来）。
flowchart TD
    T["原始文本<br/>The quick brown fox<br/>the lazy dog"] --> S1["tr: 拆成单词<br/>每行一个词"]
    S1 --> S2["tr: 统一小写<br/>消除大小写干扰"]
    S2 --> S3["sort: 排序<br/>相同单词聚到一起"]
    S3 --> S4["uniq -c: 计数<br/>2 the<br/>1 brown<br/>1 dog"]
    S4 --> S5["sort -rn: 按频次降序"]
    S5 --> S6["sed Nq: 取前N名"]
    style S1 fill:#e8f4e8
    style S2 fill:#e8f4e8
    style S3 fill:#e8f4e8
    style S4 fill:#e8f4e8
    style S5 fill:#e8f4e8
    style S6 fill:#e8f4e8

4.3 这场公案到底说明了什么

Knuth 本人输了吗？没有。他的哈希 trie 在大规模数据上确实更快，而且十页程序的初衷是展示文学编程，不是交付生产工具。这场公案真正的价值在于 McIlroy 的评论里那几句话的杀伤力：

Knuth 的程序里，每个数据结构都是新的、都需要正确性证明；shell 管道里没有一个数据结构是新的，sort 和 uniq 已经被全世界的人每天用了十几年。

这就是"无为"的极致：

  • 不写代码，就是最高的代码质量——没有新写的数据结构，就没有新的 off-by-one 错误；
  • 组合现成工具，胜过手工打造精品——文学编程追求的"像文学一样优雅的程序"，败给了"根本不用写程序"；
  • 顺便还赢了可读性：Knuth 的程序要读十页，McIlroy 的读十秒。

每次我看到团队为一个"一次性数据统计需求"立项、排期、写微服务，我都会想起这六行 shell。

5. 机制与策略分离：X Window 的世纪教训

分离原则（Separation）说：把策略（policy）和机制（mechanism）分开；把接口和引擎分开。

  • 机制：能做什么——提供能力，比如"能在屏幕上画窗口、能接收鼠标点击"；
  • 策略：该怎么做——决定行为，比如"窗口标题栏长什么样、点击关闭按钮是杀进程还是最小化"。

5.1 X Window：把"不表态"写进架构

Unix 世界对这个原则最彻底的实践是 X Window System（X11），1984 年起源于 MIT。X 的设计者把"机制，而非策略"（mechanism, not policy）直接写成了项目格言。

具体怎么分的：

flowchart TB
    subgraph 策略层["策略层(可由用户替换)"]
        WM["窗口管理器<br/>决定标题栏样式/焦点行为"]
        TK["控件工具包<br/>决定按钮长什么样"]
    end
    subgraph 机制层["机制层(X服务器)"]
        XS["X Server<br/>只管画像素/收输入事件<br/>不关心'窗口'概念"]
    end
    APP["应用程序"] --> TK
    WM --> XS
    TK --> XS
    XS -. "协议(X protocol)" .- APP

X 服务器故意不知道窗口应该长什么样、标题栏该有几个按钮。它只提供画矩形、画字、传鼠标键盘事件的机制。所有"外观和行为"都推给了可替换的窗口管理器和工具包。

结果是惊人的长寿和多样性：同一套 X 协议跑了近四十年，上面先后长出过 Motif、GTK、Qt 等无数风格迥异的桌面环境，X 服务器本身几乎不用变。机制稳定，策略自由演化——这就是"无为而治"的架构版：底层定最少的规矩，上层爱怎么长就怎么长。

5.2 反面教材：策略焊死在机制里

对比之下，很多 GUI 系统把"按钮必须长这样、窗口必须这样关闭"直接焊死在系统底层。短期看开箱即用，长期看：

  • 想换一种交互风格？改不动底层，只能外挂 hack；
  • 底层想升级？牵一发而动全身，一动就破坏所有应用。

工程连接：这个教训在今天依然天天上演——

  • Kubernetes 的控制循环是机制，你的 CRD/Operator 是策略；
  • HTTP 是机制，REST 风格是策略；
  • 编译器前端后端分离（LLVM 的 IR 是机制，各语言前端是策略）；
  • 你自己写的框架如果把"业务规则"和"执行引擎"揉在一个类里，就是在给三年后的自己埋雷。

一句话理解：机制回答"能不能"，策略回答"该不该"。把"该不该"的决定权留给离用户最近的那层。

6. cat -v 之争：小即是美的保卫战

6.1 一只猫引发的血案

cat 是 Unix 里最单纯的程序：把文件内容原样输出。它的名字来自 concatenate（拼接），cat a b c > all 把三个文件拼成一个。就这么点功能，干净漂亮。

后来 BSD（伯克利版 Unix）的开发者给 cat 加了选项，比如 -v 可以把不可见字符显示出来。听起来人畜无害，对吧？

1983 年，Rob Pike 和 Brian Kernighan 在 USENIX 大会上发了一篇演讲，标题就很凶：《Program Design in the UNIX Environment》，其中一节叫 “cat -v considered harmful”（化用 Dijkstra 的名篇）。核心论点：

  1. cat 的职责是拼接字节流，“可视化不可见字符"是另一件事，属于另一个程序；
  2. 一旦 cat 开始长选项，它就会无限长下去——今天是 -v，明天是显示行号、压缩空行……Unix 后来的 cat 果然长出了 -n、-s、-E、-T 一长串；
  3. 正确做法是写一个专门的小程序做可视化（Pike 他们后来写了 vis），让 cat 保持单纯。

6.2 这不是洁癖，是防熵增

回头看，Pike 他们争的从来不是 cat 这一个程序，而是一个普适规律：

软件的自然演化方向是功能蔓延（feature creep），而每一次"顺手加个选项"都在加速它。今天不加护栏，三年后它就会变成没人敢动的屎山。

工程连接：你身边一定有那个"本来是 200 行的小工具，三年后变成 8000 行、40 个命令行参数、没人知道所有参数组合行为"的内部程序。它就是一场输掉了的 cat -v 战争。McIlroy 那句话在这里闭环了：“要做新功能，就写个新程序，而不是给旧程序加特性。”

6.3 小即是美（Small is Beautiful）

cat -v 之争背后的正面主张，后来被 Mike Gancarz 总结成一本书的名字：《Linux and the Unix Philosophy》里的核心口号——Small is Beautiful（小即是美）：

  • 小程序容易写、容易测、容易懂、容易替换；
  • 大程序每一处都是沉没成本，坏了一个角就全盘皆输；
  • 一个 200 行的小工具，用不顺手可以扔掉重写；一个 8000 行的怪兽，你只能供着它。

7. Worse is Better：Unix 为什么能赢

7.1 Gabriel 的著名论断

1989 年前后，Lisp 黑客 Richard Gabriel 写了一篇著名文章（后收录于《Lisp: Good News, Bad News, How to Win Big》，1991），提出了一个让理想主义者抓狂的概念：Worse is Better（更糟的就是更好的）。

他对比了两种设计哲学：

MIT/Stanford 路线（“正确的事”，The Right Thing）：

  • 设计必须完整、正确、一致、优雅；
  • 接口的简洁性没有实现的正确性重要；
  • 代表：Lisp 机器、Scheme 的理想主义一脉。

新泽西路线（Worse is Better，新泽西 = 贝尔实验室所在地）：

  • 实现的简单性优先于一切，接口简单、正确性、一致性都要为它让路；
  • 功能做 50% 能跑，好过做 90% 但没人写完；
  • 代表：C 和 Unix。

Gabriel 的观察是：那个"更糟"的新泽西方案会赢，因为它像病毒一样可移植——简单的东西容易实现、容易移植到任何机器上，先占领世界，再靠用户社区慢慢把它补齐。而"正确的事"因为太重、太贵、太难实现，永远停留在少数精英的实验室里。

7.2 历史判卷：Gabriel 说对了

  • C 语言有一堆"糟糕"的设计（缓冲区溢出、未定义行为），但它简单到一个人能写个编译器，于是 C 编译器铺满了地球上每一台机器；
  • Unix 的系统调用接口远不如 Lisp 机器优雅，但 Unix 能跑在从 PDP-11 到超算的一切东西上；
  • 反观 Lisp 机器、各种"设计完美"的操作系统，坟头草已经三米高了。

7.3 但要小心：这不是给烂代码发通行证

Gabriel 本人对这篇文章的态度其实很矛盾（他甚至用化名写过反驳自己的文章）。Worse is better 描述的是演化的规律，不是你写烂代码的借口：

  • 它说的是"实现简单、先跑起来、让世界帮你完善"会赢；
  • 它不是说"不测试、不处理错误、随便糊"会赢。

一句话理解：先交付一个简单到不可能失败的 60 分方案，让它在真实世界里进化；不要在象牙塔里憋一个永远交付不了的 100 分方案。

8. 无用之用：shell 脚本的临时救赎

道家讲"无用之用，方为大用”——看起来没用的东西，往往有大用。Shell 脚本就是编程世界里的"无用之用"：

  • 它"不入流"：没有类型系统、没有 IDE 补全、面试不考、简历上不好意思写；
  • 但它解决的是真实世界里最高频的那类问题：一次性的、临时的、不值得立项的脏活。

举几个我自己（和每个老 Unix 用户）每周都在做的事：

# 找出日志里报错最多的 10 个接口
grep ERROR app.log | awk '{print $5}' | sort | uniq -c | sort -rn | head

# 把 300 个 .jpeg 文件批量重命名成 .jpg
for f in *.jpeg; do mv "$f" "${f%.jpeg}.jpg"; done

# 监控某个进程，挂了自动拉起（穷人版 supervisor）
while true; do ./myserver || sleep 5; done

这些脚本"丑陋"、“脆弱”、“不可维护”——都没错，但它们本来就是一次性用品，写完跑完就扔。为它们搞工程化、写单元测试、上代码评审，恰恰违反了经济原则：程序员的时间比机器贵，也比"代码的体面"贵。

关键判断力在于分清楚两类问题：

  • 临时问题 → shell 糊一个，跑完即弃，这是"无为"的胜利；
  • 反复出现的问题 → 那就不是临时问题了，老老实实写成正经工具，别拿"反正临时用用"当借口让脚本混进生产系统核心路径。

区分错了方向都很惨：给临时问题过度工程化是浪费生命，让临时脚本变成永久依赖是埋雷（无数公司的核心发布流程，起点都是某人"临时写一下"的 500 行 bash）。

9. 与"无为而治"的正式呼应

呼应一下开头，把这条镜像关系钉死：

道家 Unix 哲学
无为 = 不妄为 不写多余的代码（吝啬/经济原则）
治大国若烹小鲜 大系统由小工具组合而成（组合原则）
道法自然 顺应文本流/管道这个"自然接口"，不发明私有协议
上善若水，水善利万物而不争 过滤器程序低调透明，只过数据不刷存在感（缄默原则）
圣人无常心，以百姓心为心 机制不预设策略，把选择权留给用户（X Window）
无用之用 shell 一次性脚本、简单的文本接口反而最长寿

但注意：这本书的主体是工程，不是玄学。 道家给的是一个好用的直觉框架，真正支撑 Unix 哲学的是 50 年的工程证据——管道的胜利、文本流的长寿、cat -v 的沦陷、Lisp 机器的坟墓。直觉负责让你快速做出方向正确的决定，证据负责在你被质疑时撑住你。

10. 带走的清单

写代码或做设计之前，过一遍这十条（按 17 原则提炼后的实战版）：

  1. 能不写就不写：这个问题用现有工具组合能解决吗？（McIlroy 公案）
  2. 一次只做一件事：这个程序/类/函数，能用一句话说清职责吗？
  3. 输出即接口：这个程序的输出，能被另一个还没写出来的程序直接消费吗？（缄默原则）
  4. 用文本说事：这个配置/日志/接口，是人能直接读的文本吗？（透明原则）
  5. 机制和策略分开了吗：我写的这层，是提供能力，还是替用户做决定？（X Window 教训）
  6. 先跑起来再说：现在的版本是不是简单到不可能失败？（Worse is better）
  7. 这是临时问题吗：是 → 脚本糊；不是 → 正经写。别搞反。
  8. 我在加功能还是加复杂度：这个"顺手加的小功能"，是不是下一个 cat -v？
  9. 复杂度在哪一层：不得不复杂时，复杂度被隔离在最小范围了吗？
  10. 删掉一半会怎样：如果砍掉一半功能，核心用户还在吗？在 → 砍。

11. 避坑指南：对 Unix 哲学最常见的四种误用

  • 坑一：把 KISS 当懒惰的挡箭牌。 “简单"指的是设计和实现的简单，不是"不做需求、不处理边界情况”。Knuth 的词频程序虽然输给了六行 shell，但它处理的性能边界是 shell 版处理不了的——该复杂的地方必须复杂。
  • 坑二：把 worse is better 当烂代码许可证。 它描述的是"简单实现先活下来再进化"的演化规律，不是"别写测试、别管错误处理"。60 分方案的前提是边界清晰、失败模式明确，不是糊。
  • 坑三：把"小即是美"理解成微服务越多越好。 微服务拆分如果只分了部署、没分清楚接口，得到的是分布式屎山。组合原则的前提是每个部件接口干净，否则 N 个服务只有 N 倍的运维痛苦，没有组合红利。
  • 坑四：用 shell 糊生产核心。 一次性脚本的正确归宿是跑完即弃（或转正为正经工具）。让 500 行没人看懂的 bash 长在发布流程的心脏上，是把"无用之用"用成了"无用之害"。

12. 结语

《Unix 编程艺术》出版于 2003 年，讲的是 1969 年开始的故事，但它预言对了此后二十年几乎所有的技术走向：文本协议（HTTP/JSON）打败二进制协议，组合式工具（容器、K8s、CI/CD pipeline）打败单体巨兽，“简单实现先跑起来”（Python、Go 的设计取向）打败"正确的事"。

回到那句主线：无为 = 不写多余的代码。 最高明的程序员不是写得最快的人，而是最清楚哪行代码不该存在的人。就像老子说的，为学日益，为道日损——学技术是不断加法，懂设计是不断减法。

这本书值得每五年重读一遍，因为你对"哪行代码不该存在"的判断力，会随踩坑数量逐年升级。

方糖猫
方糖猫（大可）

18 年后端架构，现在独立做 AI 产品。这里记录 AI 视频、AI Agent 与工程实践。

本文阅读量 次