《架构整洁之道》之设计与架构究竟是什么

一、什么是设计？什么是架构？二者究竟有什么区别?

二者没有任何区别。

“架构”这个词往往使用于”高层级”的讨论中。这类讨论一般都把”底层”的实现细节排除在外。而”设计”一词，往往用来指代具体的系统底层组织结构和实现的细节。但是，从一个真正的系统架构师的日常工作来看，这样的区分是根本不成立的。

举个例子说明:

以给我设计新房子的建筑设计师要做的事情为例。新房子当然是存在着既定架构的，但这个架构具体包含哪些内容呢？首先，它应该包括房屋的形状、外观设计、垂直高度、房间的布局等。但是，如果查看建筑设计师使用的图纸，会发现其中也充斥着大量的额设计细节。譬如，我们可以看到每个插座、开关以及每个电灯具体的安装位置，同时也可以看到某个开关与所控制的电灯的具体连接信息;我们能看到壁炉的具体安装位置，热水器的大小和位置信息，甚至是污水泵的位置;同时也可以看到关于墙体、屋顶和地基都有非常详细的建造说明。

总的来说，架构图里实际包含了所有的底层设计细节，这些细节信息共同支撑了顶层的架构设计，底层设计信息和顶层架构设计共同组成了整个房屋的架构文档。

软件设计也是如此。底层设计细节和高层架构信息是不可分割的。它们组成在一起，共同定义了整个软件系统，缺一不可。所谓的底层和高层本身就是一系列政策组成的连续体，并没有清晰的分界线。

二、目标是什么

软件架构的终极目标是，用最小的人力成本来满足构建和维护系统的需求。

一个软件架构的优劣，可以用它满足用户需求所需要的成本来衡量。如果该成本很低，并且在系统的整个生命周期内一直都能维持这样的低成本，那么这个系统的设计就是优良的。如果该系统的每次发布都会提升下一次变更的成本，那么这个设计就是不好的。就这么简单。

三、案例分析

以某公司为例，公司业务取得不断成功，工程师的规模不断扩大，但是生产效率却增长缓慢，以及代码变更成本不断增高、工程师生产力接近0等。

首先来说该公司的业务系统是一个典型的乱麻系统。这种系统一般都是没有经过设计，匆匆忙忙被构建起来。然后为了加快发布的速度，拼命地往团队里加入新人，同时加上决策层对代码质量提升和设计结构优化存在着持续的、长久的忽视，这种状态能持续下去就怪了。

对系统的开发者来说，这会带来很大的挫败感，因为团队中并没有人偷懒，每个人还都是和之前一样在拼命工作。

然而，不管他们投入了多少个人时间，救了多少次火，加了多少次班，他们的产出始终上不去。工程师的大部分时间都消耗在对现有系统的修修补补上，而不是真正完成实际的新功能。这些工程师真正的任务是:拆了东墙补西墙，周而往复，偶尔有精力能顺便实现一点小功能。

那么问题到底出在哪呢？

该书中提到龟兔赛跑，并总结主题思想如下:
1.慢但是稳，是成功的秘诀。
2.该比赛并不是拼谁开始跑得快，也不是拼谁更有力气得。
3.心态越急，反而跑得慢。

这个故事本身揭露得是过度自信的愚蠢行为。兔子由于对自己速度的过度自信，没有把乌龟当回事，结果乌龟爬过重点线取得胜利的时候，它还在睡觉。

这与现代软件研发工作有点类似，现在的软件研发工程师都有点过于自信。当然了，他们确实不会偷懒，一点也不。但是他们真正偷懒的地方在于-持续低估那些好的、良好设计的、整洁的代码的重要性。

这些工程师们普遍用一句话欺骗自己:”我们可以未来再重构代码，产品上线最重要“。但是结果大家都知道，产品上线以后重构工作就再没人提起了。市场的压力永远也不会消退，作为首先上市的产品，后面有无数的竞争对手追赶，必须要比他们跑得更快才能保持领先。

所以，重构的时机永远不会再有了。工程师们忙于完成新功能，新功能做不完哪有时间重构老的代码？循环往复，系统成了一团乱麻，生产效率持续直线下降，直至为零。

结果就像龟兔赛跑中过于自信的兔子一样，软件研发工程师们对于自己保持高产出的能力过于自信了。但是乱成一团的系统代码可没有休息时间，也不会放松。如果不严加提防，再几个月之内，整个研发团队就会陷入困境。

工程师们经常相信的另外一个错误观点是:”在工程中容忍糟糕的代码存在可以在短期内加快工程上线的速度，未来这些代码回造成一些额外的工作量，但是并没有什么大不了“。相信这些鬼话的工程师对自己清理乱麻代码的能力过于自信了。但是更重要的是，他们忽视了一个自然规律:无论是短期还是长期来看，胡乱编写代码的工作速度其实比循规蹈矩更慢。

对于常年关注软件开发本质的人来说，软件开发的一个核心特点:
要想跑得快，先要跑得稳。

综上所述，管理层扭转局面的唯一选择就是扭转开发者的观念，让他们从过度自信的兔子模式转变回来，为自己构建的乱麻系统负起责来。

当然，某些软件研发工程师可能会认为挽救一个系统的唯一办法是抛弃现有系统，设计一个全新的系统来替代。但是这里仍然没有逃离过度自信。试问:如果是工程师的过度自信导致了目前的一团乱麻，那么，我们有什么理由让他们从头开始，结果就会更好呢？

过度自信只会使得重构设计陷入和原项目一样的困局中。

三、总结

不管怎么样看，研发团队最好的选择就是清晰地认识并避开工程师过度自信的特点，开始认真地对待自己的代码架构，对其质量负责。

要想提高自己软件架构的质量，就需要先知道什么是优秀的软件架构。而为了在系统构建过程中采用好的设计和架构以便减少构建成本，提高生产力，又需要先了解系统架构的各种属性与成本和生产力的关系。