设计与架构究竟是什么-《架构整洁之道》读书笔记
设计与架构究竟是什么？
尽管标题是 设计与架构究竟是什么？然而书中似乎并没有给出答案。反而对于目标给出了清晰的定义。
1 | 软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。 |
对于架构评估，书中给出了简单的说明。
1 | 一个软件架构的优劣，可以用它满足用户需求所需要的成本来衡量。如果该成本很低，并且在系统的整个生命周期内一直都能维持这样的低成本，那么这个系统的设计就是优良的。如果该系统的每次发布都会提升下一次的变更的成本，那么这个设计就是不好的。 |
乱麻系统
书中举了一个乱麻系统的例子，说明一个糟糕的架构有多令人难受。乱麻系统的特点如下：
- 没有经过设计，匆匆忙忙被构建起来
- 为了加快发布速度，拼命地往团队里加入新人
- 决策层对代码质量提升和设计结构优化存在着持续的、长久的忽视
导致的后果就是，对开发者来讲带来了很大的挫败感，团队没有人偷懒，拼命工作，然而不管他们投入了多少个人时间，救了多少次火，产出始终上不去。工程师的大部分时间都消耗在对现有系统的修修补补上，而不完成新功能。
对于公司管理层而且，就是成本不断的上升，功能产出确明显下降。
解决之道
书中举了龟兔赛跑的故事，归纳了以下的主题思想：
- 慢但是稳，是成功的秘诀
- 该比赛并不是拼谁开始跑的快，也是不拼谁更有力气
- 心态越急，反而跑得慢
工程师们普遍用一句话来欺骗自己：“我们可以未来再重构代码，产品上线最重要！”但是结果大家都知道，产品上线后重构工作就再没人提起了。
接下来就举例子说明 测试驱动开发（TDD） 的方法论，说明软件开发的一个核心特点：
1 | 要想跑得快，先要跑得稳。 |
接下来是另一个极端，某些工程师可能会认为挽救一个系统的唯一办法是抛弃现有系统，设计一个全新的系统来替代。然而
1 | 过度自信只会使得重构设计陷入和原项目一样的困局中。 |
个人观点
关于架构评估，书中只简单讲了评判标准，而且是结果型的标准。当然这样指明了大的方向，而具体的方法论并没有讲。当然架构评估本身就是一门复杂的学问。
关于乱麻系统一，有的项目就是开发完成就结束了，或者还没开发完成就结束了，对于这一类项目，似乎是什么样的架构并不重要，因为不存在维护的问题。所以一个项目在立项时，有没有考虑过它的生命周期呢？项目的生命周期越长，平摊成本就越低，而收益越大。
关于乱麻系统二，业务与技术往往是相反的，业务上的事件的发生往往是突发的，而为了应对突发事件产生的系统，往往没有足够的时间留给技术实现团队。这也变相的要求作为技术人，需要准备好架构预案，针对某类系统有提前想的架构模块，业务需求真的到来的时候，需要我们能花费较少的时间就能出来一个还不错的设计，从而满足业务的需要，所以没事多磨刀。
关于设计一个全新的系统，往往我们面临的是别人留下来一堆代码，而这一堆里，不知道哪些有用，哪些没用，而且出于新人接手的情况下，如果业务上不特别着急，又需要工程师表现时，就很容易出现通过重构以显示自己能力的想法。这个时候我们一定不要忘记架构的目标，就是前面说的:
软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。
我们一定要想想，重构是不是能用最小的人力成本来满足构建和维护该系统的需求。
- 关于要快还是要稳，我想架构上是要稳，业务上可能是要快，这个时候要看我们如何取舍了。有时候要快才能占领先机。
