第一章 设计和架构是什么？
这些年有许多关于设计和架构的困惑，设计是什么？架构又是什么？这两者有什么不同吗？
这本书的一个目标就是解开这个困惑，去真正定义设计和架构是什么？对于初学者，我将假设设计和架构一点区别都没。
“架构”这个词常常用于高层的上下文中，而不在低层的细节。但“设计”这个词往往是意味着低层的结构和决定。但在真实的架构中他们的使用场景还是很模糊的。
考虑一个设计新房子的架构师，这个房子有架构吗？当然有的。那它的架构是什么？呃，它是房子的形状，外观，标高，空间和房间的布局。当我看着我的架构产出图，我看到了大量的低层细节。 我看到每个插座，灯开关和灯的放置。 我看到哪些开关控制哪个灯。 我看到炉子放在哪里，热水器和水池泵的大小和位置。 我看到了如何构建墙壁，屋顶和基础的详细描述。
简而言之，我看到了支持高层决定的所有细节。我也看到了低层细节和高层决定都是房子设计的一部分。
那类比软件设计，低层细节和高层决定也是软件设计的一部分。它们形成一个连续的结构，定义了系统的形状。所以你不能缺少任何一个;事实上，他们也没有明确的分界线。 只有从最高层到最低层的一体的决定。
目标？
这些决定的目标是什么？好的软件设计的目标是什么？这目标不亚于我对乌托邦的描述：
软件架构的目标是最小化需要构建和维护系统的人力资源
设计质量的衡量可以简单通过衡量满足客户需求的所需努力来体现。如果这种努力少，并且在系统的整个生命周期中保持少的水平，那么设计是好的。如果这个努力随着每个新版本的增长而增多，则设计是不好的。就这么简单。
案例研究
用个例子来研究以下案例。它包括了一个匿名的真是公司的数据。
首先，让我们看着这个工程人员的数量增长，我相信你同意这个趋势挺的鼓舞人心的，如图1.1的增长肯定意味着很大的成功。
图1.1 工程人员的数量增长
来自Jason Gorman的演示文档的一帧，已授权。
现在，让我们看同时期，这家公司的产能，通过简单地代码行数统计（如图1.2）。
图1.2 同时期的产能
很明显，一些事变得很糟了。即使每个发布版本开发人员都不停的增长，但是代码量的增长却看起来趋于渐近线。
现在提供真实的工资图，如图1.3展示了同时期每行代码的成本。
这些趋势是不可持续的。 这个公司在一时刻的盈利状况并不重要：这些曲线使得公司即使没有彻底崩溃的话，也将大大消耗商业模式的利润，并将公司陷入困境。
是什么造成了生产力的显着变化？ 为什么代码版本8与发行版本1相比，代码成本要高40倍呢？
图1.3 同时期每行代码的成本
混乱的标志
你看到的是一个混乱的标志。 当系统匆匆被抛在一起时，当程序员的数量是产能的唯一驱动者，当对代码的清洁程度或设计的结构没有多少想法时，那么你可以相信这个曲线会到丑陋的一端。
图1.4展示了对于开发者的曲线。初始时，他们的产能接近100%，但随着每个版本，他们的产能降低，到了第四次发布，很明显的看到他们产能将沉底到为0的渐近线。
图1.4 版本和产能
从开发者的角度来看，这结果及其可怕，因为每个人都努力工作了，没有人减少他们的努力。
然而，尽管他们英勇，加班和奉献，但他们根本没有得到任何东西了。 他们所有的努力都被从开发功能特性中转移出来，现在被用来管理混乱。 他们的工作已经改变了，从一个地方转移到另一个地方，下一个和另一个地方，这样下去他们就只能增加小小的功能特征了。
高管的角度
如果你觉得这已经很糟糕了，想象一下这张图对高管看起来是什么样的！考虑图1.5，绘制了同时期每月的开发工资条。
图1.5 同时期每月的开发工资条
第一个版本每月花费数百万美元，第二个版本每月花费多于数百万美元，到了第八个版本每月花费达两千万每月，而且保持增加态势。
这张表只包含工资一项，显然有些令人惊讶的事将发生。人们希望收入超过成本，从而证明费用的合理性。 但是不管你怎么看这条曲线，都值得关注。
但现在比较图1.5和图1.2中的每个版本的代码行数。最开始每个月花费千万美元带来了许多功能，但最后2千万美元却几乎没带来任何东西，任何CFO看这两张图都知道得立马采取必要行动以避免灾难。
但是该怎么行动呢？是什么出问题了？是什么导致了产能惊人的下降？ 高管们可以做些什么，而不是对开发者感到愤怒？
什么出问题了？
在近2600年前，伊索讲了龟兔赛跑的故事，这个故事的寓意在不同情况下多次被陈述：
- 慢且稳赢得胜利
- 这场比赛不是比快，也不是强壮的对决
- 越自大，速度越慢
这个故事本身阐明了过度自信的自大。这只兔子，对于它自己固有的速度如此自信，没有认真对待比赛，即使当乌龟抵达终点线时仍然在睡觉。
现代开发者也在类似的赛道上，也表现出了相似的过度自信。哦，他们远不会睡觉的，大多数现代开发者都在努力工作。但是他们大脑的一部分确实是在睡觉 - 而这部分 知道好的，干净的，精心设计的代码很重要。
这些开发者都相信一个熟悉的谎言：“我们可以清理它， 我们只能先上市！“想当然，以后的事情永远都不会被清理干净，因为市场压力永远不会减少。 因为首先进入市场意味着现在你的后头已经有了一大批竞争对手，所以你必须尽可能快地跑到最前面。
所以开发者决不会切换模式。 他们不能回过头清理，因为他们必须完成下一个功能特性，还有下一个，下一个，下一个。 所以这个烂摊子就建立起来了，产能继续朝着零的方向渐近。
就像兔子的速度过于自信一样，开发者对自己的生产能力过于自信。但是代码的琐碎过于混乱使得他们的工作效率不高，从不懈怠。 如果按照这种方式，在几个月内，产能降低到零。
开发人员相信的一个更大的谎言是，编写混乱的代码使得他们在短期内进度更快，在长期中放慢速度即可。 接受这种谎言的开发者表现出类似兔子对自己的能力过分自信。在将来转换模式转化为清理垃圾的能力，但也会造成事实上的简单错误。因为，无论使用哪种时间尺度，制造混乱总是比保持清洁慢。
考虑一下Jason Gorman所做的著名实验的结果，如图1.6所示。Jason在六天的时间里进行了这个测试。 他每天都完成一个简单的程序，将整数转换成罗马数字。 当他预设的验收测试通过时，那么他的工作已经完成。 每一天的任务花了不到30分钟。 Jason在第一，第三和第五天使用了一个名为测试驱动开发（TDD）的著名整洁规范。在另外三天，他没有这个依据这个规范写了代码。
图1.6 使用/未使用TDD的迭代完成时间
首先，注意图1.6中的学习曲线。后一天的工作比前一天更快完成。另请注意，TDD日的工作比非TDD日的工作快了近10％，即使最慢的TDD日也比最快的非TDD日快。
有些人可能会看到这样的结果，并认为这是一个了不起的结果。但对那些没有被兔子的过度自信所迷惑的人来说，结果是可以预料的，因为他们知道软件开发这个简单的道理：
走得快的唯一途径就是走好。
这就是高管们的困境的答案。扭转生产力下降和成本增加的唯一方法是让开发人员停止像过度自信的兔子那样的思考，并开始为他们所做的混乱负责。
开发人员可能会认为答案是从头开始重新设计整个系统 - 但这只是兔子行为的又一次重现。导致前一次混乱的元凶，即过度自信又告诉他们，如果他们能够开始比赛，他们可以更好地建立它。现实并不乐观：
他们的过度自信将推动重新设计，像原来的项目一样混乱。
小结
在每个案例，开发组织的最好方式是认清自身，避免过度自信，开始严格采取软件架构质量措施。
为了严格执行软件架构，你得知道好的软件架构是什么，为了构建最小努力最大收益的设计和架构的系统，你得知道那种系统架构的属性可以做到。
这就是这本书的内容，它描绘了良好而整洁的架构和设计看起来长什么样，这样软件开发人员就可以构建一个拥有长期有利的生命周期的系统。