程序员的底层思维

一本超越具体编程技法的技术书：职场晋升不仅需要技术能力，更重要的是思维能力。本书带你学会用底层思维解决复杂技术问题，突破职场“天花板”。

一本培养思维能力的通用技能书：打破认知局限，培养通用的思维能力。本书帮你跳出思维定势，轻松解决生活及工作中遇到的问题。

生活中稀松平常的小故事，作者丰富的个人经验和案例，轻松生动的语言风格，专业度十足的思维模型，软件设计“科学+哲学+美学”的完美融合。

本书涵盖程序员应知应会的16种思维能力，共18章，分为三部分。第一部分主要介绍抽象思维、逻辑思维、结构化思维、批判性思维、维度思维、分类思维、分治思维、简单思维，以及成长型思维等解决日常问题的基础思维能力。第二部分结合软件行业的特点，主要介绍解耦思维、契约思维、模型思维、工具化思维、量化思维、数据思维，以及产品思维等专业思维能力。第三部分主要是对上述思维能力的综合运用实践。

张建飞，阿里巴巴前高级技术专家，目前在某大厂担任软件教练。作者于2007年计算机工程硕士毕业后，先后在国内外知名互联网企业担任高级研发和技术专家，有着丰富的一线研发、应用架构和领域建模经验。

作者提倡“工匠精神”，曾获阿里巴巴新零售技术部2019年“极致匠心奖”，并凭借《代码精进之路：从码农到工匠》一书获得2019年人民邮电出版社“IT类影响力作者”称号。

作者开源的COLA应用架构是国内颇具影响力的DDD架构之一，在GitHub上的Star数量超过6100。同时，COLA也是阿里云的官方推荐架构，被广泛应用于国内各大应用系统中。

讲软件设计的书有很多，讲思维模型的书也有很多，但却很少有将这二者结合的书。本书正好填补了这个空白，让读者有机会学习如何把好的思维模型和思考方式迁移到软件设计中，从而设计出更加可靠、可信、可维护的软件产品。

某世界500强企业Fellow专家 胡子昂

好的思维模型是程序员快速成长的利器。本书深入浅出地剖析了思维模型案例，能够让读者掌握思维模型的本质，从而在面向企业的不同业务场景时都能以不变应万变，给出优雅的架构解决方案，使企业真正实现降本增效。这是一本在思维模型领域中难得一见的、具有实践意义的好书！

奈学教育创始人兼CEO， 58集团前技术委员会主席 孙 玄

这是一本讲解软件设计的佳作，介绍了具有哲学色彩的逻辑思维分析与训练内容，并将软件设计的道与术有机地融合起来，由此可见本书的别具一格与作者的别出心裁。阅读完毕，获益良多，兴奋之情无以言表，唯有力荐。

《解构领域驱动设计》作者 张 逸

本书从抽象思维、逻辑思维、结构化思维开始讲起，并上升到了柏拉图、维特根斯坦的哲学体系，这着实令人眼前一亮。技术能力对于程序员在职场中晋升至关重要，但更重要的是这些在提升技术能力的过程中绕不过去的根本思想。

《Maven实战》作者，阿里巴巴高级技术专家 许晓斌

思辨能力好比一个人的“底层操作系统”，本书可以帮助我们检视并提升自身系统的完备性。

招商银行总行首席IT工程师 陈 曦

软件学源于科学，但编写软件却是一门逻辑抽象的艺术。和所有的工程学一样，抛开科学部分，软件学剩下的都是哲学和美学。透过这本书，我们可以领略到软件的工程之美。

阿里巴巴前资深技术专家 张群辉

建飞结合自身工作经验，用大量的实例展示了原本令人难以理解的逻辑和推理的思维过程。本书深入浅出，概念简洁，条理清晰，语言通俗易懂，既为软件从业人员提供了难得的学习机会，也为其他行业人员提供了很好的参考。

西安电子科技大学硕士生导师、副教授 何先灯

这本书不仅有独到的理论见解，也有“接地气”的案例支撑，是一本难得的软件工程艺术的佳作。如果你想在程序开发的职业生涯中持续精进，本书非常值得一读。

