在过去几年里,关于设计和架构存在很多疑问。什么是设计,什么是架构,两者有什么不同?
本书的其中一个目的就是消除所有的困惑,并且彻底地给一个确切的定义,设计和架构是什么.对于初学者来说这两者没有区别,一点也没有
架构这个词经常被用在一些高级别的,与低级别的细节分离的上下文当中.而”设计“经常看起来暗示在低级别的决议和结构。但是当你看到架构师做的架构,这种说法又是荒谬的。
思考一下,假如架构师设计你的房子,这个房子有架构吗?当然有。那它的架构又是什么呢。是它的形状,外貌,立体面图,空间和房间的布局。但是当我浏览架构师画出的图。我看到了大量的低级别的细节实现,我看见每一个插座,电灯开关,电灯被标注出来。我看见哪些开关控制哪些电灯。我看到了放置火炉的位置,热水器和抽水泵的大小和位置都被标注了出来,我看见了墙,屋顶,地基将如何被搭建
简而言之,我看见全部的支持顶层决策的底层细节,也看见了底层细节和顶层决策是整个房屋设计的一部分.
所以这就是软件设计,底层细节和顶层结构是相同物体的一部分.它们组成了一个连续的,能定义系统形状的构造物。两者缺一不可。两者没有明确的分割线,
软件设计的目标
好的软件设计的目标和我乌托邦式的描述一模一样。软件架构的目标是用最少的人力资源搭建和维护要求的系统。设计质量的权衡也就是满足用户需求所付出的成本的权衡.如果成本很低,并且至始至终都很低。这就是一个优秀的设计。如果成本很高,而且每次发布新版本,成本逐渐上升。这种设计就比较差。很简单。
实例学习
举个例子,思考下接下来的实例学习。它包含了来自匿名公司的真实数据,首先,让我们看看工程师的增长,我敢肯定你你会觉得这个倾向很振奋人心。
让我们看看该公司同时期的产出,靠代码条形图来衡量
很明显有些东西正在变糟,即使每个版本都有在逐渐增加的工程师支持,但代码的增长接近不对称.
现在来看一张图,这张图展示了每行代码的维护成本
这种倾向不是可持续发展的,不管此刻公司是多么盈利。是什么造成了这种明显的变化,为什么代码从第8版到第1版贵了40多倍
混乱的标志
当多个系统被快速地发布,当大量的程序员是唯一的动力输出时,当很少甚至没有在代码清洁或者结构设计考虑,你看到的这些情况都是混乱的标志。
下面这条曲线看起来就像开发者,他们最初是100%的生产力,每发布一个版本,他们的生产力就会下降.到第四版就逐渐接近0.
来自开发者的观点:这非常让人沮丧,因为每个人都非常努力,没有人减少付出。
至今,尽管开发者加班,奉献,但是没有取得任何实质性进展。他们全部的付出远离需求,消费在处理混乱上。他们的工作变成了将混乱从一个地方移到另一个地方,然后再移到一个地方。。。所以他们几乎很少加功能。
什么变遭了
大约2600年前,伊索寓言的龟兔赛跑,这个故事的寓意被用许多方式阐明:
- 慢而稳赢得了比赛
- 比的不是速度,而是强大
- 欲速则不达
故事本身阐述了过分自信的愚蠢,兔子对自身速度太自信,以至于没有认真应对比赛,并且在比赛途中睡觉。当乌龟冲过线后,兔子还在睡
现在的开发者就好比这场赛跑,展现出相似的自信,他们不睡觉,全靠一股子蛮劲,但是他们一部分大脑已经休息,管理干净,优秀的代码的那部分
那些开发者都撒着一个熟悉的慌,我以后再清理,现在我们必须先取得市场,当然,这些事后来都没有做,因为市场的压力从来没减少过.首先获得市场意味着你后面尾随着一大群竞争者,你必须靠尽自己最大努力来保持领先地位。
所以开发者不会转变模式去修理和清洁垃圾,因为他们已经拿到了下一个要做的需求,需求总是不断地来下一个。混乱不断地制造,生产力继续无限接近0.
兔子对速度过分自信,开发者对生产能力过分自信,但是代码问题会慢慢地削弱生产力,绝不休息和缓和。如果任由发展,把生产力降到0大约只需要一个月
更大的谎言是写脏代码短期让程序员更快,只是长期会放慢。那些接受了该观点的程序员相信他们从制造脏代码模式到清理脏代码模式的转换能力,从而表现出了兔子的过分自信能力。但是他们也犯了一个巨大的错误。写脏代码比保持干净更耗时间,无论什么样的规模。
结论
在每一个例子中,最好的选项是开发组织意识到他们的过分自信,并且开始严肃对待软件架构的质量,为了认真对待软件架构,我们需要知道什么是好的软件架构。为了搭建一个用友最小消耗,最大生产力的设计和架构,我们需要知道需要什么因素。
这就是这本书讲的内容,好的架构和设计长什么样,以至于我们有一个长期有利可图的系统
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。