软件开发架构初步了解

对我而言，代码是实实在在的，看得见，摸得着；而架构虽然散发着光芒，但好像有点虚，似乎认知、思考还比较少。
clean architecture的作者是一位从事软件行业几十年的架构大师，参与开发了各种不同类型的软件，在职业生涯中发现了一个规律：那就是，尽管几十年来硬件、编程语言、编程范式发生了翻天覆地的变化，但架构规则并没有发生变化。
上升到架构层面来说，问题同样存在，而且更加明显，因为架构的影响面远大于代码。作者举了一个例子，展示了随着代码量增加、团队人员增加、release版本增加，导致的新增代码代价的激增以及程序员生产力的下降。

从可以看到，随着时间的推移，每一行代码的代价（成本）都在逐渐上升。
从另一个角度来看

单个程序员的产出随着 release急剧 下降，即使为了一个小小的feature，也不得不到处修修改改，容易牵一发而动全身
这样的经历，尤其在项目后期，或者团队人员几次轮换之后，代码就变得难以维护，以至于没有人敢轻易改动。出现这样的问题，不能仅仅归咎于code – code这个层面关注的是更为细微具体的东西（比如命名、函数、注释），更多的应该是设计出了问题，或者说架构出了问题。
因此说，软件架构的目标是为了减少构造、维护特定系统的人力成本

行为和架构是软件系统的两个价值维度，行为是指软件开发出来要解决的问题，即功能性需求；而架构则算非功能性需求，比如可维护性、扩展性。很多程序员迫于各种压力，可能觉得只要实现功能就行了；殊不知，非功能性需求也是技术债务，出来混，迟早是要还的。

艾森豪威尔矩阵：

behavior: 紧急，但不总是特别重要
architecture：重要，但从来不紧急
了解过时间管理或者目标管理的话，都知道重要但不紧急的事情反而是需要我们特别花时间去处理的。
而架构设计就是让我们在支撑功能的同时，保证系统的可维护性、可扩展性。
软件开发和修房子一样，在实施角度来看都是从low-level到high-level的过程，比如房子是由砖块(brick)到房间(room)，再由房间到房子(house)。