亿贝中国研发中心开发总监 鲁 杰

第一部分 基础思维能力
01 抽象思维 2
1．1 抽象 = 抽离 + 具象 3
1．2 抽象是哲学思维的基础 4
1．3 语言的抽象性 5
1．4 软件设计中的抽象 7
1．4．1 面向对象的核心是抽象 7
1．4．2 抽象设计的评判标准 8
1．4．3 抽象缺失之基础类型偏执 9
1．4．4 抽象缺失之重复代码 12
1．4．5 抽象设计要完整 14
1．4．6 不要为了抽象而抽象 15
1．5 抽象的层次性 17
1．5．1 对抽象层次的权衡 17
1．5．2 软件中的分层抽象 20
1．5．3 强制类型转换中的抽象层次问题 22
1．5．4 抽象层次一致性原则 24
1．6 锻炼抽象思维能力 28
1．7 精华回顾 30
参考文献 30
02 逻辑思维 31
2．1 逻辑就是关系 32
2．2 逻辑三要素之概念 33
2．2．1 概念要明确且清晰 34
2．2．2 制定团队通用语言 35
2．2．3 管理者的概念技能 36
2．3 逻辑三要素之判断 37
2．4 逻辑三要素之推理 38
2．4．1 演绎推理：因为，因为，所以 38
2．4．2 归纳推理：从特殊到一般 40
2．4．3 溯因推理：大胆假设，小心求证 41
2．5 逻辑链 42
2．5．1 5Why思考法 43
2．5．2 5So思考法 44
2．6 逻辑谬误 45
2．6．1 偷换概念 46
2．6．2 错误假设 46
2．6．3 循环论证 47
2．6．4 以偏概全 48
2．6．5 滑坡谬误 48
2．7 非理性思考 49
2．8 精华回顾 50
参考文献 50
03 结构化思维 51
3．1 结构与架构 51
3．2 从无序到有序 52
3．3 金字塔结构 54
3．4 金字塔中的逻辑 57
3．4．1 纵向逻辑关系 58
3．4．2 横向逻辑关系 60
3．5 如何搭建结构 64
3．5．1 自上而下 65
3．5．2 自下而上 66
3．5．3 上下结合 70
3．6 更多结构思维框架 71
3．7 精华回顾 73
04 批判性思维 74
4．1 理解批判 75
4．2 批判中台 77
4．2．1 中台的底层逻辑 77
4．2．2 业务中台为何低效 77
4．2．3 解决中台的困境 79
4．3 批判架构师 82
4．3．1 尴尬的架构师 83
4．3．2 尴尬的架构部门 83
4．3．3 人人都是架构师 84
4．4 批判技术管理者 85
4．4．1 技术不作为 86
4．4．2 业务不思考 87
4．4．3 脾气超火爆 87
4．5 自我批判 87
4．6 精华回顾 89
参考文献 89
05 维度思维 90
5．1 维度究竟是什么 90
5．2 多维度思考 91
5．3 不做if else程序员 93
5．3．1 多态扩展 94
5．3．2 代码分离 95
5．3．3 矩阵分析 96
5．3．4 殊途同归 98
5．4 无处不在的矩阵分析 99
5．4．1 波士顿矩阵 99
5．4．2 订单要素分析 100
5．4．3 RFM模型 101
5．4．4 逻辑推理中的矩阵 103
5．4．5 相关系数矩阵 104
5．5 设计模式中的维度思维 105
5．6 组织管理中的维度思维 109
5．6．1 人员分工矩阵 109
5．6．2 人才盘点矩阵 110
5．6．3 需求管理矩阵 110
5．7 精华回顾 111
06 分类思维 112
6．1 分类是本能 112
6．2 分类无处不在 113
6．3 分类的本质 114
6．3．1 寻找共同属性 114
6．3．2 经典分类与概念聚集分类 115
6．3．3 多种多样的分类角度 116
6．4 没有“完美”分类 117
6．5 软件设计中的分类 118
6．5．1 对象分类 118
6．5．2 构建分类 119
6．5．3 领域分类 121
6．6 组织架构中的分类 122
6．6．1 业务型组织 123
6．6．2 职能型组织 124
6．7 互联网产业分类 125
6．8 精华回顾 127
参考文献 128
07 分治思维 129
7．1 分治设计模式 129
7．1．1 管道模式 130
7．1．2 责任链模式 133
7．2 分布式系统 138
7．2．1 x轴拆分 139
7．2．2 y轴拆分 140
7．2．3 z轴拆分 140
7．2．4 xyz轴拆分对比 142
7．3 分治算法 142
7．4 解决问题的黄金三步 143
7．5 “分治并”的应用 144
7．5．1 流式计算 145
7．5．2 分布式数据库 146
7．6 精华回顾 149
参考文献 149
08 简单思维 150
8．1 简化是逆向做功 151
8．1．1 压缩、隐藏与赋予 151
8．1．2 减少选择 152
8．1．3 奥卡姆剃刀 155
8．2 干掉流程引擎 156
8．3 极简状态机的实现 157
8．3．1 领域专用语言的分类 158
8．3．2 极简状态机的模型设计 159
8．3．3 连贯接口设计 161
8．3．4 无状态设计 164
8．3．5 极简状态机的使用 165
8．4 COLA的壮士断腕 166
8．5 复杂的产品没人用 167
8．6 精华回顾 169
09 成长型思维 170
9．1 走过至暗时刻 170
9．2 成长型思维与固定型思维 171
9．3 大脑的可塑性 173
9．4 培养成长型思维 174
9．4．1 明确努力的意义 175
9．4．2 改变归因习惯 175
9．4．3 摆脱精神内耗 176
9．4．4 持续精进 178
9．4．5 保持好奇心 179
9．4．6 守住平常心 180
9．4．7 慢也是快 181
9．4．8 掌握表扬的技巧 182
9．5 成功人士的成长型思维 184
9．6 精华回顾 185

