软件架构师的12项修炼

出版者:机械工业出版社华章公司

作者:Dave Hendricksen

页数:216

译者:张菲

出版时间:2012-5-1

价格:59.00元

装帧:平装

isbn号码:9787111378600

丛书系列:华章程序员书库

具体描述

每一位软件开发人员都有一个架构师的梦，但为何真正的软件架构师却寥寥无几？软件开发人员更容易在技术上有所积累和突破，但是技术上的精湛并不足以使你成为一位优秀的软件架构师。合格的软件架构师究竟应该具备哪些能力和素养？本书科学而系统地归纳出软件架构师应该具备的完整能力模型，该能力模型呈一金字塔结构，共分为4层：位于最底层的是技术技能，是软件架构师的基石，属于硬技能；从下往上的三层分别是关系技能、个人技能和商务技能，这些都属于软技能。由于硬技能会随着具体技术领域的不同而千差万别，因此本书假定读者已经具备了这方面的技能；但其他3大方面的软技能却在每个技术领域都适用，是每一位软件架构师的必修课，这是本书的核心内容。

为了便于认知和实践，本书将3大方面的软技能分为12项：关系技能包含文雅的举止（在任何环境下都能与人文雅相处的能力）、沟通（与人有效交互的能力）、协商（将事情办成的能力）、领导力（通过施加影响力将事情办成的能力）和政治（“政治场合”与人交互的能力）等5项；个人技能包含透明化（使自我、团队关系和项目透明化的能力）、激情（激发和保护激情的能力）和语境切换（将注意力迅速切换到新语境并保持专注的能力）等3项；商务技能包括商务知识（读懂商务语言的能力和了解产品与顾客的能力）、创新（如何通过学习和思考来创新的能力）、实用主义（抓住关键问题的能力）、认知（认知目标、战略及合作伙伴的能力）等4项。

本书不仅帮助软件开发人员系统地学习如何修炼这12项软技能，而且还能让他们进一步理解软件架构师的角色和本质，使他们最终突破技术的“天花板”，成为一名合格的软件架构师。

作者简介

Dave Hendricksen是Thomson Reuters公司的一名架构工程师。他与公司的新产品开发团队紧密合作，为Westlaw.com等大型在线平台设计创新性产品。他最近还出席了卡内基•梅隆大学强力软件工程学院的“在敏捷世界里设计与构建大型系统”研讨会。

目录信息

