---
title: '为什么程序员要读哲学'
---

# 为什么程序员要读哲学

写代码十年，越来越发现：**写得好不好不取决于语法熟不熟、框架会不会，而取决于「想清楚没有」**。

而「想清楚」这件事，哲学已经研究了两千五百年。

## 一、抽象的代价

写过一段时间业务代码的人都知道，**抽象的代价比看上去高得多**。

> 「我加一个 BaseHandler 类，子类继承，以后就不用重复写了。」

听起来很对，但半年后回头看：
- 业务变了三次，每次都要在 BaseHandler 加新方法
- 子类不再 reuse 父类方法，而是 override + 调一个 protected helper
- 新人接手要先看完 7 层继承链才敢动一行

奥卡姆剃刀（Occam's Razor）告诉我们：**如无必要，勿增实体**。这是 14 世纪的哲学规则，但写代码时每个抽象决策都该过一遍。

## 二、命名即定义

哲学里有一个老问题：**什么是椅子？**

- 三条腿的高凳是不是椅子？
- 没有靠背的板凳是不是椅子？
- 树桩能坐人，是不是椅子？

软件工程的「命名地狱」其实是同一个问题：

```python
class User:
    pass

class Account:
    pass

class Customer:
    pass

class Member:
    pass
```

四个看起来很像，但语义不同。哲学家在意「类型边界」的问题，程序员每天都在踩。

## 三、可证伪性

科学哲学家 Karl Popper 提出：**一个理论如果不能被任何观察证伪，它就不是科学**。

这条标准放到代码里：

| 命题 | 可证伪吗 |
|---|---|
| 「这段代码很优雅」 | ❌ 无法证伪 |
| 「这段代码运行 P99 < 100ms」 | ✅ 跑一遍就知道 |
| 「这个架构便于扩展」 | ❌ 主观判断 |
| 「加 100 个新端点不需要改 router 配置」 | ✅ 可演示 |

写设计文档时，**多写第二类，少写第一类**——你会发现自己的判断快很多。

## 四、第一性原理

Elon Musk 经常提的 first principles 来自亚里士多德。意思是：**不要类比，回到不可再分的基本前提去推**。

业务场景里：

- 「别人 ORM 都这么做」← 类比思维
- 「数据库读 1 行 ≈ 0.1 ms，我这个查询要 50 行 → 5 ms 是合理的」← 第一性原理

类比思维让你跟随，第一性原理让你判断。两者都有用，但**架构决策必须靠第一性原理**——别人的解决方案不一定适配你的约束。

## 五、苏格拉底式追问

苏格拉底教学法的核心是：**不停问「为什么」直到对方自己看出矛盾**。

写 code review 时这是最强的工具：

- 「为什么这里用 mutex 而不是 channel？」
- 「为什么这个字段是 nullable 的？」
- 「为什么这个函数返回 Result 而不是 Option？」

不带攻击性，纯粹想了解。多数时候，PR author 自己回答到第三层就发现：**这地方设计可以改进**。

---

读哲学不是为了能引经据典，而是为了拿到一套「想清楚」的工具箱。

> **42md** — 你的 AI 知识快刀。  
> 把 PDF / 网页 / 录音 / Word / 网页 / 演讲稿，一行命令转成干净 Markdown。

立即体验：[42md.cc](https://42md.cc)