第二部分 专业思维能力
10 解耦思维 188
10．1 耦合与解耦 189
10．2 依赖倒置解耦 189
10．2．1 抽象比具体灵活 190
10．2．2 面向接口编程 191
10．2．3 应用与日志框架的解耦 192
10．3 中间层映射解耦 195
10．3．1 DNS的解耦设计 196
10．3．2 CDN的解耦设计 197
10．4 解耦的技术演化 199
10．5 应用架构中的解耦 201
10．6 精华回顾 204
11 契约思维 205
11．1 软件设计中的规范 206
11．1．1 命名规范 206
11．1．2 异常处理规范 207
11．1．3 架构规范 210
11．1．4 规范的维护 211
11．2 软件设计中的标准 212
11．2．1 前端标准化之路 212
11．2．2 Java规范 213
11．2．3 API设计标准 216
11．3 依赖契约的扩展机制 218
11．3．1 基于接口的扩展 218
11．3．2 基于配置数据的扩展 220
11．4 掌握标准制定权 222
11．5 精华回顾 225
参考文献 225
12 模型思维 226
12．1 模型及其分类 226
12．1．1 物理模型 227
12．1．2 数学模型 227
12．1．3 概念模型 228
12．1．4 思维模型 228
12．1．5 模型不能代替实物 229
12．2 UML建模工具 229
12．2．1 类的UML表示法 231
12．2．2 类的关联关系 232
12．2．3 类的依赖关系 236
12．2．4 类的泛化关系 237
12．2．5 类与接口的实现关系 238
12．3 领域模型 239
12．3．1 限界上下文 240
12．3．2 上下文映射 241
12．4 领域模型与数据模型 243
12．4．1 错把领域模型当数据模型 244
12．4．2 错把数据模型当领域模型 246
12．4．3 两种模型各司其职 248
12．5 精华回顾 249
13 工具化思维 251
13．1 你我都是“工具人” 252
13．2 工具化的一般步骤 252
13．3 TestsContainer小工具 253
13．4 组合创新也是创新 258
13．5 ORM工具 261
13．6 基础设施即代码 267
13．7 巧用便签贴 269
13．8 精华回顾 270
参考文献 270
14 量化思维 271
14．1 量化的步骤 271
14．1．1 定义指标 272
14．1．2 将指标数字化 273
14．1．3 优化指标 274
14．2 研发效能度量 275
14．2．1 度量不是“指标游戏” 275
14．2．2 力求合理的度量 276
14．3 目标管理 278
14．3．1 SMART原则 278
14．3．2 OKR考核指标 279
14．3．3 不要迷信指标 280
14．4 量化网站运营 281
14．5 量化技术贡献 282
14．6 精华回顾 284
15 数据思维 285
15．1 “精通”数据 285
15．2 数据体系概览 286
15．2．1 数据源 286
15．2．2 数据仓库 287
15．2．3 ETL 289
15．2．4 元数据 291
15．2．5 数据应用 292
15．3 数仓建模 292
15．3．1 维度模型 293
15．3．2 事实明细表 295
15．3．3 事实汇总表 297
15．4 数据产品平台 299
15．4．1 看我情 300
15．4．2 看行情 301
15．4．3 看敌情 301
15．5 用数据说话 302
15．6 精华回顾 303
16 产品思维 304
16．1 产品的三要素 305
16．1．1 用户 305
16．1．2 需求 305
16．1．3 场景 306
16．2 产品的分类 306
16．2．1 用户关系角度 307
16．2．2 用户需求角度 307
16．2．3 用户类型角度 307
16．2．4 产品形态角度 308
16．3 产品架构 308
16．4 产品化 310
16．5 平台化 312
16．5．1 企业平台化 312
16．5．2 平台化建设 314
16．5．3 平台产品化 316
16．6 精华回顾 318