译者序
前 言
致 谢
第一部分 关系技能修炼
第1章　文雅的举止 3
1.1　别人怎样评价你 3
1.2　技术之天花板 4
1.3　变得文雅、专业的途径 6
1.3.1　注重关系甚于争执孰对孰错 6
1.3.2　学会委派 8
1.3.3　生活是有反作用的 9
1.3.4　有效沟通之生与死 11
1.3.5　要正直诚实而不是率直 13
1.3.6　不要掩盖问题—它们以后还会冒出来的 14
1.3.7　提供专业的服务 16
1.3.8　忘掉以前的冒犯 17
1.4　小结 19
1.5　参考资料 19
第2章　沟通 22
2.1　沟通原则 23
2.1.1　先听后说 24
2.1.2　专心致志 24
2.1.3　正面思考 25
2.1.4　尽早道歉 25
2.1.5　不要在缺陷上招致恼羞成怒 26
2.2　沟通策略 27
2.2.1　多说“是”，少说“不是” 27
2.2.2　在销售过程中建立起信任关系 28
2.2.3　特殊场合才说“不” 29
2.2.4　抑制想自卫的冲动 31
2.2.5　倾听建议来改善合作 31
2.2.6　了解别人和自己的沟通需求 32
2.2.7　才思敏捷 34
2.3　与执行官沟通 35
2.3.1　执行官需要信任、忠诚和连贯性 35
2.3.2　清晰性甚于完整性 36
2.3.3　不要让执行官感到惊讶 37
2.4　小结 38
2.5　参考资料 39
第3章　协商 41
3.1　协商原则 42
3.1.1　不要让人惊讶 42
3.1.2　不要模棱两可 43
3.1.3　委派权威而不是义务 43
3.1.4　有困难时寻求帮助 44
3.1.5　不要掩盖问题 44
3.1.6　即使很难，也要坚持做正确的事 45
3.2　协商策略 45
3.2.1　倾听你的内心呼唤 45
3.2.2　设法同意 45
3.2.3　不要找分歧 47
3.2.4　寻找共同点 47
3.2.5　如果无法达到一致，就让所有人稍微不满吧 48
3.2.6　将协商作为一种改进措施 49
3.3　协商前的工作 49
3.3.1　知道哪些是可协商的 49
3.3.2　了解如何在单位里游刃有余 51
3.3.3　关键决定上寻求合作氛围 52
3.3.4　学习文化 53
3.3.5　让别人明白你的想法 53
3.4　协商的收尾 54
3.4.1　捍卫决策的执行 54
3.4.2　维护架构决定记录 54
3.4.3　你有时会赢，有时会输 55
3.4.4　从委派中学习 56
3.5　小结 56
3.6　参考资料 58
第4章　领导力 60
4.1　领导力的原则 61
4.1.1　建立信任关系 61
4.1.2　建立共识 62
4.1.3　建立战略伙伴关系（通过关系带来安全） 62
4.1.4　要身体力行（为你所说的话带来安全） 63
4.1.5　感知风险、评估影响、做出行动（明确风险的清晰度） 64
4.1.6　适当处理风险：什么是鞭炮，什么是原子弹（明确影响的清晰度） 65
4.2　领导策略 66
4.2.1　奥卡姆剃刀法 66
4.2.2　展现可视化信息 66
4.2.3　领导者要确保事情不跑题 67
4.2.4　基于环境推销 68
4.2.5　随大流（找机会利用已有的资源） 69
4.2.6　关注执行官于认知，而非解决冲突 69
4.3　领导的时机 70
4.3.1　利用单位的动量 70
4.3.2　知道何时伸出援手 71
4.3.3　允许其他人学习 71
4.3.4　知道何时该卓尔不群 72
4.3.5　请求原谅还是征求允许 73
4.4　领导别人 73
4.4.1　允许别人奉献（不要命令） 74
4.4.2　通过影响力激励别人 76
4.4.3　确保别人能做主 76
4.4.4　处理冲突 77
4.5　小结 77
4.6　参考资料 79
第5章　政治 81
5.1　政治的定义 81
5.2　政治市场 82
5.3　政治环境 85
5.3.1　与公司的战略方向保持一致 85
5.3.2　理解你所处的文化环境 86
5.3.3　及早处理别人关注的问题 87
5.3.4　相信你所推销的东西 89
5.3.5　不关我的事 90
5.3.6　关系很重要（与别人的关系） 90
5.4　政治原则 91
5.4.1　宽宏大量 91
5.4.2　不要为你的价值妥协 92
5.4.3　光明正大地竞争 92
5.4.4　透明地操作 92
5.4.5　你是怎样的人就怎样表现 93
5.4.6　帮助别人，不求回报 93
5.4.7　认识到生活是反身的 93
5.5　政治策略 94
5.5.1　帮助别人达成其目标 94
5.5.2　学会享受过程而不是目标 94
5.5.3　在关键之处力争出色 95
5.5.4　愿意就低优先级目标妥协 95
5.5.5　不要对别人的糟糕举止采取冒犯的行动 96
5.5.6　私下处理人际问题 97
5.6　政治时机 97
5.6.1　以适时的作风执行事情 97
5.6.2　今天失利并不代表明天不会成功 98
5.6.3　要认识到政治上你不会是常胜将军 99
5.6.4　积极参与政治游戏 99
5.7　成为一名好的政治人物 100
5.8　参考资料 101
第二部分　个人技能修炼
第6章　透明化 105
6.1　住在玻璃房中的架构师 105
6.2　透明化的类型 106
6.3　自我透明化 107
6.3.1　表现自然真诚 107
6.3.2　承认自己的弱点 108
6.3.3　承认你的实力和兴趣 109
6.3.4　赶在人前与上司沟通 110
6.4　项目透明化 111
6.4.1　让执行官看到你手里所有的扑克牌 111
6.4.2　架构师把透明化和清晰性带到许多领域 112
6.4.3　架构师将“发现”变成“收获” 113
6.5　关系透明化 116
6.5.1　该信任时就给别人信任 116
6.5.2　你说的话长久不变 117
6.5.3　道歉表明你的透明化 118
6.5.4　学会在做出反应前倾听（寻求透明化） 118
6.5.5　允许别人对你透明化 119
6.6　成为一名透明的架构师 119
6.7　参考资料 120
第7章　激情 122
7.1　什么是激情 123
7.2　发现激情 124
7.2.1　如何找到激情 124
7.2.2　恒心与激情：终极的杀手组合 125
7.2.3　岗位上的激情 126
7.2.4　重新点燃激情 127
7.3　将激情作为向导 127
7.3.1　等待机遇：它经常在找你，说话非常轻 128
7.3.2　跟着直觉走 129
7.3.3　选择你有激情的领域 129
7.3.4　改变会督促你前行 130
7.3.5　缺乏激情会成为你事业上升的天花板 131
7.3.6　把难事做好，尽心尽力投入 131
7.3.7　激情是提供动力的内在燃料 132
7.4　保护你的激情 132
7.4.1　忽略批评：这是你的激情、你的认知，不是他们的 132
7.4.2　不要分神 133
7.5　今天能做什么来追求你的激情 134
7.6　学会投入并享受过程 135
7.7　成为一名激情四射的架构师 135
7.8　参考资料 136
第8章　语境切换 138
8.1　自我意识语境 140
8.1.1　专心致志 140
8.1.2　明白你的弱项 141
8.1.3　生命中不仅仅有工作 141
8.1.4　多任务工作的效率奥秘 141
8.1.5　控制你的肾上腺素：慢下来 142
8.2　架构意识语境 142
8.2.1　使用“可/有…性”的字眼 142
8.2.2　寻求适当的耦合性和内聚性 142
8.2.3　持续构建你的语境 143
8.3　“大象”语境 144
8.3.1　哪些事没有提到 144
8.3.2　提问一些难题 145
8.3.3　早些发出坏消息 145
8.3.4　如果他们拥有这个公司，他们会怎么做 146
8.4　决策意识语境 146
8.4.1　他们真的已经把问题解决了 146
8.4.2　他们知道哪些替代方案可行吗 147
8.4.3　别人是否已经权衡过此技术 147
8.4.4　作为中立的第三方，即便这样做是个缺点 147
8.5　交谈语境 148
8.5.1　不要开会和用电子邮件 148
8.5.2　如果需要，（马上）让别人参与进来 148
8.6　谈话者语境 148
8.6.1　了解你的谈话对象 148
8.6.2　中庸之道 149
8.6.3　有时要唱红脸，有时要唱白脸 149
8.6.4　提供背景信息 149
8.7　项目语境 150
8.7.1　提出预算 150
8.7.2　带来实用性 151
8.7.3　学会在雪崩中冲浪 151
8.7.4　挑出专门的资源 151
8.7.5　你做出了哪些假设条件 152
8.8　成为一名善于察言观色、见风使舵的架构师 152
8.9　参考资料 154
第三部分　商务技能修炼
第9章　商务知识 157
9.1　了解商务 159
9.1.1　营销、财务（投入产出比）和销售 159
9.1.2　考虑拿一个商务学位 161
9.2　了解你的公司 162
9.2.1　了解产品对客户的价值所在 162
9.2.2　知道你的公司如何赚钱 163
9.2.3　了解你公司的历史、文化 163
9.3　了解你的顾客 164
9.3.1　考虑拜访顾客、打电话给销售或者在门面上帮员工干活 164
9.3.2　考虑参与可用性研究，参与产品概念访谈或其他客户产品评估 167
9.3.3　考虑使用敏捷技术 167
9.4　了解你的领域 167
9.4.1　收集领域知识 168
9.4.2　在商务环境中了解你的领域 169
9.5　帮助公司更好地了解技术 169
9.6　成为一名谙熟商务的架构师 170
9.7　参考资料 171
第10章　创新 173
10.1　创新的定义 174
10.2　建立边界条件 175
10.2.1　找出边界条件 175
10.2.2　在边界内创新 176
10.2.3　你会做什么（假如没有约束条件，不必故作姿态） 178
10.2.4　鼓励别人思考、开放 178
10.2.5　应对那些唱反调的人 179
10.2.6　避开唱反调的人，找个安全的地方来思考 179
10.3　发展内心准则 179
10.3.1　顺从你的直觉 179
10.3.2　学会信任自己 180
10.3.3　认真倾听客户的声音，但要保持自己的认知 180
10.3.4　听听别人的话（协作） 181
10.3.5　你今天能迈出一小步吗 181
10.3.6　今天不行没关系：继续埋头苦干，早晚会成功的 182
10.4　组合基本概念 182
10.4.1　阅读、阅读、还是阅读 183
10.4.2　疯狂的主意让你发现真正的边界 183
10.4.3　要有大眼光 184
10.4.4　创新者的困难抉择 184
10.4.5　创新与集聚：将事情按正确分组整合在一起 184
10.4.6　选择简洁 185
10.4.7　简洁性是知识产权的根本 185
10.4.8　在着手解决前先思考问题 186
10.4.9　定义问题 186
10.4.10　睡觉时思考 187
10.4.11　战略问题还是战术问题 187
10.5　成为一名能创新的架构师 187
10.6　参考资料 189
第11章　实用主义 191
11.1　实用型架构的定义 191
11.2　范围管理 192
11.2.1　与商务伙伴一起确定特性的优先级 192
11.2.2　帮助执行官做出正确决策 193
11.2.3　处理不确定性 193
11.2.4　有些时候，你只需要一个概念就能开始干了 193
11.2.5　使用敏捷过程作为一种实用主义方法 194
11.3　风险管理 194
11.3.1　区分可能性和可行性 194
11.3.2　对于每个决定，都自问一些重要的问题 196
11.3.3　应对可能的风险 197
11.3.4　架构刺探 197
11.3.5　与运营人员一起确定效率 197
11.3.6　观察其他项目，决定有哪些地方是可牺牲的 198
11.4　沟通 198
11.4.1　记录下大家一致同意的决议 199
11.4.2　提供多种替代方案，并推荐其中一种 199
11.4.3　用透明性拉平期望值 199
11.4.4　发展经验方法来估量项目 200
11.5　成为一名实用主义的架构师 200
11.6　参考资料 201
第12章　认知 203
12.1　认知之定义 204
12.2　找寻和创立引人注目的目标 204
12.2.1　发现认知 204
12.2.2　从混沌现实编造出有说服力的故事 206
12.2.3　克服障碍 207
12.3　开发与建立战略路线图 208
12.3.1　将路线映射至认知 208
12.3.2　制定支持认知的战略 209
12.4　确定志同道合的伙伴 210
12.4.1　认知需要齐心协力 210
12.4.2　认知要求有关键的利益相关者 211
12.4.3　认知需要资金支持 212
12.5　实践认知 213
12.5.1　将认知当做增加投入产出比的战略 213
12.5.2　使用认知灌输目标感 213
12.5.3　在项目评估时就应用认知 214
12.5.4　采用支出信封（界定认知范围） 215
12.6　成为一名有远见的架构师 215
12.7　参考资料 216
· · · · · · (收起)

