书名：程序员必读之软件架构  
ISBN：9787115371072  
作者：[英]Simon Brown 著  
开本：16开  
版次：第版  
出版时间：2015-04  

内容提要：  

内容简介：

通常，人们对软件架构师持两种错误的看法。有人认为软件架构师是一种高高在上的职位；有人认为软件架构师完全不懂开发，只是会画条条框框的指挥家。本书将打破这些传统的认知，模糊软件开发和架构在流程中的界限，进而为软件架构正名。本书是一本强调实践、注重实效、轻量级、面向开发者的软件架构指南。

　　通常，人们对软件架构师持两种错误的看法。有人认为软件架构师是一种高高在上的职位；有人认为软件架构师完全不懂开发，只是会画条条框框的指挥家。《程序员必读之软件架构》将打破这些传统的认知，模糊软件开发和架构在流程中的界限，进而为软件架构正名。《程序员必读之软件架构》是一本强调实践、注重实效、轻量级、面向开发者的软件架构指南。 　　如果你是一名想成为软件架构师的程序员，那么《程序员必读之软件架构》就是为你准备的。  


作者介绍：  

作者简介：

Simon Brown

全球知名软件架构独立咨询师、讲师，创办了专门讨论软件架构问题的网站“编码架构”（codingthearchitecture.com）。他自称是写代码的软件架构师和明白架构的软件开发者。自2008年以来的7年时间里，Simon在全球28个国家做过有关软件架构、技术领导力及其与敏捷的平衡等主题的百余场演讲，并于2012年8月在中国举办的ArchSummit全球架构师峰会上以“郁闷的架构师”和“如何设计安全的架构”为主题发表演讲，深受与会者好评。Simon已为全球20多个国家的软件团队提供咨询和培训，他的客户既有小型技术初创企业，也不乏全球家喻户晓的品牌公司。

译者简介：

邓钢

误打误撞进入IT行业的80后程序员，爱好Web技术，对前端技术尤其偏爱。曾在盛大创新院担任前端工程师，现在是IBM上海的一名软件用户界面工程师。除了具体的技术，对软件架构、软件工程也很感兴趣，希望把自己在IBM所见所闻分享出来，为前端领域如火如荼的工程化浪潮贡献力量。

媒体评论：  

媒体评论：

“这是一本‘指南’型图书。作者会给你一个图景以及达到它的关键技术指引，你可以得到一个思考问题的框架，而非一条道路或一套方法。但对于架构师来说，这样就足够了。”

——周爱民，现任豌豆荚架构师，前盛大网络平台架构师、支付宝业务架构师

目录：  

推荐序一：架构师真正要学会的事情 ix

推荐序二 xii

译者序2.0 xiii

序 xvi

关于本书 xix

软件架构培训 xxii

Part Ⅰ 什么是软件架构

第1章 什么是架构 2

第2章 架构的种类 4

第3章 软件架构是什么 6

第4章 敏捷软件架构是什么 8

第5章 架构对上设计 11

第6章 软件架构重要吗 13

第7章 问题 15

Part Ⅱ 软件架构的角色

第8章 软件架构的角色 18

第9章 软件架构师应该编码吗 22

第10章 软件架构师应该是建造大师 25

第11章 从开发者到架构师 30

第12章 拓展T 32

第13章 软技能 34

第14章 软件架构不是接力运动 36

第15章 软件架构要引入控制吗 38

第16章 小心鸿沟 40

第17章 未来的软件架构师在哪里 42

第18章 每个人都是架构师，除非他们有其他身份 44

第19章 软件架构咨询师 46

第20章 问题 48

Part Ⅲ 设计软件

第21章 架构驱动力 50

第22章 质量属性（非功能需求） 52

第23章 处理非功能需求 55

第24章 约束 57

第25章 原则 60

第26章 技术不是实现细节 63

第27章 更多分层等于更高复杂度 66

第28章 协同设计是一把双刃剑 68

第29章 软件架构是对话的平台 70

第30章 SharePoint项目也需要软件架构 72

第31章 问题 74

Part Ⅳ 可视化软件

第32章 沟通障碍 76

第33章 对草图的需要 78

第34章 无效的草图 81

第35章 C4：语境、容器、组件和类 91

