马丁的简介代码不仅仅是提供选项。在半个世纪的软件环境中,每一种可以想象的类型,马丁告诉你做出什么选择,以及为什么它们对你的成功至关重要。正如你所渴望的,这本书中充斥着直接的、不复杂的解决方案,你将面对那些能使你的项目成败的真正挑战。
通过应用软件体系结构的通用规则,在任何软件系统的整个生命周期中显著地提高开发人员的生产率。
前言
软件架构(Architecture)究竟指的是什么呢?
正向比喻是一种修辞手法,试图用架构的语言来描述某个软件,结果可粗可细,可能会过度描述,也可能会表达不足。
用架构来描述软件的明显优势是可以清晰地描绘其内在的组织结构(structure)。不管是在讨论组件、类、函数、模块(module)、还是层级、服务、微观与宏观的软件开发过程,组织结构都是一个主要关注点。但是真实世界中的许多软件项目并不是按我们的信念和理解生长的——它们底层层层嵌套,顶层则往往是一团乱麻,相互纠缠。有的时候真的很难让人相信,软件项目的组织结构性也能像物理建筑那样一目了然,层次清晰。
物理建筑,不管地基是石头还是水泥,高大还是宽阔,宏伟还是渺小,其组织结构都一目了然。物理建筑的组织结构必须被“重力”这个自然规律以及建筑材料自身的物理特性所约束。用砖头、水泥、木头、钢铁或者玻璃造就的物理建筑与软件项目相比,最大的不同点就是,大型软件项目由软件组件构成,而这些软件组件又由更小的软件组件构成,层层嵌套。
当我们讨论软件架构时,尤其要注意软件项目是具有递归(recursive)和分形(fractal)特点的,最终都要由一行行的代码组成。脱离了一行行的代码,脱离了具体的细节(detail)设计,架构问题就无从谈起。大型物理建筑的组织架构常常是由其中一个个细节设计共同决定的,如果细节设计太多,那么组织架构就会更复杂,反之亦然。但是软件项目的复杂程度却不一定能用物理尺度来衡量。软件项目也有组织结构,不论从数量上还是种类多样性上都远远超过物理建筑。我们可以很明确地说,软件开发比修建物理建筑需要更多、更专注的设计过程,软件架构师比建筑架构师更懂架构!
虽然人类已经习惯了使用物理尺度来衡量和理解现实世界,但这些却不适用于软件项目。不管某个PowerPoint图表中的彩色方块多么好看、多么简单易懂,也无法完全代表一个软件的架构。它只能是某个软件架构的某种展现形式。软件架构并没有一个固定的展现形式,每一种展现形式都建立在背后的层层抉择之上,例如,哪些部分要包含其中,哪些则应该被排除;哪些部分用特殊形状和颜色进行强调,哪些部分则一笔带过,甚至直接忽略。每种表现形式都是对的,它们往往没有任何内在的联系。
虽然软件可能是人凭空编造出来的,但还是要在现实世界中运行。虽然在设计软件架构的过程中物理定律和物理尺度可能并不是主要考虑的对象,但我们还是要理解和遵循某些约束条件。CPU速度和网络带宽往往直接决定了系统的性能。内存和存储的大小限制也会影响代码的设计。
这就是爱的不幸,期待是无穷的,但行动却是有限的,欲望是无止境的,体验却如奴隶般受限。
——William Shakespeart
无论如何,我们和我们的公司,乃至于整个经济活动都存在于现实世界中,我们可以利用现实世界的一些准则来衡量和推理软件开发过程中那些不好量化和物化的因素。
软件架构是系统设计过程中所有重要设计决定的集合,其中每个设计决定的重要程度则通过变更成本来衡量。
——Grady Booch
时间、金钱以及努力是软件架构中区分规模大小的衡量标准,也是架构和细节的区分标准。通过对这些要素的衡量,我们可以判断某个特定架构是好或坏:一个好的架构,不仅要在某一特定时刻满足软件用户、开发者和所有者的需求,更需要在一段时间以内持续满足他们的后续要求。
如果你觉得好架构的成本太高,那你可以试试差的架构加上返工重来的成本。
——Brian Foote,Joseph Yoder
一个系统的常规变更需求成本不应该是昂贵的,也不应该伴随着难以决策的大型设计而调整,更不应该需要一个独立的项目来单独完成。这些常规变更应该可以归入每日或者每周的日常系统维护中去。
要解决这个问题,还有一个不小的物理难题:时间旅行。我们怎么能够知道某个系统未来的变更需求,以便提前做准备呢?我们怎么能在没有水晶球与时间旅行机的情况下,未卜先知,降低未来的变更成本呢?
所谓架构,就是你希望能在项目一开始就做对,但是却不一定能够做对的决策的集合。
——Ralph Johnson
了解历史已经够难了,我们对现实的掌握最多也只有七八成,预言未来就更加困难。
我们架构师们每天都站在这样拥有无穷选择的交叉路口。