读后感

花了近一个月的时间阅读了这本书。这是一本翻译很烂的书，虽然书的内容是原作者多年工作的结晶。 读一本书，能学到一两句话，一两个方法，已经是算是成功，没有白费几十块钱和阅读的时间。这也就所谓的开卷有益。 开篇讲 “注重关系甚于对错”，让我们明白，原...  

看样子那里都一样 不能光沉迷技术 搞办公室政治 国人估计也要跟别人学学 如果平衡 如何利益最大化 读后感觉不光技不如人 而且 玩政治也玩不赢人家 {以下忽略 凑字发帖 凑字发帖 凑字发帖 凑字发帖 凑字发帖 凑字发帖 }

花了近一个月的时间阅读了这本书。这是一本翻译很烂的书，虽然书的内容是原作者多年工作的结晶。 读一本书，能学到一两句话，一两个方法，已经是算是成功，没有白费几十块钱和阅读的时间。这也就所谓的开卷有益。 开篇讲 “注重关系甚于对错”，让我们明白，原...  

看样子那里都一样 不能光沉迷技术 搞办公室政治 国人估计也要跟别人学学 如果平衡 如何利益最大化 读后感觉不光技不如人 而且 玩政治也玩不赢人家 {以下忽略 凑字发帖 凑字发帖 凑字发帖 凑字发帖 凑字发帖 凑字发帖 }

