具体描述
架构师是一个技术制高点的岗位，在智能时代（如大数据、云计算和移动互联网潮流）里，它位居于领导位置，与企业高阶经理们是互补的，或者能汇集于一身的。
《思考软件，创新设计——A段架构师的思考技术》介绍当今全球正蔚为风潮的设计思考（Design Thinking）技术，陪伴你从目前的编程或设计岗位进入架构设计（A段和B段），踏上灿烂的软件（程序）生涯的新旅程。其内容涵盖了A段架构师的主要策略思维，以及许多实践案例，包括软硬整合商业模式范例、产品策略案例演练、架构设计的学习步骤、云平台架构设计法则等；并阐述从策略、设计到代码的落地步骤。
相信《思考软件，创新设计——A段架构师的思考技术》会是你的一匹千里马，陪伴你驰聘于广大的IT原野上，并发挥创新潜能，挑战人生颠峰。
作者简介
高焕堂：在校时期主修统计学和信息管理，将近40年软件开发生涯。工作于亚洲和欧美各地区，专精于商业策略思考和系统架构设计。近年来，热衷于<IT+设计>教育顾问和产品开发。
Annping Kao：出生于美国科罗拉多（Colorado）州，从小喜爱艺术美学。在学时，学习平面设计和3D动画技术，熟悉Java编程。热爱思考设计，让凡事增加价值。
目录信息
1.1 A段架构师的角色 1
1.2 面对复杂，唯有简单 2
1.3 商业环境与模式是复杂的 3
1.4 软件的复杂是本质性的（并非表象而已） 5
1.5 如何从复杂中设计出简单 7
1.5.1 单纯与美丽的密切联系 7
1.5.2 软件美何在，把酒问<对称> 7
1.5.3 软件架构的第1种对称性 8
1.5.4 软件架构的第2种对称性 8
1.6 参考文献 9
第2章软硬整合商业模式范例 10
2.1 复习：A段架构设计 10
2.2 产品设计支持商业模式 11
2.2.1 反思既有的商业模式 12
2.2.2 创立新型商业模式 12
2.3 商业模式范例 13
2.3.1 长期的获利策略 13
2.3.2 短期的获利策略 14
2.3.3 硬硬结合销售 14
2.3.4 软硬整合开发 16
2.4 产品设计范例 17
2.5 延伸到客厅配件市场 18
2.5.1 客厅配件范例 18
2.5.2 客厅配件的商业模式 19
2.5.3 与微信、微博或百度地图等平台对接 20
2.6 产品的架构设计范例 21
2.6.1 基本元素和功能 21
2.6.2 应用情境（举例） 22
2.6.3 架构设计与实践 23
2.7 参考文献 23
第3章获利思维与心境 24
3.1 获利思维VS.成本思维 24
3.2 让架构师身价百倍的招式 26
3.3 领悟信用卡VISA商业模式 27
3.4 以农夫挑水浇花为例 28
3.5 设计客厅配件产品的商业（合作）模式 31
3.5.1 复习：客厅配件的商业模式 31
3.5.2 一样的心境 32
3.5.3 创立OFA联盟 33
3.6 参考文献 34
第4章创新思维 35
4.1 溯因推理与创造性 35
4.2 溯因推理基本观念 36
4.3 <假定-否证>= 删除法 39
4.4 孔明的溯因推理范例 41
4.5 麦肯锡的MECE原则 45
4.5.1 认识MECE原则 45
4.5.2 议题树及其种类 46
4.5.3 持续对议题进行分解和检验 47
4.5.4 符合MECE原则 47
4.5.5 持续进行<检验-否证> 48
4.5.6 展开下一阶层的议题 49
4.5.7 MECE范例 51
4.6 软件敏捷（Agile）开发原则 54
4.6.1 认识敏捷开发原则 54
4.6.2 敏捷幕后的溯因推理 55
4.6.3 A段架构师的敏捷力 57
4.7 敏捷设计：应用于智慧城市顶层设计 58
4.7.1 <顶层设计>含义的迷思 58
4.7.2 创新的起点：愿景（Vision） 59
4.7.3 观察现实，提出假定（Hypothesis） 60
4.7.4 结论：提出<敏捷顶层设计方法> 61
4.7.5 应用：敏捷顶层设计步骤说明 62
4.8 创新设计：<发现EIT造形>之旅 62
4.8.1 什么是代码造形？ 62
4.8.2 大家熟悉的两种代码造形：函数和类 63
4.8.3 创新的起点：愿景（Vision） 64
4.8.4 提出假定 65
4.8.5 提出新的假定 65
4.8.6 结论：提出EIT代码造形 66
4.8.7 为什么需要有两个配角 68
4.9 参考文献 69
第5章组合思维 70
5.1 从古典抽象思维谈起 70
5.2 创新组合思维 72
5.2.1 <合>的设计法则 72
5.2.2 序中有乱：以集装箱为例 73
5.2.3 演练：如何抽象出<集装箱> 74
5.2.4 观摩：软件集装箱 75
5.3 组合设计的要素：造形（Form） 77
5.3.1 从集装箱认识“造形” 77
5.3.2 认识EIT软件造形 78
5.3.3 造形的特性 81
5.3.4 造形的内部元素 81
5.3.5 造形的外部组合规律 82
5.4 演练范例：寻找（设计）软件系统的造形 85
5.5 演练范例：从简单造形组合出复杂 90
5.5.1 范例（一）：一对EIT造形包容善变的通信协议 90
5.5.2 范例（二）：EIT造形的巢状组合 93
5.5.3 范例（三）：从EIT造形组合出GoF设计模式 95
5.6 反思：儒家文化中的创新组合思维 99
5.6.1 分解的尽理之精神 99
5.6.2 中学为体，西学为用 99
5.7 设计出未来性 103
5.7.1 今日决策的未来性 103
5.7.2 愿景与连线 104
5.7.3 愿景从哪里来 105
5.7.4 组合与创新 105
5.7.5 演练：未来性架构设计 107
5.8 参考文献 113
第6章战术引导战略思维 114
6.1 架构师擅长于战术引导战略 114
6.2 会赢的战术 116
6.3 找会赢的战术，调整战略资源 117
6.4 <战术引导战略>的企业案例 118
6.5 参考文献 121
第7章四项假设性思维 122
7.1 从溯因推理谈起 122
7.2 假设（Assumption）是什么 125
7.3 第一项：不自觉的假设，放宽思维局限 125
7.3.1 一般范例 125
7.3.2 孔明空城计的范例 126
7.3.3 其他范例 127
7.4 第二项：有待被检验的假定，激发愿景想象 129
7.5 第三项：完成性的假设，想象最终结果 131
7.5.1 什么是完成性假设 131
7.5.2 Mapping from vision to reality与溯因推理 133
7.5.3 “Mapping”如何促进Know Unknown 135
7.5.4 演练：Mapping from vision to reality 137
7.5.5 演练：全脑观想（Visualization） 139
7.5.6 演练：完成性假设 140
7.6 第四项：万一性的假设，预留弹性空间 148
7.6.1 Why？万一性的假设 148
7.6.2 如何预见失败 149
7.6.3 认识Possibility和备胎思维 151
7.7 参考文献 152
第8章架构师策略思维的案例演练 153
8.1 产品策略思维 153
8.1.1 产品策略目标：兼顾独特性、普遍性和可靠性 153
8.1.2 实践方案：软硬整合、跨平台与测试 154
8.1.3 从简单中掌握复杂 155
8.1.4 对假定进行检验 157
8.2 发挥四项假设性思维 158
8.2.1 复习：溯因（Abductive）推理 158
8.2.2 观察现实，观想愿景 159
8.2.3 推导出假定 160
8.2.4 进行Mapping from vision to reality 161
8.2.5 重大发现 163
8.2.6 决定跨平台策略的方向 165
8.3 订定跨平台实践策略 165
8.3.1 复习：探索策略方向 165
8.3.2 拟订实践策略 165
8.3.3 策略-1：把它“EIT（设计）”了 166
8.3.4 策略-2：挟天子以令诸侯 167
8.3.5 策略-3：建立中间件（middleware） 167
8.4 跨芯片小平台策略 167
8.4.1 什么是<跨平台> 167
8.4.2 终端产品跨（芯片）小平台的3种情境 169
8.5 跨Android大平台策略 174
8.5.1 这个<策略-2>从哪里来 174
8.5.2 策略-2的实践 176
8.6 跨自己平台的策略 180
8.6.1 这个<策略-3>从哪里来 180
8.6.2 中间件跨平台的效益：没钱就改版，改版就有钱 182
8.6.3 中间件跨客户端的效益 183
8.6.4 中间件的设计 183
8.6.5 中间件在整体架构中的角色 185
8.7 参考文献 186
第9章架构设计的十个学习步骤 187
9.1 这<十个步骤>从哪里来 187
9.1.1 从架构思维的4个元素出发 187
9.1.2 学好<创意爱上限制> 188
9.1.3 学好<创新组合> 190
9.1.4 学习敏捷测试和设计通用性接口 191
9.2 阐述<十个学习步骤> 192
9.2.1 第1步：学习两种抽象视角（Abstraction View） 192
9.2.2 第2步：关心下层的变动自由度 193
9.2.3 第3步：<系统架构控制力>支撑<商业竞争话语权> 193
9.2.4 第4步：<用户体验>是用户从简单中叫出复杂的满足感 194
9.2.5 第5步：创意爱上限制，即需求检验设计 194
9.2.6 第6步：假设性思维和Mapping from vision to reality 195
9.2.7 第7步：清晰而明确表述接口（Interface） 195
9.2.8 第8步：尽快对接口进行检验和测试 195
9.2.9 第9步：设计通用性接口 196
9.2.10 第10步：有效减法设计，才能开放加法（设计） 197
9.3 深入领悟（一）：变动自由度 197
9.4 深入领悟（二）：创意爱上限制 200
9.5 深入领悟（三）：Mapping from vision to reality 201
9.6 深入领悟（四）：迅速检测接口 204
9.7 深入领悟（五）：有效减法设计，才能开放加法 208
9.7.1 举例：以Socket接口来包容TCP/IP通信协议 208
9.7.2 演练步骤 208
9.8 参考文献 218
第10章<Java/HBase + C>云平台架构设计的十项法则 219
10.1 这<十项法则>从哪里来 219
10.1.1 反思假设 219
10.1.2 关注于命令流及其控制点 221
10.2 阐述<十项法则> 222
10.3 思考议题&提示 227
10.4 参考文献 232
第11章法则-2的实践范例：通用性接口设计 233
11.1 通用性接口 233
11.2 亲自设计通用性接口 235
11.2.1 认识用例（Use Case）及其剧景（Scenario） 235
11.2.2 设计通用性接口来支撑用例（Use Case） 238
11.2.3 衔接到<UC-001：播放音乐>的特殊性接口 239
11.2.4 衔接到<UC-002：播放某首音乐>的特殊性接口 243
11.3 多个通用性接口的联合应用范例 247
11.3.1 应用范例：手机与Android TV的多机整合 247
11.3.2 iPhone手机端的规划 248
11.3.3 衔接iPhone手机端的（通用性）接口：Servlet 249
11.3.4 App的Context接口与myTVServlet对接 253
11.3.5 Android本地App的设计 259
11.4 参考文献 264
第12章法则-3的实践范例：挟天子以令诸侯 265
12.1 一般框架设计：以<五子棋>为例 265
12.1.1 阶段一：从传统类（Class）造形设计出发 265
12.1.2 阶段二：继续运用EIT造形设计 268
12.2 基于Android设计小框架：以<涂鸦>应用为例 272
12.2.1 介绍多层EIT造形 272
12.2.2 简介「涂鸦」（Scribble） 274
12.2.3 <涂鸦>范例的功能说明 274
12.3 实践<挟天子以令诸侯> 275
12.3.1 阶段一：从传统类（Class）造形设计出发 275
12.3.2 阶段二：继续运用EIT造形设计 276
12.4 参考文献 308
· · · · · · (收起)
读后感
很认真地看了前6章，后面实在看不下去，草草翻了一下，看完都开始怀疑自己的阅读和技术能力了。罗里吧嗦，表述很乱；内容重复堆砌，真的没有什么养分。还有那个EIT构形简直就是个垃圾。 千万别买，千万别买，千万别买。重要的事情说3次
评分很认真地看了前6章，后面实在看不下去，草草翻了一下，看完都开始怀疑自己的阅读和技术能力了。罗里吧嗦，表述很乱；内容重复堆砌，真的没有什么养分。还有那个EIT构形简直就是个垃圾。 千万别买，千万别买，千万别买。重要的事情说3次
评分很认真地看了前6章，后面实在看不下去，草草翻了一下，看完都开始怀疑自己的阅读和技术能力了。罗里吧嗦，表述很乱；内容重复堆砌，真的没有什么养分。还有那个EIT构形简直就是个垃圾。 千万别买，千万别买，千万别买。重要的事情说3次
评分本书讲解了很多很多思考的技术，我们常说不同人的思维方法是不同的，的确如此，但是我们没有想过，思考是不是也可以学习呢？ 本书的作者告诉你，思考是可以学习的，而且也是有一些固定的技术的。架构师也分为A段和B段，A段常常是非常重要的。我理解这就像我们国家制定的一些指...
评分本书讲解了很多很多思考的技术，我们常说不同人的思维方法是不同的，的确如此，但是我们没有想过，思考是不是也可以学习呢？ 本书的作者告诉你，思考是可以学习的，而且也是有一些固定的技术的。架构师也分为A段和B段，A段常常是非常重要的。我理解这就像我们国家制定的一些指...
用户评价
初次翻开这本书，就被它那种直击核心的洞察力所吸引。作者似乎拥有某种超能力，能将那些我们日常工作中司空见惯、习以为常的“模糊地带”清晰地解构开来。它不是那种堆砌技术术语的教科书，而更像是一场与一位经验老道的架构师的深度对话。读着读着，我经常会停下来，揉揉眼睛，回味刚才那几段话，那种感觉就像是本来你在黑暗中摸索，突然有人点亮了一盏聚光灯，让你猛地意识到：原来问题一直都在那里，只是我没有用对方法去看待它。这本书特别强调了一种“系统性思维”在设计初期的重要性，它教会了我如何从宏观的业务目标出发，反向推导出最合理的模块划分和技术选型，而不是盲目追逐最新的框架或技术热点。特别是关于需求分析和风险预判的部分，提供了极其实用的框架和心智模型，让我在面对复杂项目时，多了一层稳健的思考滤镜。这绝不是一本能速读的书，它需要你沉下心来，边读边在脑海中映射自己的实际项目，才能真正体会到其精髓所在。
评分坦率地说，市面上关于软件架构的书籍汗牛充栋，但很多读起来都像是对前人理论的重复包装，缺乏真正的思想火花。然而，这本书的文字中，洋溢着一种“亲历者”的坦诚和激情。作者毫不避讳地分享了自己在设计巅峰时刻的兴奋，以及在面对系统崩溃时的那种深刻反思和痛苦挣扎。这种真实感，是任何理论书籍都无法比拟的。特别是关于“渐进式架构”的论述，它承认了现实世界的复杂性，拒绝了那种一步到位的“完美设计”的幻想，转而提供了一套可行的、容错率更高的演进路径。书中对于如何平衡短期交付压力和长期系统健康度的讨论，简直是教科书级别的范例。它不是给你一把万能的钥匙，而是教你如何根据不同的锁，去磨制出最适合的钥匙。读罢全书，我感觉自己对待每一次重构和新功能设计，都多了一层谨慎而又充满信心的审视角度。
评分这本书的阅读体验是一种非常独特的“慢热型”的享受。它不像某些快餐式的指南那样提供立竿见影的技巧，而是更注重于培养读者的底层思维模型。它的语言风格非常精炼，没有多余的修饰，每一个句子似乎都经过了千锤百炼，包含了多重含义。我发现自己开始在日常工作中，不自觉地使用书中的一些术语和视角去分析问题，比如当我们讨论某个模块的“边界清晰度”时，脑海中会浮现出书中关于“清晰边界如何降低认知负荷”的论述。对于那些已经有一些项目经验，但感觉自己思维停滞不前的中高级工程师来说，这本书简直是醍醐灌顶。它迫使你跳出你当前技术栈的舒适区，去思考那些更本质的、跨越技术代际的原则。这是一部能够真正提升思维层级的著作，而非仅仅是技术知识的补充。
评分这本书的结构设计堪称匠心独钟，它没有采用传统的“是什么-怎么做”的平铺直叙，而是巧妙地构建了一个递进式的知识体系。我尤其欣赏作者在阐述复杂概念时所使用的类比和案例，它们往往取材于日常生活或经典工程案例，极大地降低了抽象思维的门槛。比如，书中对“接口契约”的描述，竟然引用了国际贸易中的清关流程，这种跨领域的类比一下子就让原本枯燥的软件设计原则变得生动起来，理解起来毫不费力。更重要的是，作者似乎在用一种“反经验主义”的态度来审视设计决策——他不仅告诉你应该怎么做，更会深入剖析过去那些看似成功却暗藏隐患的“反模式”，以及这些反模式是如何一步步侵蚀系统健康度的。读完后，我感觉自己不再只是一个执行者，而是被赋予了一种更深层次的“设计权能”，能够预见到未来代码迭代中可能出现的摩擦点，并提前布局。
评分这本书给我的最大震撼是，它彻底颠覆了我过去对于“架构师”这个角色的理解。我原以为架构工作更多的是在技术栈的选择和代码结构的搭建上，但这本书揭示了架构的本质其实是“决策的艺术”和“沟通的桥梁”。作者花了大量篇幅讨论如何有效地向非技术背景的利益相关者阐述技术方案的权衡取舍，这在我看来，比任何具体的UML图绘制技巧都要宝贵得多。它让你意识到，一个优秀的架构师，一半是工程师，一半是哲学家和外交家。书中对于“技术债务”的衡量标准，也给出了非常务实且可量化的指标，而不是仅仅停留在“感觉很乱”的主观判断上。我尝试着将书中的一些关于“决策树”的工具应用到我最近的一个技术选型会议中，结果效率和共识度都得到了显著提升，这让我对这本书的实用价值深信不疑。
评分简直就是瞎逼逼
评分垃圾，千万别买。
评分垃圾，千万别买。
评分全他妈写些废话，不知道豆瓣怎么还打这么高分。
评分架构师之路漫漫
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 book.quotespace.org All Rights Reserved. 小美书屋 版权所有