基本信息
- 作者： (英)Simon Brown
- 丛书名： 图灵程序设计丛书
- 出版社：人民邮电出版社
- ISBN：9787115371072
- 上架时间：2014-11-5
- 出版日期：2015 年1月
- 开本：16开
- 页码：205
- 版次：1-1
- 所属分类：计算机 > 软件工程及软件方法学 > 软件方法/软件工程
编辑推荐
软件架构在成功的软件交付中扮演着重要角色，但IT行业一直对软件架构存在误解，缺乏应有的重视。提到软件架构，人们脑海中浮现的画面通常是架构师闭门造车，提前作好大型预置设计，然后将UML模型或数百页客户需求文档扔给毫不知情的开发团队。很多组织也将软件架构看做一种职位级别而非工作角色，甚至为了节省成本，将编码工作外包，将本地开发人员推上“高高在上”的架构师职位。种种现状导致软件架构与编码严重脱节，也致使软件架构师在开发人员群体中名声不佳，被视为脱离实际工作、只会画框框线线的“指挥家”。其实，下至接口设计，上至技术选型，每个程序员多多少少都接触或参与过一些架构工作，架构师也自然而然成为相当一部分程序员的职业发展方向。
本书从全新的视角重新解读软件架构，揭示软件架构的本质，是一本强调实践、注重实效、轻量级、面向开发人员的软件架构指南。本书作者是一位备受好评的软件架构讲师，为全球20多个国家的软件团队提供咨询和培训，其中不乏家喻户晓的大型企业。在过去几年中，他的实践经验已令数千人受益终生。
如果你是一名软件开发人员，那么本书定会对你的职业发展有所助益。
内容简介
作译者
Simon Brown
全球知名软件架构独立咨询师、讲师，创办了专门讨论软件架构问题的网站“编码架构”（codingthearchitecture.com）。他自称是写代码的软件架构师和明白架构的软件开发者。自2008年以来的7年时间里，Simon在全球28个国家做过有关软件架构、技术领导力及其与敏捷的平衡等主题的百余场演讲，并于2012年8月在中国举办的ArchSummit全球架构师峰会上以“郁闷的架构师”和“如何设计安全的架构”为主题发表演讲，深受与会者好评。Simon已为全球20多个国家的软件团队提供咨询和培训，他的客户既有小型技术初创企业，也不乏全球家喻户晓的品牌公司。
邓钢
误打误撞进入IT行业的80后程序员，爱好Web技术，对前端技术尤其偏爱。曾在盛大创新院担任前端工程师，现在是IBM上海的一名软件用户界面工程师。除了具体的技术，对软件架构、软件工程也很感兴趣，希望把自己在IBM所见所闻分享出来，为前端领域如火如荼的工程化浪潮贡献力量。
全球知名软件架构独立咨询师、讲师，创办了专门讨论软件架构问题的网站“编码架构”（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
推荐序一：架构师真正要学会的事情 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
译者序
在本书行将出版之时读到周爱民老师写的推荐序，感触良多。因而书还未面世，译者序就写了第二稿，倒也跟IT行业的风格挺契合：很多软件首次发布时的版本号都是2.0，甚至更高。
初识软件架构
我是从一个小互联网公司走出来的野生程序员。小公司里没有很细的分工，程序员必须像万金油，什么都会一点。数据怎么分表，后端接口怎么分，URL结构怎么定，前后端怎么接，这些都得搞定。事情多了，必须想清楚。
我在盛大创新院做的最后一个项目是一个iOS垂直社交应用。两个同事合作开发iOS客户端，而我在这个项目里的工作是开发一个REST架构的数据服务。需求很简单，就是根据客户端的应用场景编写一整套API。当第一个里程碑的所有工作完成之后，我发现需求开发只占用了一小部分时间，而设计关系型数据库的结构，设计认证、授权和报告，设计应用签名和令牌，设计REST风格的URL结构，开发API调试工具，编写API文档，这些事情却耗费了大量的时间。我就想，花了这么多时间做这些事情，并没有增加任何功能，又感觉不能不做，这到底是为什么？对这个问题的思考和学习，应该算是我对软件架构的入门。
怎么会翻译这本书
两年前我进入IBM，参与的项目是一个适用于大型数据中心的存储资源管理工具。这个工具的规模和复杂程度远远超出大多数面向普通用户的互联网应用，自然对架构的要求更为严苛。而IBM作为一家传统软件企业，深厚的技术积累也令我大开眼界，给了我很多学习和思考软件架构的机会和资源。
我们项目的架构师会贡献代码，会参加代码评审/回顾；我们有预先架构设计，也有架构演化；我们执行SCRUM方法；任何人对设计有意见，都可以给架构师发邮件，只要有理有据，就能说服他更改设计。在此之前我从未见过这样奇特的组合。很快适应了以后，我又想，这么好的方式，居然只有我们在用？直到今年三月，在微博上看到图灵的李松峰老师为Software Architecture for Developers一书征召译者。读过样章后才发现，我们就是作者理想中的团队啊！既然如此，何不尝试翻译这本书？
架构离我们并不遥远
写给程序员的软件架构，这是一个很有趣的出发点。长久以来，架构师在程序员群体中声名狼藉，软件架构被很多人认为是一项脱离现实、高高在上的工作。其实对程序员来说，架构近在眼前！下至接口设计，上至技术选型，不论你是否意识到，每个程序员或多或少都接触和参与过一些架构工作。架构师也自然而然成为相当一部分程序员的职业发展方向：你看，我们努力想要成为自己咒骂的人。
本书的作者是一位经验丰富的架构师。他从最简单的基本概念入手，对软件架构进行了层层深入的细致讲解，结合自己的实践经验，总结出很多实用的准则和方法，并且附上一个完整的开源项目来对这些内容加以佐证，帮助读者学习和理解。翻译这本书，在我看来更是对软件架构的一次系统学习，不仅丰富了我对软件架构的理解，更改变了我对架构师这个角色的一些固有印象。这本书令我获益匪浅，希望更多有志成为架构师的程序员朋友也能从中有所收获。
周爱民老师的序
十一假期结束后打开邮箱，收到图灵的李静老师的邮件，得知周爱民老师会为这本书撰写推荐序。惊喜，因为爱民老师是包括我在内的很多人敬仰的资深前辈。惶恐，因为我在软件架构方面还是个菜鸟，写作能力更与爱民老师相去甚远。
要来爱民老师的文章一读，“然后忘掉”，写得真好！我从未受过任何计算机科学或软件工程的专业训练，大学所学的化学专业也跟计算机毫无关联。因此，去看去听去做，并且牢牢记住，使我得以在这个行业一步步走到今天。自从对软件架构产生兴趣，也是如此逐渐学到很多概念、方法。虽然清楚架构必有权衡，不能十全十美，然而了解的知识越多，就更想面面俱到，反而放不开。殊不知，牢牢记住，也给自己画地为牢，陷入爱民老师所说的困局。
如果说这本书帮我画了一个更大的圈，那么爱民老师的文字则告诫我要跳出这个圈。我面前的架构之路还很长，不知何时能走出圈外，走到爱民老师今日所处之地。
谢谢你们
这本书的翻译能够完成，我最想感谢的人是成都七中的高中语文老师王正可。王老师是我近20年学生生涯中最重要的一位老师：她是第一个让我对语文产生兴趣的人。王老师教给我文字的艺术，帮助我找到阅读和写作的乐趣，对我而言这是一笔巨大的财富。如果不曾有幸成为她的学生，我想我不会养成写作的习惯，更不可能有翻译图书的想法。
为了让我能够安心地翻译，家里的领导承担了洗衣、做饭、扫地（以及数钱）等繁琐的家务。对一些难以理解的字句，她也和我一起讨论。作为一个非球迷，她还陪我熬夜观看了好多场世界杯比赛，大大减轻了我因为拖延翻译而产生的负罪感。图灵公司的李松峰和李静两位老师，对我翻译这本书给予了极大的肯定和支持，并且纵容了我逾期未完工的行为。这本书也有他们的一份付出。
2014年10月于上海
初识软件架构
我是从一个小互联网公司走出来的野生程序员。小公司里没有很细的分工，程序员必须像万金油，什么都会一点。数据怎么分表，后端接口怎么分，URL结构怎么定，前后端怎么接，这些都得搞定。事情多了，必须想清楚。
我在盛大创新院做的最后一个项目是一个iOS垂直社交应用。两个同事合作开发iOS客户端，而我在这个项目里的工作是开发一个REST架构的数据服务。需求很简单，就是根据客户端的应用场景编写一整套API。当第一个里程碑的所有工作完成之后，我发现需求开发只占用了一小部分时间，而设计关系型数据库的结构，设计认证、授权和报告，设计应用签名和令牌，设计REST风格的URL结构，开发API调试工具，编写API文档，这些事情却耗费了大量的时间。我就想，花了这么多时间做这些事情，并没有增加任何功能，又感觉不能不做，这到底是为什么？对这个问题的思考和学习，应该算是我对软件架构的入门。
怎么会翻译这本书
两年前我进入IBM，参与的项目是一个适用于大型数据中心的存储资源管理工具。这个工具的规模和复杂程度远远超出大多数面向普通用户的互联网应用，自然对架构的要求更为严苛。而IBM作为一家传统软件企业，深厚的技术积累也令我大开眼界，给了我很多学习和思考软件架构的机会和资源。
我们项目的架构师会贡献代码，会参加代码评审/回顾；我们有预先架构设计，也有架构演化；我们执行SCRUM方法；任何人对设计有意见，都可以给架构师发邮件，只要有理有据，就能说服他更改设计。在此之前我从未见过这样奇特的组合。很快适应了以后，我又想，这么好的方式，居然只有我们在用？直到今年三月，在微博上看到图灵的李松峰老师为Software Architecture for Developers一书征召译者。读过样章后才发现，我们就是作者理想中的团队啊！既然如此，何不尝试翻译这本书？
架构离我们并不遥远
写给程序员的软件架构，这是一个很有趣的出发点。长久以来，架构师在程序员群体中声名狼藉，软件架构被很多人认为是一项脱离现实、高高在上的工作。其实对程序员来说，架构近在眼前！下至接口设计，上至技术选型，不论你是否意识到，每个程序员或多或少都接触和参与过一些架构工作。架构师也自然而然成为相当一部分程序员的职业发展方向：你看，我们努力想要成为自己咒骂的人。
本书的作者是一位经验丰富的架构师。他从最简单的基本概念入手，对软件架构进行了层层深入的细致讲解，结合自己的实践经验，总结出很多实用的准则和方法，并且附上一个完整的开源项目来对这些内容加以佐证，帮助读者学习和理解。翻译这本书，在我看来更是对软件架构的一次系统学习，不仅丰富了我对软件架构的理解，更改变了我对架构师这个角色的一些固有印象。这本书令我获益匪浅，希望更多有志成为架构师的程序员朋友也能从中有所收获。
周爱民老师的序
十一假期结束后打开邮箱，收到图灵的李静老师的邮件，得知周爱民老师会为这本书撰写推荐序。惊喜，因为爱民老师是包括我在内的很多人敬仰的资深前辈。惶恐，因为我在软件架构方面还是个菜鸟，写作能力更与爱民老师相去甚远。
要来爱民老师的文章一读，“然后忘掉”，写得真好！我从未受过任何计算机科学或软件工程的专业训练，大学所学的化学专业也跟计算机毫无关联。因此，去看去听去做，并且牢牢记住，使我得以在这个行业一步步走到今天。自从对软件架构产生兴趣，也是如此逐渐学到很多概念、方法。虽然清楚架构必有权衡，不能十全十美，然而了解的知识越多，就更想面面俱到，反而放不开。殊不知，牢牢记住，也给自己画地为牢，陷入爱民老师所说的困局。
如果说这本书帮我画了一个更大的圈，那么爱民老师的文字则告诫我要跳出这个圈。我面前的架构之路还很长，不知何时能走出圈外，走到爱民老师今日所处之地。
谢谢你们
这本书的翻译能够完成，我最想感谢的人是成都七中的高中语文老师王正可。王老师是我近20年学生生涯中最重要的一位老师：她是第一个让我对语文产生兴趣的人。王老师教给我文字的艺术，帮助我找到阅读和写作的乐趣，对我而言这是一笔巨大的财富。如果不曾有幸成为她的学生，我想我不会养成写作的习惯，更不可能有翻译图书的想法。
为了让我能够安心地翻译，家里的领导承担了洗衣、做饭、扫地（以及数钱）等繁琐的家务。对一些难以理解的字句，她也和我一起讨论。作为一个非球迷，她还陪我熬夜观看了好多场世界杯比赛，大大减轻了我因为拖延翻译而产生的负罪感。图灵公司的李松峰和李静两位老师，对我翻译这本书给予了极大的肯定和支持，并且纵容了我逾期未完工的行为。这本书也有他们的一份付出。
2014年10月于上海
序言
信息技术行业不是大步前行，就是剧烈动荡。一方面，我们奋力前行，重新发明软件构建方式，时时处处精益求精。而另一方面，我们不断遗忘过去的好处，软件开发团队常意想不到地把事情搞砸。
软件架构在一个成功的软件交付中扮演关键角色，然而令人沮丧的是，很多团队都忽视了这一点。即使在最敏捷的团队中，软件构架这一角色也都是必需的，不管是由一个人还是整个团队共同扮演，但要寻求到预先和演化两种构架理念的平衡，往往还只是人们美好的意愿而并没有变为现实。
软件架构的坏名声
当我介绍自己是软件架构师时，对方通常会有两种反应。要么觉得这非常酷，想了解更多；要么就是露出不屑的神情，意思是说“我想跟实际开发软件的人聊，而不是跟只会画框框线线的指挥家聊”。软件架构的角色在IT行业中名声很差，出现这种想法自然不难理解。
“软件架构”给人的印象通常是架构师闭门造车，提前做好大型预先设计，然后好像接力赛跑时传递交接棒一样，把庞大的UML（Unified Modeling Language，统一建模语言）模型或200页Word文档丢给毫不知情的开发团队。当然，这是假设架构师实际参与了软件设计。似乎很多人都认为，只要做一个PPT，而且幻灯片中有一页出现了“企业服务总线”框线图，就算是做完了软件设计。哦，千万别忘了，这个PPT里毫无疑问也少不了对ROI（Return on Investment，投资回报）和TCO（Total Cost of Ownership，总体拥有成本）的陈述。
很多组织对软件开发普遍都有一个有意思的看法。比如，他们看到了离岸外包可以节省成本，因而把软件开发流程中的编码工作也看作一种可以买卖的商品。其结果往往是本地开发者被推向所谓“高价值”的软件架构职位，而编码则交由其他人完成。多数情况下这只会让软件架构和开发更加脱节，还常常让人像赶鸭子上架一样不得不去承担架构工作。这些组织也常倾向于把架构师看作一种职位级别而非工作角色。
敏捷愿景
“敏捷”已经出现了差不多十年，但它仍是“外来的时髦小子”。很多软件团队都有“实现敏捷”的愿景。毫无疑问，敏捷有很多好处，人们都想让你相信它是灵丹妙药，但事实并非如此。IT行业的每件事，都伴随着铺天盖地的宣传和天花乱坠的炒作。如今，开始一个新的软件项目，总能听到自组织的团队、自动化验收测试、持续交付、回顾、看板、浮现式设计，还有一大堆你可能都没听过的新名词。这很奇葩，但团队往往急于赶时髦，就将原来的东西不分好坏一起丢掉。“非功能需求”听起来虽然不酷，但这并不是你能忽视它们的理由。
这堆老古董软件架构的东西都是什么？很多软件团队似乎认为他们不需要软件架构师，张口闭口都是“自组织团队”、“YAGNI”（You Aren’t Going to Need It，你不会需要它）、“演化架构”和“最后责任时刻”这些词。如果他们确实需要架构师，也许会去找个“敏捷架构师”。我不完全确定这些词都是什么意思，但我猜它有点像用便利贴替代UML，或用TDD（Test-Driven Development，测试驱动开发）替代画图。也就是说，假设他们已经不是只使用高层次系统隐喻的概念，而且也不把“浮现式设计”作为盲目乐观的借口。
那么你觉得自己是架构师吗
看起来这个行业里有很多人自称是软件架构师，而他们实际上完全在做别的事。我能够原谅那些在大企业里实践软件架构，却误以为自己是“企业架构师”的人。总之我们这行的术语就是经常把人搞糊涂。
但那些夸大自己在软件团队里作用的人又如何呢？这些不负责任的架构师通常担任技术领导，却连基本能力都不够格。我见过一些面向公众的网站在进入用户验收测试环境时，还有一堆安全问题，没有基本性能测试，常用功能也有问题，死链，并且完全没有文档。这只是我能看到的软件外在的问题，天知道代码会是什么样子！如果你承担了软件架构的角色，最后却交付这样的东西，你做得就不对。这不是什么软件架构，这也只能算是盲目乐观。
失意的架构师
必须承认，不是所有软件团队都像这样，但我前面讲的也不是空穴来风。糟糕的是很多组织确实就是这样干的，因此软件架构有这样的名声并不奇怪。
想在这个行业里有所作为，就需要克制对新鲜玩意的迷恋，开始问一些问题。敏捷需要架构吗，或者架构真的需要敏捷吗？相比近些年学到的东西，我们是不是忘掉了更多好的软件设计方法？对于我们现在构建的软件系统，只有盲目乐观就够了吗？如果我们不是从培养未来软件架构师的角度考虑，这些问题还有意义吗？我们要如何从失意走向平和？
推荐序一：架构师真正要学会的事情
1. 要学会去看，然后忘掉
有一本书叫《观止》，写的是微软研发Windows NT的一段故事。“观止”在这里的意思是说“看到这些，就无需再看了”，因为世上之物亦无过于此。20多年过去，如今微软在操作系统上面临着的种种挑战与困境，其实与《观止》所叙的研发方法、理念与目标有着与生俱来的血缘关系。
另一个与“看”相关的词汇是“所见即可得”（WYSIWYG）。这个词以及与此相关的WIMP（Windows, Icon, Menu and Pointer）曾经主导了整个人机交互的设计理念。也是在20多年前，Borland为Windows桌面系统成功地设计了跨语言的VCL，由此“所见即所得”成为Borland对“如何更便捷地构建UI”的基本假想，以至于这家伟大的公司在互联网时代来临时决定“用VCL描述界面的方式来解决‘网站设计’的问题（RadPHP）”。
然而，互联网上的网页是没有WIMP的；移动设备上的操作系统也不再采用与Windows NT类似的方式开发。
软件架构在一个成功的软件交付中扮演关键角色，然而令人沮丧的是，很多团队都忽视了这一点。即使在最敏捷的团队中，软件构架这一角色也都是必需的，不管是由一个人还是整个团队共同扮演，但要寻求到预先和演化两种构架理念的平衡，往往还只是人们美好的意愿而并没有变为现实。
软件架构的坏名声
当我介绍自己是软件架构师时，对方通常会有两种反应。要么觉得这非常酷，想了解更多；要么就是露出不屑的神情，意思是说“我想跟实际开发软件的人聊，而不是跟只会画框框线线的指挥家聊”。软件架构的角色在IT行业中名声很差，出现这种想法自然不难理解。
“软件架构”给人的印象通常是架构师闭门造车，提前做好大型预先设计，然后好像接力赛跑时传递交接棒一样，把庞大的UML（Unified Modeling Language，统一建模语言）模型或200页Word文档丢给毫不知情的开发团队。当然，这是假设架构师实际参与了软件设计。似乎很多人都认为，只要做一个PPT，而且幻灯片中有一页出现了“企业服务总线”框线图，就算是做完了软件设计。哦，千万别忘了，这个PPT里毫无疑问也少不了对ROI（Return on Investment，投资回报）和TCO（Total Cost of Ownership，总体拥有成本）的陈述。
很多组织对软件开发普遍都有一个有意思的看法。比如，他们看到了离岸外包可以节省成本，因而把软件开发流程中的编码工作也看作一种可以买卖的商品。其结果往往是本地开发者被推向所谓“高价值”的软件架构职位，而编码则交由其他人完成。多数情况下这只会让软件架构和开发更加脱节，还常常让人像赶鸭子上架一样不得不去承担架构工作。这些组织也常倾向于把架构师看作一种职位级别而非工作角色。
敏捷愿景
“敏捷”已经出现了差不多十年，但它仍是“外来的时髦小子”。很多软件团队都有“实现敏捷”的愿景。毫无疑问，敏捷有很多好处，人们都想让你相信它是灵丹妙药，但事实并非如此。IT行业的每件事，都伴随着铺天盖地的宣传和天花乱坠的炒作。如今，开始一个新的软件项目，总能听到自组织的团队、自动化验收测试、持续交付、回顾、看板、浮现式设计，还有一大堆你可能都没听过的新名词。这很奇葩，但团队往往急于赶时髦，就将原来的东西不分好坏一起丢掉。“非功能需求”听起来虽然不酷，但这并不是你能忽视它们的理由。
这堆老古董软件架构的东西都是什么？很多软件团队似乎认为他们不需要软件架构师，张口闭口都是“自组织团队”、“YAGNI”（You Aren’t Going to Need It，你不会需要它）、“演化架构”和“最后责任时刻”这些词。如果他们确实需要架构师，也许会去找个“敏捷架构师”。我不完全确定这些词都是什么意思，但我猜它有点像用便利贴替代UML，或用TDD（Test-Driven Development，测试驱动开发）替代画图。也就是说，假设他们已经不是只使用高层次系统隐喻的概念，而且也不把“浮现式设计”作为盲目乐观的借口。
那么你觉得自己是架构师吗
看起来这个行业里有很多人自称是软件架构师，而他们实际上完全在做别的事。我能够原谅那些在大企业里实践软件架构，却误以为自己是“企业架构师”的人。总之我们这行的术语就是经常把人搞糊涂。
但那些夸大自己在软件团队里作用的人又如何呢？这些不负责任的架构师通常担任技术领导，却连基本能力都不够格。我见过一些面向公众的网站在进入用户验收测试环境时，还有一堆安全问题，没有基本性能测试，常用功能也有问题，死链，并且完全没有文档。这只是我能看到的软件外在的问题，天知道代码会是什么样子！如果你承担了软件架构的角色，最后却交付这样的东西，你做得就不对。这不是什么软件架构，这也只能算是盲目乐观。
失意的架构师
必须承认，不是所有软件团队都像这样，但我前面讲的也不是空穴来风。糟糕的是很多组织确实就是这样干的，因此软件架构有这样的名声并不奇怪。
想在这个行业里有所作为，就需要克制对新鲜玩意的迷恋，开始问一些问题。敏捷需要架构吗，或者架构真的需要敏捷吗？相比近些年学到的东西，我们是不是忘掉了更多好的软件设计方法？对于我们现在构建的软件系统，只有盲目乐观就够了吗？如果我们不是从培养未来软件架构师的角度考虑，这些问题还有意义吗？我们要如何从失意走向平和？
推荐序一：架构师真正要学会的事情
1. 要学会去看，然后忘掉
有一本书叫《观止》，写的是微软研发Windows NT的一段故事。“观止”在这里的意思是说“看到这些，就无需再看了”，因为世上之物亦无过于此。20多年过去，如今微软在操作系统上面临着的种种挑战与困境，其实与《观止》所叙的研发方法、理念与目标有着与生俱来的血缘关系。
另一个与“看”相关的词汇是“所见即可得”（WYSIWYG）。这个词以及与此相关的WIMP（Windows, Icon, Menu and Pointer）曾经主导了整个人机交互的设计理念。也是在20多年前，Borland为Windows桌面系统成功地设计了跨语言的VCL，由此“所见即所得”成为Borland对“如何更便捷地构建UI”的基本假想，以至于这家伟大的公司在互联网时代来临时决定“用VCL描述界面的方式来解决‘网站设计’的问题（RadPHP）”。
然而，互联网上的网页是没有WIMP的；移动设备上的操作系统也不再采用与Windows NT类似的方式开发。
媒体评论
“这是一本‘指南’型图书。作者会给你一个图景以及达到它的关键技术指引，你可以得到一个思考问题的框架，而非一条道路或一套方法。但对于架构师来说，这样就足够了。”
——周爱民，现任豌豆荚架构师，前盛大网络平台架构师、支付宝业务架构师
——周爱民，现任豌豆荚架构师，前盛大网络平台架构师、支付宝业务架构师