用户评价

读完前三章，我立刻被作者那种近乎苛刻的思维深度所折服。这不是那种人云亦云的“最佳实践”汇总，而是真正深入到“为什么”和“在什么条件下适用”的哲学层面。比如，在讨论“领域驱动设计（DDD）”的应用时，作者并没有停留在如何划分界限上下文（Bounded Context）的表面技巧，而是花了大量篇幅阐述了如何通过业务语言的统一（Ubiquitous Language）来驱动模型设计，这要求架构师必须具备极强的跨职能沟通能力。书中引述的几个案例都极具代表性，它们揭示了在实际项目中，技术债的积累往往源于早期架构设计对业务边界理解的偏差，而非编码质量本身。这种深挖根源的分析方式，让我对以往很多失败的项目有了新的理解角度。此外，作者在论述“安全性设计”时，摆脱了传统的防火墙、加密这些基础安全措施的简单介绍，而是聚焦于如何在微服务架构下构建零信任（Zero Trust）的安全模型，讨论了服务间认证、授权的最佳实践，甚至提到了供应链安全在CI/CD流水线中的集成策略。这本书的行文节奏非常紧凑，信息密度极高，我不得不放慢速度，甚至需要时常停下来，结合自己手头的工作场景进行对照反思，这是一种非常高效的学习体验。它真的在逼迫你思考，如果明天你就是那个决策者，你会如何应对这些复杂多变的情况。

