引言
设计与架构之间的区别到底是什么？什么是设计？什么又是架构？
该书的重要目标就是清晰的，明确的对这两者进行定义和解释。该书认为，这两者，即设计和架构，没有任何区别！
架构这个词往往用于高层级的讨论中，而设计往往涉及到的是底层细节。但是一个真正的架构师的日常工作来看，这样的区分是不成立的。
如设计一个新房子，一个合格的设计师不止要设计房子的地基，外型外观，房间布局，我们还可以看到设计师的设计图纸中，也充斥着大量细节，如每个插座，开关的具体位置，甚至是使用材料的大小明细规格等。
总的来说，是这些细节设计共同支撑了顶层的架构设计（即细节和顶层是不可分割的），底层的设计信息和顶层的架构设计，共同组成了整个房屋。
软件设计也是如此，是高层级和底层细节共同定义了整个软件系统。所谓的底层和高层本身就是一系列决策组成的连续体，并没有清晰的分界线。
目标是什么
好软件设计的终极目标：用最小的人力成本来满足构建和维护该系统。
判断：如果软件系统的整个生命周内一直能维持低成本，就说明系统是优良的。如果每一次发布都会提升下一次变更的成本，那么设计就是不好的。
案例分析
这里的案例，体现了一个不好的设计。
项目初期，软件的版本迭代和程序员人数呈上升趋势，正相关。但是随着软件版本的提升，前期版本的生产效率有明显提升，后期生产效率的提升却非常缓慢。
这中间即出现了差值，即程序员人数多了，后期效率却很低。并且版本的提升，往往带来的是代码变更成本的提升，代码变更成本的提升曲线几乎等同于程序员人数的增长趋势。
最终案例中第8代的产品的构建成本，要比第一代产品高出40倍。那么该产品的盈利是否又有40倍呢？显然这种模式是不可持续的。
乱麻系统的特点
上述案例，这种系统通常是没有经过设计，匆匆忙忙被构建起来的，为了加快发布速度，然后增加人手，同时加上决策层，对代码质量和设计结构的长期忽视，才会造成这种结果。
从上面的例子中，还可以得出一个结论，开发者的生产效率，会随着版本提升越来越低，并且修改成本越来越大。
这对开发者来说是非常具有挫败感的，因为并没有人在偷懒，大家都在努力发版，完成工作。他们大部分时间都是在修修补补，小部分时间才是完成新功能。
管理者视角
这种系统不仅给开发部门带来问题，从管理者角度来讲，开发部门的薪资待遇支出在不断提升，甚至追上了公司利润的提升速度和比例。解决这个问题刻不容缓。
问题到底在哪里
关键点在于软件研发工程师的过度自信和错误观点：
- 持续低估良好的设计和整洁代码的重要性。
- 欺骗自己：”我们可以未来再重构代码，产品上线最重要”，但结果是永远不会有那一天，因为市场的压力永远也不会消退，竞争永远在进行中，作为先上线的产品，后面会有很多对手追赶，只有比他们更快才能领先。
- 糟糕的代码和设计如果能够加快上线速度，那么是可以被接受的。但是他们忽略了一个规律，无论是长期还是短期，胡乱编写代码的工作速度其实比循规蹈矩更慢。
作者举了一个实验案例，这个案例让两个人在6天内完成同一个功能，以代码均通过一个测试集，视为成功通过。其中一个人采用TDD方法编程，另一个则从头开始编写，结果是采用TDD方法的速度更快。
这个实验案例揭示了一个开发核心特点：要想跑得快，先要跑得稳。
管理者扭转局面的唯一选择，就是扭转开发者的观念，让他们改变上述错误观点，为自己构建的系统负责。
当然，某些软件研发工程师会认为，拯救的办法就是重构。但是这里仍然没有逃离过度自信。试问如果是他们得错误观点和过度自信导致目前的状况，那有什么理由相信他们重构的系统，结果会更好？
过度自信只会使得重构设计陷入和原项目一样的困局中。
本章小结
研发团队最好的选择是清晰的认识错误观点和避开过度自信，开始对自己的代码架构负责，对质量负责。
要想提高质量，首先需要知道什么是优秀的软件架构。为了提高生产力，有需要先了解系统架构的各个属性和成本与生产力的关系。
该书为读者描述了什么是优秀的，整洁的软件架构。
个人总结
以上这些我都经历过。要想改变这种开发局面，在如今的大环境中，需要软件研发团队的每一个人都清楚的认识到那些错误观点，为自己的代码负责，同时也需要研发领导顶住压力，以合适的方式向老板阐述软件研发的精髓与匆忙上线的后果。
我也会想如果把这个系统重构就好了，但是无论是同事还是领导都曾对我说，老板不会同意的，这太花时间了
