闲聊
半年前，购入了《架构》一书，当时一口气看了三分之一，有顿悟之感，自觉对编码思想有了很大提高。
但因本人水平有限，java菜鸟一个，对于后三分之二，读起来晦涩难懂，然后搁置。如今，因为一些工作中的实际应用，对java，对面向对象本身，有了一些新的理解，因而重读此书，作此读书笔记。
正文
第一章
架构既设计
- 架构通常指代高层，而把底层细节排除在外。
- 设计通常指代底层，指的是各个部分的实现细节。
软件设计既应该包括架构，也应该包括设计。他们虽有侧重，但不应有分隔。或者这么来说，他们是连续的。
（莫名想到了当初高数的函数连续性，hhhh）
软件设计的目标
软件架构的终极目标，是用最小的人力成本来满足构建和维护该系统的需求
软件架构在于，预估出用户修改的量级，使整个系统，在它的生命周期内，维持一个修改的低成本。
案例分析
一个工程师规模增长，但代码行数停滞，以及代码行数变更成本剧增的案例。
原来第一个用代码行数衡量工作量的是你，Bob大叔
一个典型的没有经过合理架构的系统，（突然想到了自己刚刚开发过的系统，好打脸）
- 缺乏设计
- 匆忙构建
- 为了加快速度，而拼命加新人
- 对代码质量和结构设计的忽视
对于开发者来说，这会带来很大的挫败感，因为团队中没人偷懒，每个人都在拼命工作。
不管他们投入了多少个人时间，救了多少次火，加了多少次班，他们的产出始终上不去。工程师的大部分时间都消耗在对现有系统的修修补补上，而不是真正完成实际的新功能。
这些工程师真正做的是：拆了东墙补西墙，周而往复，偶尔有精力能顺便做一点小功能。
管理层，同样能够看出问题，人越加越多，支出也是，然而实现一个功能的成本也越来越高，最初的功能带来的收益最大，然而最后的功能，支出很多，但几乎没有收益
一个栗子🌰
龟兔赛跑的启示
- 慢但是稳，是成功的秘诀
- 比赛不比谁最开始跑的快
- 心态越急，跑的越慢
程序员的误区与谎言
持续低估 良好设计的、整洁的代码的重要性。
我们可以未来重构代码，保证上线最重要。
容忍糟糕的代码，可以加快上线的速度。
采用TDD可以加快速度。mark //ToDo TDD
有人认为，重写可以规避这个问题，其实不然
过度自信只会让重构设计陷入和原项目一样的困局中