这本书的封面设计很有质感，深色调的背景上印着几行白色的、结构清晰的文字，给人一种专业而稳重的感觉，光是拿起它，就能感受到一股沉甸甸的知识分量。我特别喜欢它在目录布局上的设计，不是那种流水账式的罗列，而是将不同的修炼点用模块化的方式划分出来，就像一个精心搭建的知识体系框架。我最先翻阅的是关于“技术选型与权衡”的那一章，作者没有给出简单的“选A不选B”的结论，而是深入探讨了在不同业务场景下，评估不同技术栈的关键考量因素，比如系统的可扩展性需求、团队现有的技术栈熟练度、以及预期的维护成本。他用了一系列生动的案例，比如一个高并发电商系统的限流策略设计，详尽地剖析了为什么最终选择了基于服务网格的熔断降级而不是简单的轮询限流，其中的逻辑推导过程非常严谨且有启发性。这本书的叙事风格是那种将复杂的理论用最直观的语言表达出来，避免了过多的晦涩术语堆砌，即便是初接触这些高阶概念的读者，也能快速抓住核心要点。更让我惊喜的是，它还穿插了一些关于“架构师软技能”的讨论，比如如何向上汇报架构决策，如何有效地推动跨部门的技术协同，这恰恰是很多纯技术书籍会忽略但却至关重要的一环。整体而言，这本书为我提供了一个系统性的思考框架，远超出了我预期的技术手册范畴，更像是一位资深前辈手把手的指导。