第三部分 思维能力的综合应用
17 我的商品团队之旅 322
17．1 落地新团队 323
17．1．1 熟悉人 324
17．1．2 熟悉业务 325
17．1．3 熟悉技术 328
17．1．4 熟悉文化 328
17．2 深入商品领域 329
17．2．1 领域概念 330
17．2．2 概念模型 336
17．2．3 产品架构 338
17．3 商品上架重构 340
17．3．1 复杂的商品上架流程 340
17．3．2 无用的流程引擎 341
17．3．3 问题的本质在于结构 342
17．3．4 结构化分解后的问题 345
17．4 复杂业务应对之道 348
17．4．1 上下结合 348
17．4．2 能力下沉 349
17．5 精华回顾 352
参考文献 352
18 COLA的演进过程 353
18．1 COLA 1．0 354
18．1．1 复杂度来自哪里 354
18．1．2 COLA 1．0的设计 356
18．1．3 COLA 1．0的整体架构 365
18．2 COLA 2．0 366
18．2．1 新架构分层 366
18．2．2 新组件划分 367
18．2．3 新扩展点设计 369
18．2．4 新二方库定位 371
18．3 COLA 3．0 375
18．3．1 去掉Command 375
18．3．2 去掉Interceptor 377
18．3．3 去掉Validator等 377
18．3．4 优化类扫描 378
18．3．5 用Adatper代替Controller 378
18．4 COLA 4．0 379
18．4．1 架构的顶层设计 379
18．4．2 技术维度与领域维度的划分 381
18．4．3 COLA组件 383
18．4．4 COLA 4．0的改动点 383
18．5 如何使用COLA 386
18．6 精华回顾 388
后记 389

在阿里巴巴的晋升会议上，评委经常会问：“你的成功可以复制吗？”我最初做评委时基本不会问这样的问题，因为我认为这样的问题很虚，工作完成就行了，不需要那么多道理。

然而随着时间的推移，我发现这的确是一个好问题。因为它可以区分出你是碰巧把事情做对了，还是你具备了一直做对事情的能力，二者是有本质区别的。碰巧做对，说明你的能力可能还不足，换一种情景，你就不一定能应付。因此，好的晋升制度不仅要考查成绩，更重要的是考查能力。对从事脑力劳动的技术人员来说，“能力”主要指的是“思维能力”。