第36章 语境图 94

第37章 容器图 98

第38章 组件图 102

第39章 是否包含技术选择 107

第40章 你会那样编码吗 110

第41章 软件架构和编码 112

第42章 你不需要UML工具 117

第43章 有效的草图 120

第44章 C4的常见问题 124

第45章 问题 126

Part Ⅴ 为软件生成文档

第46章 代码不会讲述完整的故事 128

第47章 软件文档即指南 131

第48章 语境 136

第49章 功能性概览 137

第50章 质量属性 139

第51章 约束 141

第52章 原则 143

第53章 软件架构 145

第54章 外部接口 147

第55章 代码 149

第56章 数据 151

第57章 基础设施架构 153

第58章 部署 155

第59章 运营和支持 157

第60章 决策日志 159

第61章 问题 161

Part Ⅵ 开发生命周期中的软件架构

第62章 敏捷和架构的冲突：神话还是现实 164

第63章 量化风险 167

第64章 风险风暴 169

第65章 恰如其分的预先设计 173

第66章 初识软件架构 179

第67章 问题 183

Part Ⅶ 金融风险系统

第68章 金融风险系统 186

Part Ⅷ 附录：“技术部落”的软件指南

在线试读：  

推荐序一：架构师真正要学会的事情

1.要学会去看，然后忘掉

有一本书叫《观止》，写的是微软研发Windows NT的一段故事。“观止”在这里的意思是说“看到这些，就无需再看了”，因为世上之物亦无过于此。20多年过去，如今微软在操作系统上面临着的种种挑战与困境，其实与《观止》所叙的研发方法、理念与目标有着与生俱来的血缘关系。

另一个与“看”相关的词汇是“所见即可得”（WYSIWYG）。这个词以及与此相关的WIMP（Windows, Icon, Menu and Pointer）曾经主导了整个人机交互的设计理念。也是在20多年前，Borland为Windows桌面系统成功地设计了跨语言的VCL，由此“所见即所得”成为Borland对“如何更便捷地构建UI”的基本假想，以至于这家伟大的公司在互联网时代来临时决定“用VCL描述界面的方式来解决‘网站设计’的问题（RadPHP）”。

然而，互联网上的网页是没有WIMP的；移动设备上的操作系统也不再采用与Windows NT类似的方式开发。

Borland在几年之前将整个开发工具产品线都卖掉了。当时盛大的一个Delphi圈子发起了一次“缅怀活动”，组织者说：“爱民，你应该会为那个时代写点什么吧？”

我在那个缅怀网页上写下了五个字：所见即所碍。

2.要学会去听，然后忘掉

我通常说架构是一种能力，架构角色则是要求你在具体事务中行使某些行为，而架构师则是用来标识这些能力与行为的一个职务。

当一些人将个人成长定义为“职业发展”时，就表现为“怎样成为架构师”这样的问题。对此有三种解决方案，第一种是印一张写着这样头衔的名片，而“是与不是”架构师并不重要；第二种是直接否定这个职务的意义，比如声称敏捷天生就是反架构的，于是“架构师”变成了要打倒的对象，所以成不成为这个将被打倒的对象也就不重要了；第三种则干脆声称“人人都是架构师”，既然人人都是了，那么“如何成为”也自然就不重要了。

我们大多数人都具有架构的能力，并且也或多或少地行使某些架构角色的行为，唯一缺乏的只是一个叫做“架构师”的头衔而已。问题出在我们总是期望别人通过这样的头衔来认可自己。于是我们为自己贴上这样或那样的标签，然后跟别人持有的同种标签去比对，期求出现一致或找出某种差别。于是我们听到种种声音：某某某真的是/不是、像/不像架构师；如果是架构师，那么就要这样那样，以及怎样怎样；其实这个架构、这样的架构，或某种架构应该怎么做；以及架构是什么，架构师是什么，等等。回顾“三种解决方案”，仍是困在这样的认可求同之中，与之在做着种种斗争罢了。

其实不单是你的所见阻碍了你自己，你还被别人的所见阻碍着。

3.要学会去做，然后忘掉

