编辑推荐
√ Bob 大叔倾情力作
√ 跨越半个世纪的极简架构经验
√ 显著提高开发人员生产率
【美】Robert C. Martin（罗伯特·C·马丁） 著
内容提要
通过合理运用软件架构的通用法则，可以显著提升开发者在所有软件系统全生命周期内的生产力。如今，传奇软件匠师Robert C. Martin（Bob 大叔），携畅销书Clean Code 与The CleanCoder 所获巨大成功之威，深刻揭示这些法则并亲授运用之道。Martin 在《Clean Architecture：软件架构与设计匠艺（英文版）》中远不只是在为我们提供选项，他几乎是在将软件世界中横跨半个世纪的各种架构类型的设计经验倾囊相授，目的是让读者既能阅尽所有架构选型，又可通晓其如何决定成败。Bob 大叔也的确不负厚望，《Clean Architecture：软件架构与设计匠艺（英文版）》中充满了直接而有效的解决方案，以供读者应对所面临的真正挑战——那些或最终成就或彻底破坏你项目的挑战。
作者简介
Robert C. Martin（Bob大叔）从1970年编程至今。他是cleancoders.com的联合创始人，该网站为软件开发者提供在线视频教育。同时，他还是Bob大叔咨询公司的创始人，该公司为全球大型公司提供软件开发咨询服务、培训以及技能培训服务。同时，他在 8th Light公司任“首席匠人”一职，该公司是位于芝加哥的一家软件开发咨询公司。本书作者在各种行业周刊上发表了十余篇文章，同时也经常被国际会议和行业峰会邀请进行演讲。他曾任C++ Report的主编，并且曾任敏捷联盟（Agile Aliance）的主席。
精彩导读
前言
软件架构（Architecture）究竟指的是什么呢？
正向比喻是一种修辞手法，试图用架构的语言来描述某个软件，结果可粗可细，可能会过度描述，也可能会表达不足。
用架构来描述软件的明显优势是可以清晰地描绘其内在的组织结构（structure）。不管是在讨论组件、类、函数、模块（module）、还是层级、服务、微观与宏观的软件开发过程，组织结构都是一个主要关注点。但是真实世界中的许多软件项目并不是按我们的信念和理解生长的——它们底层层层嵌套，顶层则往往是一团乱麻，相互纠缠。有的时候真的很难让人相信，软件项目的组织结构性也能像物理建筑那样一目了然，层次清晰。
物理建筑，不管地基是石头还是水泥，高大还是宽阔，宏伟还是渺小，其组织结构都一目了然。物理建筑的组织结构必须被“重力”这个自然规律以及建筑材料自身的物理特性所约束。用砖头、水泥、木头、钢铁或者玻璃造就的物理建筑与软件项目相比，最大的不同点就是，大型软件项目由软件组件构成，而这些软件组件又由更小的软件组件构成，层层嵌套。
当我们讨论软件架构时，尤其要注意软件项目是具有递归（recursive）和分形（fractal）特点的，最终都要由一行行的代码组成。脱离了一行行的代码，脱离了具体的细节（detail）设计，架构问题就无从谈起。大型物理建筑的组织架构常常是由其中一个个细节设计共同决定的，如果细节设计太多，那么组织架构就会更复杂，反之亦然。但是软件项目的复杂程度却不一定能用物理尺度来衡量。软件项目也有组织结构，不论从数量上还是种类多样性上都远远超过物理建筑。我们可以很明确地说，软件开发比修建物理建筑需要更多、更专注的设计过程，软件架构师比建筑架构师更懂架构！
虽然人类已经习惯了使用物理尺度来衡量和理解现实世界，但这些却不适用于软件项目。不管某个PowerPoint图表中的彩色方块多么好看、多么简单易懂，也无法完全代表一个软件的架构。它只能是某个软件架构的某种展现形式。软件架构并没有一个固定的展现形式，每一种展现形式都建立在背后的层层抉择之上，例如，哪些部分要包含其中，哪些则应该被排除；哪些部分用特殊形状和颜色进行强调，哪些部分则一笔带过，甚至直接忽略。每种表现形式都是对的，它们往往没有任何内在的联系。
虽然软件可能是人凭空编造出来的，但还是要在现实世界中运行。虽然在设计软件架构的过程中物理定律和物理尺度可能并不是主要考虑的对象，但我们还是要理解和遵循某些约束条件。CPU速度和网络带宽往往直接决定了系统的性能。内存和存储的大小限制也会影响代码的设计。
这就是爱的不幸，期待是无穷的，但行动却是有限的，欲望是无止境的，体验却如奴隶般受限。
——William Shakespeart
无论如何，我们和我们的公司，乃至于整个经济活动都存在于现实世界中，我们可以利用现实世界的一些准则来衡量和推理软件开发过程中那些不好量化和物化的因素。
软件架构是系统设计过程中所有重要设计决定的集合，其中每个设计决定的重要程度则通过变更成本来衡量。
——Grady Booch
时间、金钱以及努力是软件架构中区分规模大小的衡量标准，也是架构和细节的区分标准。通过对这些要素的衡量，我们可以判断某个特定架构是好或坏：一个好的架构，不仅要在某一特定时刻满足软件用户、开发者和所有者的需求，更需要在一段时间以内持续满足他们的后续要求。
如果你觉得好架构的成本太高，那你可以试试差的架构加上返工重来的成本。
——Brian Foote，Joseph Yoder
一个系统的常规变更需求成本不应该是昂贵的，也不应该伴随着难以决策的大型设计而调整，更不应该需要一个独立的项目来单独完成。这些常规变更应该可以归入每日或者每周的日常系统维护中去。
要解决这个问题，还有一个不小的物理难题：时间旅行。我们怎么能够知道某个系统未来的变更需求，以便提前做准备呢？我们怎么能在没有水晶球与时间旅行机的情况下，未卜先知，降低未来的变更成本呢？
所谓架构，就是你希望能在项目一开始就做对，但是却不一定能够做对的决策的集合。
——Ralph Johnson
了解历史已经够难了，我们对现实的掌握最多也只有七八成，预言未来就更加困难。
我们架构师们每天都站在这样拥有无穷选择的交叉路口。
其中一条比较黑暗的路线认为，只有威权和刚性才能带来强壮稳定的软件架构。如果某项变更成本太高，那么就忽视它——变更背后的需求要么被抑制，要么被丢到官僚主义的大机器中绞碎。架构师的决定是完整的、彻底极权的。软件架构就是全体开发人员的反乌托邦噩梦，永远是所有人沮丧的源泉。
而另外一条路线则充斥着大量投机性的通用设计。这会使软件项目中到处都是硬编码的猜测，无穷无尽的参数，或者成篇累牍的无效代码。维护这样的项目，常常遇到意外情况，预留多少资源都不够用。
本书试图探索的是一条极简优美的路线。这条路线认同软件的灵活多变性，并且保证这种灵活多变性仍是系统的一流属性。同时，我们也承认人类并不能全知全晓，但在信息不全的情况下人类仍然能够做出优良决策。这条路线可以使人类的优势发挥作用，而非劣势。通过实际创造和探索，我们提出问题进行实验。优秀的架构一定是要靠一个优良的体系不断打磨才能产生的，并不是一成不变的。
软件架构是一个猜想，只有通过实际部署和测量才能证实。
——Tom Gilb
遵循这条路线，我们需要用心、仔细观察，不停观察和思考，重视实践和原则。虽然这可能听起来很麻烦、很耗时，但是只有坚持走下去才能成功。
走得快的唯一方法，是先走好。
——Robert C. Martin
一起享受这个过程吧！
积跬步以至千里。每天读本书，为您搜罗最具权威专业书籍，更多图书推荐请关注每日读书。
好知识需要分享，如您有喜欢的书籍想与广大开发者分享，请在文章下方评论留言，我们将为大家推荐您的爱书！