正所谓“有道无术，术尚可求也，有术无道，止于术”。如果说我的第一本书《代码精进之路：从码农到工匠》主要是关于编程技艺——“术”层面的，那么本书则主要是关于技艺背后的底层思维——“道”层面的。

说到“道”，大家可能会想到“道可道，非常道”，觉得它“玄之又玄”。然而我这里所说的“道”更侧重于“道理”，即我们做事背后的道理、思维方式是什么。思维能力是比解决具体问题更重要的能力。问题也许各有不同，但思维方式可以复制和迁移。我们一旦掌握了正确的思维方式，便可以举一反三、触类旁通。

例如，我们都知道编程的时候命名很重要，也很难，可为什么会这样呢？如果要深挖其背后的原因，将是一个非常有趣的话题，甚至可以和哲学有关。命名工作中暗含了抽象思维能力和语言哲学，语言本身是抽象的符号，比如当你说“花”的时候，指的并不是某一朵具体的玫瑰花、郁金香，而是花的抽象概念。一朵具体的花虽然看得见、摸得着，但总会有凋零消亡的时候，而“花”这个字作为精神实体将永不会消亡。所以，抽象的花和具体的花到底哪个才是本真呢？这是一个哲学问题。

抛开哲学争论，就“花”这个字而言，它是提取了所有花的共性的抽象符号。命名之所以难，是因为你要经历一个提取共性、归纳要义，并赋予恰当名称的抽象思维过程。因此，要想真正做好命名，除了要掌握一些命名技法，还需要更深层次的修炼——提升抽象思维能力。

又如，有些人说话重点突出、易于理解，而有些人则前言不搭后语，让人不知所云；有些人写文章、写邮件思路清晰、有条理，而有些人的文章则词不达意、东拼西凑；有些人写的代码结构清晰、可读性强，而有些人写的代码则是一团乱麻、难以维护……问题的本质在于逻辑思维和结构化思维的差异，可逻辑思维和结构化思维又是什么呢？这些思维能力是可以习得和提高的吗？

维特根斯坦在《逻辑哲学论》中说，思维本身就能解决问题，我们所要做的，就是观察它是如何做到的。

认知水平有4个层次，从低到高依次是“不知道自己不知道、知道自己不知道、知道自己知道、不知道自己知道”。“不知道”并不糟糕，最糟糕的是“不知道自己不知道”，而因为缺少对自身思维的观察和培养，所以很多人对思维的认知尚处于“不知道自己不知道”的层次。

这种无意识会导致我们很多时候盲目地做事。虽然一些人“996”工作很辛苦，但也许大部分工作内容是无意义的重复，在工作过程中，思维能力并没有得到锻炼和提高。这样的人即使侥幸晋升成功，他的能力水平仍然停留在低层次。

就像混沌大学创始人李善友教授说的，没有好的思维模型，再多的知识积累也是低水平的重复。成人学习的目的不是获取更多的信息量，而是学习更好的思维模型。

综上，本书的首要目的就是打破“不知道自己不知道”的思维禁锢，把软件设计中会用到的各种思维能力显性化地呈现出来，让你意识到原来有这么多思维模型在软件设计中发挥着至关重要的作用。

一个人如果永远躺在自己的认知盲区，那么既得不到锻炼，更无法提高。只有意识到这些思维能力的存在，我们才有可能去学习、练习和提升。

我也是从这样的认知盲区中走过来的，自从意识到思维能力的重要性之后，便开始主动地学习各种思维方法，并努力将这些思维方法运用到软件设计中。在探索和学习的过程中，我发现讲思维能力的书有很多，讲软件设计的书也有很多，然而却没有一本将思维能力和软件设计相结合的书。君子求诸己，既然没有现成的书，那就只能靠自己一点一点去摸索。摸索的过程虽然要付出大量的时间和精力，但也充满乐趣，这是学习、成长和认知突破的乐趣。功夫不负有心人，你现在看到的这本书便是我“上下求索”的结果。

实际上，在本书出版之前，我已经在多个场合做过不少于十次的有关“程序员的底层思维”的分享和演讲，令我欣慰的是，每次分享都能得到很好的反馈。为此，我还专门在阿里巴巴内部开设了思维训练的培训课，课后有同学留言：“这样的课程应该被纳入新人入职的必修课”。

