本文引用了温柔运动鞋老师[就职于南潮(Ruff )，现任修订人]在《程序员必读之软件架构》年写的书的推荐顺序。
编辑：软件设计师是在软件项目开发过程中，将客户需求转化为规范的开发计划和文本，制定项目总体框架，指导开发团队完成该计划的人。 软件设计师主导系统的全局分析设计与实现以及关键技术决策。 体系结构的作用应该是对思维和技术的双重挑战，也是所有开发者的终极目标。 我希望这篇文章对我想成为、想成为或已经成为修订者的朋友有帮助。
1 .学会去看，忘记
有一本书叫《观止》，是微软开发Windows NT的故事。 “观止”的意思是“看了这个，就没必要再看了”。 因为世上的东西也没有比这更好的了。 20多年来，微软在操作系统中面临的种种挑战和困境，其实与《观止》所述的研发方法、理念和目标有着天生的血缘关系。
与“看”相关的另一个词是“一看就得到”(WYSIWYG )。 这句话及其相关的wimp(windows，Icon，Menu and Pointer )曾经主导了整个人机交互的设计理念。 20多年前，Borland成功地为Windows桌面系统设计了跨语言的VCL，从而使“所见即所得”成为Borland对“如何更轻松地构建UI”的基本虚拟，这家伟大的公司成为了互联网
但是，internet页面上没有WIMP，移动设备上的操作系统也不再以与Windows NT相同的方式开发。
Borland几年前卖掉了整个开发工具产品线。 当时盛大的Delphi社团发起了“怀念活动”，主办方说“爱人民，应该为那个时代写点什么吧”。
我在那个缅怀的页面上写了五个字。 看起来很碍事。
2 .学会去听，忘记
我通常认为框架是能力，框架的作用是要求你在特定的事务中采取特定的行为，而架构师是识别这些能力和行为的职责。
如果某人将个人发展定义为“职业发展”，则表现为“如何成为架构师”的问题。
这有三种解决办法。 第一种是打印写有这样头衔的名片，“是”和“否”架构师并不重要。
二是直接否定这个职务的意义。 例如，如果声称敏捷是天生的反体系结构，那么“架构师”将成为目标，因此是否成为该目标也不重要。
第三，既然断言“每个人都是架构师”，每个人都是这样，那么“会怎么样”当然也不重要。
我们大多数人都有体系结构的能力，或多或少都有扮演一些体系结构角色的行为。 唯一缺少的只是“架构师”的头衔。 问题是，我们总是期待别人用这样的头衔承认自己。 于是我们为自己贴上这样那样的标签，对照别人拥有的同样的标签，寻求一致，找出某种不同。 我们在那里听到了各种各样的声音。 有人真的/不是，像个修订者/不是； 架构师的话，这样那样，该怎么办呢？ 其实这个框架，这样的框架，或者某种框架应该怎么办； 还有什么是体系结构，什么是架构师，等等。 回顾“三个解决方案”，还是被困在这种承认欲望中，进行着各种各样的斗争。
其实不仅你的看到阻碍了你自己，你还被别人的看到阻碍了。
3 .等你学会了再忘
朋友给我讲了我和他家两岁的孩子的故事。 我刚收拾好桌子，一眨眼的工夫，杯子、筷子等都掉了。 我说：“怎么了？ ”他说，“孩子什么都不知道。 看着桌布以为喜欢，抓住他……”
孩子们看不见桌上有杯子，正因为他们的视线里没有杯子，他们的行动简单直接，直奔需求，快捷。 我们眼中有杯子、桌子、桌布等一切，我们多年来一直保持着其中的顺序和关系，直到这些东西融为一体，然后我们每天坐在它们面前，感觉不到他们的存在。
我们自己无意识地设定了这些东西的界线，这些界限、层次、逻辑上有条理的东西被称为“系统”。 我们从那个无序的东西中认识到这样的“系统”，用一些概念、名词定义了它们之后，我们的知识也全部固化了。 这个秩序建立后，我们可以识别和肯定秩序和无序((你设定的“这个秩序”没有) ) )的价值。 我们设定了各种价值、观念、观察和系统的模型概念后，该系统的框架也完成了。
但是，这个过程包括可以完成这个框架——并命名为“世界观”——的方法和结果，本质上只是从一个网格跳到另一个网格。 我们身处各种边界之中，再也不能回到两岁孩子的，所有不碍事的观点了。 从那个角度看，没有边界线。 你总是想跨越国界，其实是假设你“有界线”。 这和完全堆栈的意思其实是“没有堆栈”类似。 而且，当有人自信地想成为全栈的工程师时，在他眼里又存在着“这个栈”。
跨界不是你能力和方法的变化，你的行为取决于你的结构，你的结构取决于你的看法。
4 .学会超越
架构师必须超越自己和他人的眼睛。 为什么这么说，是因为观察和体系结构的对象被称为“系统”。 看到系统的多少真相决定了用什么样的影像来表现它，也决定了该影像，也就是体系结构的推进和实现。 我们已经知道、理解、理解，形成了我们所有的知识和行为，但这也阻碍了我们前进。
这些障碍是你认为最珍惜的，最
不可放弃的、最鲜血淅沥体验过的那些经验与成就。在这些所得与所碍中挣扎与决策，就是架构师的全部职责。因此作为架构师，你需要能够超越自已对系统的既有认识，看到你在光明中——显而易见之处——所未见的，这是你驱动系统架构进化的主要动力。所以架构中最难超越的并不是某个大师或前辈，而是你以及你为自己所作的设定。朴素的花瓣设定了“架构师”这个目标，便设定了这个目标所表达的某种影像(角色)，你最终可能变得跟这个影像完全一致——成为所谓的“真正的架构师”，但你仍不过是困囿于对这个“角色”的一个假设/设定而已。唯一破局的方法是：超越别人对某个角色的定义，将自己做成这个角色。
至此，你是否还在这个角色之中，就是你的觉悟了。
《程序员必读之软件架构》是一本强调实践、注重实效、轻量级、面向开发者的软件架构指南。如果你是一名想成为软件架构师的程序员，那么《程序员必读之软件架构》就是你的不二之选。
作者Simon Brown 全球知名软件架构独立咨询师、讲师，创办了专门讨论软件架构问题的网站“编码架构”(http://codingthearchitecture.com)。他自称是写代码的软件架构师和明白架构的软件开发者。自2008年以来的7年时间里，Simon在全球28个国家做过有关软件架构、技术领导力及其与敏捷的平衡等主题的百余场演讲，并于2012年8月在中国举办的ArchSummit全球架构师峰会上以“郁闷的架构师”和“如何设计安全的架构”为主题发表演讲，深受与会者好评。Simon已为全球20多个国家的软件团队提供咨询和培训，他的客户既有小型技术初创企业，也不乏全球家喻户晓的品牌公司。《程序员必读之软件架构》 作者：[美]Simon Brown，译者：hldhh
目 录
推荐序一：架构师真正要学会的事情 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 Ⅷ 附录：“技术部落”的软件指南