第 1 章：引言
系列：软件设计的哲学 · 第 1/22 章
全书导读：00-overview.md
一句话总结
软件设计的目标是降低复杂度；能跑只是及格线，长期可理解、可修改才是专业标准。
核心观点浓缩
- 复杂度是理解、修改系统时的认知负担，是软件老化的主因
- Working code isn't enough：功能正确 ≠ 设计合格
- 好设计让系统随规模增长仍可控，差设计让每次改动都像拆炸弹
- 本书提供可操作的设计技术与红旗清单，非教条方法论
- 设计应在实现全程持续进行，而非立项时画一次框图就结束
关键概念 / 金句
| 概念 | 含义 |
|---|---|
| Complexity | 改一处牵动全局、不知影响范围、读不懂——都是复杂度症状 |
| Design | 模块划分、接口形状、信息隐藏——日常编码即设计 |
| Working code isn't enough | 战术式「能跑就交」的反面命题，全书起点 |
本章在全书中的位置
第 1 章定问题域与价值主张：为何读这本书、评判设计好坏的标尺是什么。第 2 章起进入复杂度定义与具体技法；无此章则后文易沦为「设计模式清单」。
个人思考与启发
接手遗留模块时，先问「新人要多久能安全改这里？」而非「有没有 bug」。若答案以周计，问题往往在接口与边界，不在某行算法。引言把标准从「跑通」抬到「可维护」，对评审文化有直接作用。
与《程序员修炼之道》对照
- 《修炼之道》第 1 章讲务实哲学与熵；本书引言聚焦复杂度——一个偏心态，一个偏结构，互补
- 「够好即可」≠「能跑就行」：务实是在约束下负责；本书要求对长期认知成本负责
- 知识组合投资（读源码、学框架）是降低理解复杂度的慢功夫，与本书目标一致
重点与注意
重点：评判设计优劣的唯一主标尺是复杂度升降。
重点：能跑还不够——应成为团队默认共识，而非个人偏好。
注意：本书不是「不写注释」「类越小越好」等流行口号大全。
注意：设计技术要落地到每次 PR，否则只是读后感。
导航：00 全书思考 · 下一篇：第 2 章 复杂度的本质