健壮、优雅、灵活和易维护的软件架构是怎样炼成的?《架构之美》通过一系列优秀的文章回答了这个问题,这些文章来自于十几位当今一流的软件设计师和架构师。在每篇文章中,作者都向们展示了一个著名的软件架构,并分析了什么让其具有创新性,让其极其符合设计目标。
《架构之美》内容包括:
Facebook的架构如何建立在以数据为中心的应用生态系统之上。
Xen的创新架构对操作系统未来的影响。
KDE项目的社区过程如何让软件的架构从粗略的草图演进为漂亮的系统。
不断滋长的特征如何让GNUEmacs获得从未预料到的功能。
JikesRVM自优化、自足执行的运行时环境背后的魔法。
海报:
《架构之美》围绕5个主题领域来组织《架构之美》的内容:概述、企业应用、系统、终用户应用和编程语言。《架构之美》让优秀的设计师和架构师来描述他们选择的软件架构,剥开架构的各层,展示他们如何让软件做到实现功能、可靠、易用、高效率、可维护、可移植和优雅。
王海鹏,1994年毕业于华东师范大学。拥有理学士(物理)和文学士(英国语言文学)学位。独立的咨询顾问、培训讲师、译者和软件开发者。已翻译十余本软件开发书籍,主题涵盖敏捷方法学、需求工程、 UML 建模和测试。拥有15年软件开发经验,目前主要的研究领域是软件架构和方法学,致力于提高软件开发的品质和效率。
序
前言
第一部分 论架构
第1章 什么是架构
1.1 简介
1.2 创建软件架构
1.3 架构结构
1.4 好的架构
1.5 美丽的架构
1.6 致谢
1.7 参考文献
第2章 两个系统的故事:现代软件神话
2.1 混乱大都市
2.2 设计之城
2.3 说明什么问题
2.4 轮到您了
2.5 参考文献
第二部分 企业级应用架构
第3章 伸缩性架构设计
3.1 简介
3.2 背景
3.3 架构
3.4 关于架构的思考
第4章 记忆留存
4.1 功能和约束
4.2 工作流
4.3 架构关注点
4.4 用户反应
4.5 结论
第5章 面向资源的架构:在Web中
5.1 简介
5.2 传统的Web服务
5.3 Web
5.4 面向资源的架构
5.5 数据驱动的应用
5.6 应用面向资源的架构
5.7 结论
第6章 数据增长:Facebook平台的架构
6.1 简介
6.2 创建一个社会关系Web服务
6.3 创建社会关系数据查询服务
6.4 创建一个社会关系Web门户:FBML
6.5 系统的支持功能
6.6 总结
第三部分 系统架构
第7章 Xen和虚拟化之美
7.1 简介
7.2 Xenoservers
7.3 虚拟化的挑战
7.4 半虚拟化
7.5 Xen的变换形式
7.6 改变的硬件,改变的Xen
7.7 经验教训
7.8 延伸阅读
第8章 Guardian:一个容错操作系统环境
8.1 Tandem/16,将来所有的计算机都会像这样构建
8.2 硬件
8.3 机械布局
8.4 处理器架构
8.5 处理器间总线
8.6 输入/输出
8.7 进程结构
8.8 消息系统
8.9 文件系统
8.10 民间传说
8.11 弊端
8.12 后继者
8.13 延伸阅读
第9章 JPC:一个纯Java的x86PC模拟程序
9.1 简介
9.2 概念验证
9.3 PC架构
9.4 Java性能技巧
9.5 把4GB放入4GB:这不起作用
9.6 保护模式的危险
9.7 从事一项毫无成功希望的斗争
9.8 劫持JVM
9.9 最终灵活性
9.10 最佳安全性
9.11 第二次做会更好
第10章 元循环虚拟机的力量:JikesRVM
10.1 背景
10.2 与运行时环境相关的传言
10.3 JikesRVM简史
10.4 一个自足执行的运行时自举
10.5 运行时组件
10.6 经验教训
参考文献
第四部分 最终用户应用架构
第11章 GNUEmacs:滋长的特性是其优势
11.1 使用中的Emacs
11.2 Emacs的架构
11.3 滋长的特性
11.4 另外两个架构
第12章 当集市开始构建教堂
12.1 简介
12.2 KDE项目的历史和组织结构
12.3 Akonadi
12.4 ThreadWeaver
第五部分 语言与架构
第13章 软件架构:面向对象与面向功能
13.1 概述
13.2 示例
13.3 面向功能解决方案的模块性评价
13.4 面向对象视图
13.5 面向对象模块性的评价和改进
13.6 代理:将操作封装到对象中
致谢
参考文献
第14章 重读经典
14.1 所有东西都是对象
14.2 类型是隐式定义的
14.3 问题
14.4 砖块和灰浆建筑架构
参考文献
跋
第一部分 论架构
第1章 什么是架构
1.5 美丽的架构
所有前面的方法都有助于我们判断一个架构是否“足够好”——也就是说,是否有可能指导开发者和测试者构建一个系统,并满足系统的利益相关人的功能和质量关注点。在我们每天使用的系统中存在着许多好的架构。
但是,超越足够好的架构是怎样的呢?如果有一个“软件架构名人堂”,那会怎样?哪些架构会陈列在这个艺术馆的墙上?这个想法可能没有你想象的那么遥远——在软件产品线领域,这样的“名人堂”的确存在。(注1)进入“软件产品线名人堂”的条件包括获得商业上的成功、影响其他产品线的架构(其他产品线可能“借用、复制、窃取”这个架构)、拥有足够的文档从而让其他人“不必通过道听途说”就能够理解该架构。
我们将为更一般的“架构名人堂”或“美丽架构艺术馆”的候选者设立怎样的条件呢?
首先我们应该认识到,这是一个软件系统的艺术馆,而不是其他艺术馆,我们的系统构建的目的是为了使用。所以,我们也许从一开始就应该关注该架构的实用性:它应该每天被许多人使用。
但是,在使用架构之前,它必须先构建,所以我们应该关注该架构的可构建性。我们会寻找那些具有定义良好的使用结构的架构,它们支持增量式构建,这样,通过每次构建迭代我们都能得到一个有用的、可测试的系统。我们也会寻找那些具有定义良好的模块接口、本来就很好测试的架构,这样,构建的过程就是透明的、可见的。
接来下,我们想寻找那些展示了持久性的架构——也就是说,那些经过了时间考验的架构。我们生活在一个技术环境以从未有过的加速度变化的年代。美丽的架构应该预期到变更的需要,允许期望的修改能够容易而有效地进行。我们想寻找那些避免了“衰老地平线”(Klein 2005)的架构,超过了这条“衰老地平线”,维护将变得代价极大,以至于不可能进行。
······
从编辑手里拿到厚厚的《架构之美》译稿时,恰巧是我刚刚讲完一场消息系统架构的讲座之后。而正是在昨天,一位想要创业的朋友跟我说要寻找一位懂得“架构”的高人与他一起创业。要知道与代码不同的是,“虚幻”的架构常常让人认为其有很多玄妙之处,只因它大多难以落在纸上。特别是与很多大师谈及架构时,经常落入他们的一些“陷阱”,并往往为自己达不到大师的精明与技巧而叹息。殊不知,被我们所津津乐道的这些架构,是他们在日常工作里经历了大量的错误、重复的尝试、无数的代码、长久的考验所积淀下来的只言片语。本书将数十人的经历与只言片语,经过深思熟虑后抽象出规律,使之可以不断复用。而另一方面,又将架构的过程娓娓道来,尝试让读者思考架构的过程与思路。在这里,更多的过程与思考被展现出来,更多的原因与为什么让我们了解。这本书里展现了很多绚丽的故事,犹如士兵阅读将军的传记一样,阅读本书将会让你更鼓起勇气追寻大师们的脚步,但永远要记住,每一滴汗水才真正是你成长路上的每一个记号,要在自己的工作里更深地去理解每一处不同,架构出属于自己的系统。感谢译者和出版者为我们带来这样一本传奇的架构故事书。
《架构之美》这本书,用一种非常诗意的方式,解读了软件架构的本质。我尤其喜欢它对“一致性”的探讨,不仅仅是代码层面的统一,更是设计理念和工程实践上的协调一致。作者通过生动的故事和巧妙的比喻,阐述了在一个庞大的系统中,如何通过建立一套清晰的设计原则和规范,来确保整个系统的和谐统一。这让我想起我们团队在一些大型项目中遇到的瓶颈,很多时候都是因为大家对“什么是好的设计”没有一个共同的理解,导致项目在推进过程中出现很多不协调的现象。这本书则提供了一个很好的参照系,它告诉我们,架构不仅仅是技术堆砌,更是一种思想的统一和价值的体现。它还深入地探讨了“可读性”在架构设计中的重要性,指出一个良好的架构,应该能够让后来者快速地理解其设计思路和工作原理。这对于长期的项目维护和团队协作至关重要。总而言之,这本书给我的感觉是一种“润物细无声”的启迪,它没有直接给出具体的解决方案,而是引导我去思考更深层次的问题,从而在实践中形成自己的洞察和判断,最终构建出真正“美”的架构。
评分不得不说,《架构之美》这本书的视角非常独特,它并没有停留在技术细节的层面,而是将目光投向了更宏观的“架构哲学”。我尤其欣赏它在讨论“演进式架构”时所展现出的前瞻性。很多时候,我们在规划一个新系统的时候,总是希望一步到位,设计出尽善尽美的方案。然而,现实往往是技术在不断变化,业务需求也在不断调整,当初的设计很可能在短时间内就显得力不从心。这本书则提倡一种更加务实的态度,即承认不确定性,并设计出能够适应变化的架构。它通过一系列的论证,让我意识到,架构的生命周期和软件本身的生命周期一样,都是一个不断演进的过程。关键在于如何让这种演进是可控的、有序的,而不是混乱的。书中对于“权衡”的讨论也让我受益匪浅,很多时候,最优解并非绝对的最优,而是在特定约束条件下的最佳选择。这要求我们在做决策时,不能一味地追求技术上的完美,而要充分考虑成本、时间和资源等因素。总而言之,这本书帮助我打破了一些固有的思维定势,让我能够更加灵活地看待软件架构的设计与发展。
评分读完《架构之美》,我感觉自己仿佛经历了一场思维的洗礼。这本书最让我印象深刻的是它对于“简洁性”的推崇。在如今这个追求“炫技”和“复杂”的环境下,能够沉下心来谈论简洁,本身就是一种难得的品质。作者通过大量的实例,阐述了如何通过精炼的设计,去除不必要的复杂性,从而让系统更加易于理解、易于维护。我记得其中有一个章节,专门讨论了“过度设计”的危害,这让我深有同感。很多时候,我们为了应对所谓的“未来可能的需求”,而引入了过多的抽象和设计模式,结果却让系统变得臃肿不堪,维护成本飙升。这本书则告诉我们,有时候最简单的解决方案,往往是最有效的。它鼓励我们在设计初期,就聚焦于核心需求,并用最直接、最简洁的方式去实现。此外,书中对于“可测试性”的强调也让我受益匪浅。一个好的架构,必然是容易进行自动化测试的,这不仅能够保证系统的质量,还能够极大地提高开发效率。这本书的价值在于,它不仅仅提供了一些方法论,更重要的是,它培养了一种“道”的境界,让读者在实践中能够不断地去追求更深层次的理解和更优雅的设计。
评分我最近刚翻完《架构之美》,说实话,这本书确实给了我不少启发,尤其是关于如何平衡创新与稳定性这一点。在实际工作中,我们经常会遇到各种各样的技术难题,有时候为了追求最新的技术和最酷炫的功能,会忽略掉一些潜在的风险,导致系统变得越来越不稳定。这本书通过一些生动的案例,深入浅出地讲解了如何在一开始就构建出既有前瞻性又足够稳健的架构。我特别喜欢它在探讨“技术债务”时提到的观点,不再是简单地将其视为一个负面词汇,而是将其看作是一种权衡,一种在特定时间点为了快速迭代而不得不做出的选择,关键在于如何有效地管理它,而不是放任自流。书中也强调了沟通的重要性,很多时候架构的失败并非技术本身的问题,而是团队成员之间缺乏有效的沟通和共识,导致各自为政,最终让整个系统变得混乱不堪。读完之后,我开始反思我们团队在架构设计过程中的一些习惯,并且尝试在下一次的项目中引入一些新的思考方式,希望能够避免重蹈覆辙。这本书的内容对我来说,更多的是一种思维模式的引导,让我能够从更宏观、更长远的视角去看待软件的构建过程,而不仅仅是关注眼前的代码实现。
评分《架构之美》这本书,我断断续续读了一段时间,每次都能从中汲取到一些新的养分。它给我最深刻的感受是,真正的“美”并非来自于华丽的辞藻或者复杂的技巧,而是源于内敛的智慧和深厚的功底。作者在书中阐述的许多设计原则,看似简单,但背后却蕴含着对工程实践的深刻理解。比如,关于“模块化”的论述,不仅仅是简单地将大系统拆分成小组件,更重要的是如何去定义这些模块的边界,以及如何有效地管理它们之间的依赖关系。这让我联想到我们日常工作中经常遇到的“牵一发而动全身”的尴尬局面,很多时候就是因为模块划分不清,或者模块间的耦合度过高导致的。书中提出的“解耦”策略,提供了很多行之有效的思路,让我对如何构建可维护、可扩展的系统有了更清晰的认识。此外,它还触及到了“非功能性需求”的重要性,这一点在很多技术书籍中往往会被忽略,但实际上,一个好的架构必须能够同时满足性能、安全、可用性等多个维度的要求。我个人认为,这本书最大的价值在于,它能够帮助读者建立起一套系统性的思维框架,从而在面对复杂的技术挑战时,能够更加游刃有余。
评分刚看了一部分,书不错
评分货物收到6天,电子发票都没出来,严重耽误报销。
评分这本书非常好,值得大家购买,物流非常快。
评分从封面和印刷质量看,和一般的盗版书没有什么两样。
评分书感很不错,买了就好好看
评分可以
评分书写的不错,提供的很多的知识点!
评分挺好的一本书,对架构有了新的认知
评分看看好的架构是什么样,学习学习。
本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度,google,bing,sogou 等
© 2025 book.cndgn.com All Rights Reserved. 新城书站 版权所有