我想，这门课程之所以能够引发大家的共鸣、使大家获得启发，是因为其中涉及的曾经困扰我的问题亦困扰着很多人。既然我有幸能从这些困惑中走出来，那么我希望这些经验同样可以帮助你。

非常感谢你能坚持看到最后一页。希望你在看完本书后，能够把这些底层思维能力内化成自己的“不知道自己知道”。这些底层思维中蕴藏着解决问题的强大力量，当它们与软件设计相遇时，会擦出耀眼的“火花”。希望你能感受到软件设计中所蕴含的思维美学。

在你看到这本书的同时，我已经离开了阿里巴巴这个令我熟悉的环境。在接近不惑之年，我选择走出舒适圈，继续“折腾”，去一个国内知名大厂做软件教练。

很多人不理解我为何这样做，因为在国内一直有一个论断：技术人的35岁是一道坎儿，如果继续做技术，自身竞争力将开始下降，无法跟上更年轻的程序员的步伐，体力上也不能适应“996”的工作节奏。

我非常不认同“35岁现象”，根据成长型思维的观点，人类没有那么脆弱，人类的智力也不会在35岁后就停止发展，更不用说35岁之后就没有竞争力了。Martin Fowler、Eric Evans、Neal Ford这些人在60多岁时还在写代码，为什么我们中国的程序员在35岁时就应该退役了呢？

年龄不是最重要的要素，关键要看你想成为什么样的人。很多程序员抱怨“面试造火箭，入职拧螺丝”，工作没有成就感，没有成长性。实际上，程序员大部分的日常工作的确是在“拧螺丝”，我的职业生涯也是从这样的基础岗位开始的。我还记得我的第一份工作是在交通银行，因为看不惯当时乱糟糟的系统，于是我对照着一本设计模式方面的书开始做重构，重构的工作完全在我的本职工作之外，加上我当时的技术水平也是“半吊子”，结果改出了一堆bug，我不得不在客户现场随时待命，准备修复问题。然而最后，经过我重构后的系统得到了单位领导和客户的一致认可。

从那时起，我心中就已经埋下了“追求代码的极致和美”这颗种子。因此，周围的环境只是客观存在的一个因素，更重要的在于我们自己的主观想法——有没有一颗追求极致的匠心、永不放弃的恒心、坚定不妥协的决心，以及永不满足的好奇心。如果你只是妥协于外界环境的压力，只会抱怨工作的琐碎，只甘心做一个实现业务逻辑的if else程序员，那么你也许只会按照自己选择的路线沉沦下去。

软件开发行业的匠心和传统行业的匠心不一样，不是重复做简单的事情，你就能把它做好。这就好比你即使做了10年的收银员，也只是一个收银员，无法成为财务总监。在软件开发行业，你需要不断地学习、不断地思考、不断地积累、不断地尝试、不断地失败、不断地创新，才有可能做得好。

优秀的工程师，心中都有一团火—— 一种对美的追求和渴望。这需要我们经历无数个不眠之夜，承受很大的压力，受很多委屈，看很多的书，尝试很多别人没有实践过的东西，要具有一颗“不妥协、不将就、不放弃”的倔强的心。这样我们才能做出一些不同凡响的东西，才能活成自己所期望的样子。

人生不是百米短跑，而是一场马拉松，拼的是心力、体力和脑力。种一棵树的最好时间是十年前，其次是现在。从今天起，保持好奇心，持续学习，不断丰富自己、提升自己，构建自己的知识体系和核心竞争力。就像我也是在而立之年以后才开始“技术开悟”的，请相信我，一切都为时不晚。

35岁不应该是技术生涯的终点，也可以是起点。我希望我们这一代技术人能像国内外的软件大师们看齐，在技术这条路上坚持得更久一点，走得更远一点。希望有一天，中国可以涌现出更多的软件大师，产出更多原创的软件理论和方法论，为世界技术发展贡献更多的中国力量！