这本书给我的最大感受是“务实中的理想主义”。它既不盲目追捧最新的时髦技术，也不沉溺于过时的教条，而是始终以解决实际业务问题为核心导向。特别是关于“技术债务管理”的那几个章节，写得尤为精彩。作者用了一个非常形象的比喻，将技术债务比作一个不断复利增长的贷款，指出延迟偿还的成本远高于主动投入资源进行重构的成本。书中详述了几种主动管理技术债务的策略，比如“刹车点”（Stop-the-line）策略，即在特定业务增长节点强制进行架构清理，以及“持续小额偿还”的模型。这让我意识到，架构的健康度并非一蹴而就，而是需要像维护一个大型园林一样，需要持续投入人力物力进行修剪和维护。书中对“API设计与版本控制”的讨论也极为透彻，特别是针对如何处理向后兼容性（Backward Compatibility）的棘手问题，提供了多套成熟的策略和迁移路径，避免了为了追求“优雅”而导致业务方痛苦升级的僵局。这本书的排版和插图选择也很有助于阅读体验，它没有使用那种密密麻麻的文字块，而是巧妙地运用了流程图和对比表格，让复杂的对比逻辑一目了然，这对于需要快速吸收信息的专业人士来说，无疑是巨大的加分项。

我通常对“修炼”类的书籍抱持一种谨慎态度，因为很多这类书籍内容空泛，口号大于实质。然而，这本让我彻底改变了看法。它在探讨“架构师领导力”和“培养架构师团队”的部分，展现出一种罕见的洞察力。作者清晰地描绘了从“个人英雄主义”到“团队驱动”的转变过程，强调了架构师的角色更像是“赋能者”而非“独裁者”。他详细阐述了如何通过设定清晰的“架构原则”（Architectural Principles）来指导团队做去中心化的决策，而不是事无巨细地干预每一个技术选择。这种对组织行为学的深入理解，是区分普通高级工程师和真正架构师的关键。书中还穿插了一些关于“技术评估前沿趋势”的分析，比如对Serverless和边缘计算的长期影响的预判，作者的观点既有前瞻性，又回归到了成本效益的现实考量，避免了将新技术神化。总而言之，这本书提供了一种动态的、适应性强的思维框架，它教你的不仅仅是“如何设计系统”，更是“如何在这个快速变化的技术生态中持续进化，并带领你的团队一起成长”。读完合上书本时，我感觉自己收获的不是一堆知识点，而是一整套应对未来不确定性的方法论。

这本书的结构布局设计得极为精妙，它似乎是按照一个初级工程师成长为资深架构师的自然路径来组织的，层层递进，逻辑浑然天成。我尤其欣赏它在探讨“可观测性”这一主题时的全面性。它没有仅仅停留在 Prometheus 和 Grafana 的工具层面，而是从一个更宏观的视角切入——即如何构建一个有效的“反馈循环”来持续优化系统性能。作者细致地拆解了日志（Logging）、指标（Metrics）和追踪（Tracing）三者的角色定位、数据采集的最佳实践，以及如何将这三者关联起来形成一个完整的“故事线”。我记得有一段话非常深刻，大意是：如果你的系统出了问题，但你无法在五分钟内追溯到问题的根源，那么无论你的代码多么优雅，你的系统在架构层面上都是失败的。这种对时间敏感度的强调，让抽象的架构概念立刻变得具象化和紧迫化。再者，书中对于“治理”的论述也独树一帜，它超越了单纯的技术治理，探讨了如何在组织结构和流程层面固化架构决策的有效性，比如如何建立有效的架构评审委员会（ARB）机制，确保“一次正确的架构”能够持续落地，而不是沦为PPT上的漂亮图纸。读完这一部分，我感觉自己看待“管理”和“技术”的关系都有了新的视角。

偏理论，例子好少

点都是很精准的，阐述却是很苍白的

不出意外，应该是我目前为止读过最好的做好Tech Leader 方面的书。

又翻出来把这本书重读了一遍，依旧是那么经典，依旧那么多收获。要获得灵感，就是要不断阅读

技术之外