本文引自周爱民老师[就职于南潮(Ruff)，现任架构师一职]写给《程序员必读之软件架构》一书的推荐序。

编者按：软件架构师是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，制定项目的总体架构，并指导开发团队完成这个计划的人员。软件架构师主导系统全局分析设计与实施和关键技术决策。所谓的架构角色，是对思维和技术上的双重挑战，也应该是所有开发者的终极目标。希望此文对想要成为、即将成为或已经成为架构师的朋友受用。

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. 要学会超越

架构师需要超越自己与别人的所见，因为你观察与架构的对象称为“系统”，你看到系统多少的真相，决定了你用怎样的影像去表现它，并进而推进与实现这种影像，亦即是架构。我们既已知道的、理解的、明白的，形成了我们的知识与行为的一切，却也正是阻碍着我们前进的东西。

这些障碍正是你以为你最珍视的、最不可放弃的、最鲜血淅沥体验过的那些经验与成就。在这些所得与所碍中挣扎与决策，就是架构师的全部职责。因此作为架构师，你需要能够超越自已对系统的既有认识，看到你在光明中——显而易见之处——所未见的，这是你驱动系统架构进化的主要动力。

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

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

《程序员必读之软件架构》是一本强调实践、注重实效、轻量级、面向开发者的软件架构指南。如果你是一名想成为软件架构师的程序员，那么《程序员必读之软件架构》就是你的不二之选。

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

目　录

推荐序一：架构师真正要学会的事情　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 Ⅷ　附录：“技术部落”的软件指南