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

均为原创，读架构整洁之道的笔记。

包含了部分自己的理解，包含了原书中至少70%的知识点。
完整笔记，各位老哥友链加起来吧。
我的博客地址：www.yuque.com/_huangkuan

引言

设计与架构之间的区别到底是什么？什么是设计？什么又是架构？

该书的重要目标就是清晰的，明确的对这两者进行定义和解释。该书认为，这两者，即设计和架构，没有任何区别！

架构这个词往往用于高层级的讨论中，而设计往往涉及到的是底层细节。但是一个真正的架构师的日常工作来看，这样的区分是不成立的。

如设计一个新房子，一个合格的设计师不止要设计房子的地基，外型外观，房间布局，我们还可以看到设计师的设计图纸中，也充斥着大量细节，如每个插座，开关的具体位置，甚至是使用材料的大小明细规格等。

总的来说，是这些细节设计共同支撑了顶层的架构设计（即细节和顶层是不可分割的），底层的设计信息和顶层的架构设计，共同组成了整个房屋。

软件设计也是如此，是高层级和底层细节共同定义了整个软件系统。所谓的底层和高层本身就是一系列决策组成的连续体，并没有清晰的分界线。

好软件设计的终极目标：用最小的人力成本来满足构建和维护该系统。

判断：如果软件系统的整个生命周内一直能维持低成本，就说明系统是优良的。如果每一次发布都会提升下一次变更的成本，那么设计就是不好的。

这里的案例，体现了一个不好的设计。

项目初期，软件的版本迭代和程序员人数呈上升趋势，正相关。但是随着软件版本的提升，前期版本的生产效率有明显提升，后期生产效率的提升却非常缓慢。

这中间即出现了差值，即程序员人数多了，后期效率却很低。并且版本的提升，往往带来的是代码变更成本的提升，代码变更成本的提升曲线几乎等同于程序员人数的增长趋势。

最终案例中第8代的产品的构建成本，要比第一代产品高出40倍。那么该产品的盈利是否又有40倍呢？显然这种模式是不可持续的。

上述案例，这种系统通常是没有经过设计，匆匆忙忙被构建起来的，为了加快发布速度，然后增加人手，同时加上决策层，对代码质量和设计结构的长期忽视，才会造成这种结果。

从上面的例子中，还可以得出一个结论，开发者的生产效率，会随着版本提升越来越低，并且修改成本越来越大。

这对开发者来说是非常具有挫败感的，因为并没有人在偷懒，大家都在努力发版，完成工作。他们大部分时间都是在修修补补，小部分时间才是完成新功能。

这种系统不仅给开发部门带来问题，从管理者角度来讲，开发部门的薪资待遇支出在不断提升，甚至追上了公司利润的提升速度和比例。解决这个问题刻不容缓。

关键点在于软件研发工程师的过度自信和错误观点：

持续低估良好的设计和整洁代码的重要性。
欺骗自己：”我们可以未来再重构代码，产品上线最重要”，但结果是永远不会有那一天，因为市场的压力永远也不会消退，竞争永远在进行中，作为先上线的产品，后面会有很多对手追赶，只有比他们更快才能领先。
糟糕的代码和设计如果能够加快上线速度，那么是可以被接受的。但是他们忽略了一个规律，无论是长期还是短期，胡乱编写代码的工作速度其实比循规蹈矩更慢。

作者举了一个实验案例，这个案例让两个人在6天内完成同一个功能，以代码均通过一个测试集，视为成功通过。其中一个人采用TDD方法编程，另一个则从头开始编写，结果是采用TDD方法的速度更快。

这个实验案例揭示了一个开发核心特点：要想跑得快，先要跑得稳。

管理者扭转局面的唯一选择，就是扭转开发者的观念，让他们改变上述错误观点，为自己构建的系统负责。

当然，某些软件研发工程师会认为，拯救的办法就是重构。但是这里仍然没有逃离过度自信。试问如果是他们得错误观点和过度自信导致目前的状况，那有什么理由相信他们重构的系统，结果会更好？

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