朋友跟我聊他家的两岁小孩：我刚把桌子收拾好，一转眼杯子碗筷什么的都全摔地上了。我问：“怎么了？”他说：“小孩子什么也不懂啊，她看到桌布觉得喜欢，就一把抓过去……”

小孩子没能看到桌子上还有杯子，但正因为他们的视线里没有杯子，他们的行动才简单直接，才直达需求，才迅速。而我们的眼睛里有杯子、桌子、桌布等一切，我们经年累月地维护着其中的次序与关系直到这些东西混成一体，然后我们便日日坐守在它们的面前，而又无觉他们的存在。

正是我们自己不知不觉地设定了这些事物之间的界线，并把这些界限、层次与逻辑井然的东西称为“系统”。当我们从那些无序的事物中识别出了这样的“系统”并用一些概念、名词去定义了它们之后，我们对此的一切知识也就固化了。当这种秩序被建立起来之后，我们也就得到了对有序和无序（没有你所设定的“这种秩序”）价值的识别与肯否；当我们设定了种种价值、观念、观察与系统的模型概念之后，也就完成了这个系统的架构。

但这一过程，包括完成这一架构——它可以命名为“世界观”——的方法以及结果，在本质上不过是让你从一个格子跳到了另一个格子而已。我们处在种种界限之中，再也无法回到两岁小孩的、一切无碍的视角：在那个视角下，根本就没有所谓的界线。你之所以时时在寻求跨界，其实是源自你假设了“存在界线”，这就如同全栈的含义其实是“没有栈”，而当有人信心满满地要“成为全栈工程师”时，他的眼里便又有个“这个栈”的存在。

所谓跨界不是指你能力与方法上的变化，你的作为取决于你的格局，你的格局取决于你的所见。

4.要学会超越

架构师需要超越自己与别人的所见，因为你观察与架构的对象称为“系统”，你看到系统多少的真相，决定了你用怎样的影像去表现它，并进而推进与实现这种影像，亦即是架构。我们既已知道的、理解的、明白的，形成了我们的知识与行为的一切，却也正是阻碍着我们前进的东西。这些障碍正是你以为你最珍视的、最不可放弃的、最鲜血淅沥体验过的那些经验与成就。在这些所得与所碍中挣扎与决策，就是架构师的全部职责。因此作为架构师，你需要能够超越自已对系统的既有认识，看到你在光明中——显而易见之处——所未见的，这是你驱动系统架构进化的主要动力。

所以架构中最难超越的并不是某个大师或前辈，而是你以及你为自己所作的设定。当你设定了“架构师”这个目标，便设定了这个目标所表达的某种影像（角色），你最终可能变得跟这个影像完全一致——成为所谓的“真正的架构师”，但你仍不过是困囿于对这个“角色”的一个假设/设定而已。唯一破局的方法是：超越别人对某个角色的定义，将自己做成这个角色。

至此，你是否还在这个角色之中，就是你的觉悟了。

周爱民
现任豌豆荚架构师
前盛大网络平台架构师、支付宝业务架构师

推荐序二

说起架构，想必很多人会认为它离自己太远，我做的事情还远到不了架构这么高的层次。那么什么是架构呢？正如本书作者所做的调查一样，不同的人会给出不同的见解。

我们不妨从平时的项目中来观察一下，技术选型是怎么出来的？团队的分工协作是如何进行的？项目质量和进度是怎么得到保障的？

是的，你会发现，在任何一个项目中，总有些人会在这些事情上付出努力。从他们身上可以看到哪些不一样的特质？他们看起来都很积极，好像整个项目就是他们在负责；他们让事情得到解决，最终让项目得以交付。

可以认为，项目中出现的类似行为都是在对架构的思考，思考架构会是从被动服务到主动服务的Owner意识养成过程，会让我们Get things done！而最终完成的好坏及是否有方法论支撑则是另外讨论的范畴，这也正是本书要为大家呈现的内容！

如果你刚接触项目不久，建议由浅入深，从分清楚什么是库什么是框架开始，带着问题在本书中寻找答案！如果你已经验丰富，同样可以认真思考书中每一部分后面的问题进行自我对照，看看与作者的建议是否有共鸣之处！

从现在开始，认真且有效地去规划完成自己负责的事情！

杜欢
淘宝网高级技术专家