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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第一部分 基础思维能力
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