"Talk is cheap. Show me the code."
Core Thinking Models
1. Show Me the Code
Essence: Do not trust slides, promises, or architecture diagrams. The only trustworthy thing is runnable code. No matter how heated the discussion, without code it is just empty talk.
Operating Principles：
代码说话三定律：
定律1：任何提议都必须附带可运行的代码
- "我们应该用X架构" → 附带X架构的原型实现
- "这个功能很简单" → 那你写一个给我看
- "性能会更好" → benchmark数据说话
Law 2: Necessary and Sufficient Conditions for Merging Code
- The code is correct (no logic bugs)
- The code is clear (people can read it)
- The code has tests (proving it is correct)
- Does not break existing functionality (regression tests)
- Consistent with the project style (code taste)
Law 3: Termination Conditions for Discussion
- There is code → discuss based on the code
- No code → go write code, then discuss after it is written
- Never design architecture on a mailing list (design with code)
**日常应用**：
When encountering arguments in team communication: ├─ Someone is saying "We should..." → "Okay, write a POC" ├─ Someone is saying "In theory..." → "In theory? Where is the benchmark?" ├─ Someone is saying "This isn't hard..." → "Then where is the PR?" └─ Someone is saying "In the future we will..." → "Where is the code that runs now?"
### 2. 去中心化协作模式（Bazaar vs Cathedral）
**本质**：伟大的软件不是在象牙塔里设计出来的，而是在开放环境中"发布早、发布频"、让大量人参与打磨出来的。
**集市模式（Bazaar）原则**：
-
Release Early, Release Often
- Do not wait until it is perfect to release
- Users are the best testers
- "Good enough" is enough to ship
-
Given Enough Eyeballs, All Bugs Are Shallow
- Open source → anyone can look, modify, and submit
- Bugs have nowhere to hide before a large number of eyes
- The edge cases users encounter are more numerous than you imagine
-
A good collaboration process is more important than a good plan
- There is no need for a "chief architect"
- There is a need for a good merge process (pull request → review → merge)
- Code quality is guaranteed through review, not through central planning
-
Commit to correcting the right things afterward
- Do not fear making mistakes (making mistakes is normal)
- What is feared is not correcting them after they are made
- Git's philosophy: every commit is traceable
**实用版本**（任何团队都可用）：
Project management:
- Do not spend 3 months planning and then 3 months executing
- Spend 1 week planning, then deliver something usable every week
- Users' real feedback > the "perfect solution" you imagine
Review process:
- All code must be reviewed by at least one person
- Review criteria: correct, clear, consistent
- Do not review architectural opinions, only review code quality
Quality assurance:
- Automated testing > manual testing
- CI/CD is the baseline, not a bonus
- Being able to roll back is more important than being able to fix
### 3. 无情的代码审查（Ruthless Code Review）
**本质**：代码审查不是社交活动。审查的目的是保证代码质量，不是让提交者心情好。但"无情"是对代码，不是对人。
**审查框架**：
Review priorities (from high to low):
P0: Correctness — Is the code doing the right thing? ├─ Is the logic correct? ├─ Are edge cases handled? ├─ Are there race conditions/memory leaks? └─ Do the tests cover the critical paths?
P1: Clarity — Can others understand it? ├─ Do the variable names have meaning? ├─ Does the function do one thing and only one thing? ├─ Is complex logic commented? └─ "Clever code" is almost always bad code
P2: Consistency — Is it consistent with the existing code style? ├─ Consistent indentation and naming conventions? ├─ Consistent error handling approach? └─ Consistent with the project's coding habits?
P3: Elegance — Is there a better way? ├─ Is it over-engineered? (YAGNI principle) ├─ Can it be implemented with less code? └─ Is the data structure chosen correctly? ("Show me your flowcharts...")
**Linus的品味标准**：
Good code taste = doing the right thing in the simplest way
Negative examples:
- 10 lines of code doing what 5 lines could do
- Adding an unnecessary layer of abstraction for the sake of "flexibility"
- Using complex data structures to solve a simple problem
- "Defensive programming" turned into "fearful programming"
Positive examples:
- The core paths of the Linux kernel, with code so concise it looks like pseudocode
- Git's internal object model, astonishingly concise and elegant
- Using the right data structures to make algorithms naturally simple
### 4. 务实工程哲学（Pragmatic Engineering）
**本质**：不追求理论上完美，追求实际上好用。解决今天的问题，不为明天假想的问题做过度设计。
**设计原则**：
-
Solve real problems, not imagined problems
- Don't add abstraction layers "preventively"
- If you don't need it today, don't write it today
- YAGNI: You Ain't Gonna Need It
-
Simple solutions > clever solutions
- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Kernighan
- Simple code is easy to debug; clever code makes you cry
-
Backward compatibility is a promise
- Once users start using your API/interface, don't change it casually
- Linux's system call compatibility has been maintained for 30 years
- If you must change it, provide a migration path
-
Performance is not optimization, it's design
- Consider performance from the start
- It's not "write the slow version first, then optimize"
- Instead, choose the right data structures and algorithms
- But also don't micro-optimize prematurely — profile first, then optimize
**技术债务管理**：
Technical debt classification: ├─ Must pay back: affects current functionality/performance → pay back this iteration ├─ Should pay back: doesn't affect the present but affects the future → pay back next iteration ├─ Can skip paying back: code unlikely to be touched again → leave it for now └─ Don't pay back: modules about to be rewritten → not worth the time
### 5. 正确的数据结构思维（Data Structures First）
**本质**：先想清楚数据怎么组织和流动，算法和代码自然跟着来。
**核心洞察**（Linus引用的Mike Ginnis名言）：
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
Design process:
- What are the core data entities?
- What are the relationships between them?
- What data structures express these relationships?
- What is the complexity of the key operations?
- Only then comes the code
Git's design case study:
- Data entities: blob (file content), tree (directory structure), commit (snapshot)
- Relationships: commit → tree → blobs (content-addressed, hash ID)
- Data structures: DAG (directed acyclic graph), content-addressable storage
- Result: branching, merging, and backtracking are all natural and elegant
## 决策框架
### Linus技术决策树
Facing a technical decision:
Step 1: Is there a real requirement? ├─ Is this solving a real problem or an imagined problem? ├─ Are there users complaining about this problem? └─ If no one is complaining, why do it?
Step 2: What is the simplest solution? ├─ If 10 lines of code can solve it, don't use 100 ├─ If the standard library can do it, don't build your own ├─ If an existing solution can do it, don't invent a new one └─ "Simple" > "Elegant" > "Clever"
Step 3: Disruptiveness assessment ├─ Will this break existing functionality? ├─ Will this change the user interface? ├─ If so, what is the migration path? └─ Can backward compatibility be achieved?
Step 4: Reversibility ├─ If this decision is wrong, can it be rolled back? ├─ How costly is the rollback? └─ Can we first do a small version to test the waters?
## 经典语录
1. *"Talk is cheap. Show me the code."*
— 出处：Linux内核邮件列表, 2000（讨论微内核vs宏内核架构争论）
2. *"烂程序员担心代码。好程序员担心数据结构和它们之间的关系。"*
— 出处：引用自Rob Pike/Mike Ginnis，Linus在Git邮件列表和访谈中多次提及
3. *"Linux的成功不是因为我是天才，而是因为我在正确的时间做了正确的事，并且没有搞砸太多。"*
— 出处：Linux Foundation 峰会演讲
4. *"如果它不能编译或者有已知的bug，那就不要提交。这不是一个高标准，这是底线。"*
— 出处：Linux内核邮件列表中的code review
5. *"我不做梦。我没有要'改变世界'的愿景。我只是觉得有些东西不好用，所以我自己写了一个。"*
— 出处：TED 演讲, 2016
6. *"Git的伟大之处不在于它是什么，而在于它不是什么——它不是SVN。"*
— 出处：Git十周年访谈
7. *"我认为我们拥有的最伟大的技术之一就是'不做什么'的能力。排除法很重要。"*
— 出处：Linux内核开发者访谈
8. *"聪明的人会把复杂的问题变简单，而不是把简单的问题变复杂。"*
— 出处：Linux内核邮件列表中的代码review评论
## 实战模板
### 模板一：代码Review检查卡
```markdown
## PR #__: [标题] | 作者：__ | Reviewer：__
### 正确性 ✅/❌
- [ ] 逻辑正确：核心路径手动验证
- [ ] 边界情况：空值、零值、负数、溢出
- [ ] 错误处理：异常被正确捕获和处理
- [ ] 并发安全：有没有竞态条件？
- [ ] 测试覆盖：关键路径有测试
### 清晰性 ✅/❌
- [ ] 命名有意义（不是foo, bar, tmp2）
- [ ] 函数做且只做一件事
- [ ] 复杂逻辑有注释（解释"为什么"）
- [ ] 没有"聪明"的trick（smart code = bad code）
### 简洁性 ✅/❌
- [ ] 没有多余的抽象层
- [ ] 没有预留给"未来可能需要"的接口
- [ ] 删掉的代码 > 新增的代码？(加分项)
- [ ] 数据结构选得对吗？
### 一致性 ✅/❌
- [ ] 风格和现有代码一致
- [ ] 错误处理方式一致
- [ ] API设计风格一致
### 总评
- Approve / Request Changes / Needs Discussion
- 核心反馈（最多3条）：
1. ...
2. ...
3. ...
Template 2: Pragmatic engineering design document
## 功能：[名称]
### 问题
- 真实用户遇到的痛点是什么？
- 谁在抱怨？抱怨什么？
### 最简方案
- 不考虑"未来扩展"，只解决当前问题
- 用10行代码能解决吗？如果能，为什么不用？
- 标准库/已有工具能直接用吗？
### 数据结构设计（先于算法）
Core entities:
- Entity1: {field1, field2, ...}
- Entity2: {field1, field2, ...}
Relationships:
- Entity1 --N:1--> Entity2
Key operations and complexity:
- Query: O(?)
- Insert: O(?)
- Update: O(?)
### 向后兼容
- [ ] 不破坏现有接口
- [ ] 新字段有默认值
- [ ] 旧数据能正常工作
### 不做的事（排除法）
- ❌ 不做X，因为...
- ❌ 不做Y，因为...
Template 3: "Bazaar model" project management
## 项目：[名称]
### 发布节奏
- 发布频率：每 __ 天/周
- 最小可用标准：[列出核心功能]
- "完美"不是发布的条件，"够用"才是
### 协作流程
Contributor: fork → change code → submit PR → wait for review
Reviewer: check correctness → check clarity → Approve/Request Changes
Maintainer: merge → automated testing → release
### 质量门禁
- [ ] 自动化测试通过（CI）
- [ ] 至少一人review通过
- [ ] 不破坏现有功能
- [ ] 代码风格检查通过
### 回滚策略
- 每个release有tag → 可精确回退
- 线上出问题 → 先回滚，后调查
- 回滚时间目标：< __ 分钟
Application scenarios
| Scenario | How to apply |
|---|---|
| Code review | Use the review checklist, focus on correctness and clarity, and do not accept "clever" code |
| Architecture design | Design the data structures first, then think about algorithms and code. Prefer simple solutions |
| Team collaboration | Release early, release often. Make code review the core of quality assurance |
| Project management | Do not pursue perfect planning; pursue rapid iteration and real user feedback |
| Technology selection | Choose the simplest solution that can solve the problem. Do not pay for "possible future needs" |
| Handling arguments | Let the code speak. Stop arguing and write a POC to compare |
Anti-patterns
- ❌ Do not imitate Linus's temper: His technical judgment is first-rate, but his communication style is not. Code can be ruthless; people deserve basic respect.
- ❌ Do not treat "simple" as "lazy": Linus's simplicity is simplicity after careful thought, not cutting corners to save effort.
- ❌ Do not ignore testing: The premise of "Show me the code" is that the code can run and tests prove that it can run.
- ❌ Do not over-engineer: If you do not need an abstraction layer today, do not write it today. Wait until you truly need it and then abstract.
- ❌ Do not open-source for the sake of open-sourcing: Open source is because the collaboration model is better, not because it is trendy. Internal projects do not necessarily all need to be open-sourced.
- ❌ Do not show off in code: If the code you write requires others to think for 5 minutes to understand it, you wrote it wrong.
Distilled from the Linux kernel mailing list, Git source code and documentation, TED talk (2016), the autobiography "Just for Fun", and various interviews Last updated: 2026-04-14