架构整洁之道 1~2章读书笔记

第1部分 概述

第1章 设计与架构究竟是什么

设计（Design）与架构（Architecture）二者没有任何区别。一丁点区别都没有！

“架构”这个词往往使用于“高层级”的讨论中。这类讨论一般都把“底层”的实现细节排除在外。而“设计”一词，往往用来指代具体的系统底层组织结构和实现的细节。但是，从一个真正的系统架构师的日常工作来看，这样的区分是根本不成立的。

目标是什么

软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。

一个软件架构的优劣，可以用它满足用户需求所需要的成本来衡量。

龟兔赛跑的思想：

• 1．慢但是稳，是成功的秘诀。
• 2．该比赛并不是拼谁开始跑得快，也不是拼谁更有力气的。
• 3．心态越急，反而跑得越慢。

软件开发的一个核心特点：要想跑得快，先要跑得稳。

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

第2章 两个价值维度

对于每个软件系统，我们都可以通过行为和架构两个维度来体现它的实际价值。

行为价值

软件系统的行为是其最直观的价值维度。

大部分程序员认为他们的工作是且仅是：按照需求文档编写代码，并且修复任何Bug。这真是大错特错。

架构价值

软件系统必须保持灵活。软件发明的目的，就是让我们可以以一种灵活的方式来改变机器的工作行为。

变更实施的难度应该和变更的范畴（scope）成等比关系，而与变更的具体形状（shape）无关。

如果系统的架构设计偏向某种特定的“形状”，那么新的变更就会越来越难以实施。所以，好的系统架构设计应该尽可能做到与“形状”无关。

哪个价值维度更重要

架构的灵活性比系统行为更加重要。

艾森豪威尔矩阵

• 软件系统的第一个价值维度：系统行为，是紧急的，但是并不总是特别重要。
• 软件系统的第二个价值维度：系统架构，是重要的，但是并不总是特别紧急。

平衡系统架构的重要性与功能的紧急程度这件事，是软件研发人员自己的职责。

为好的软件架构而持续斗争

研发团队必须从公司长远利益出发与其他部门抗争。

有成效的软件研发团队会迎难而上，毫不掩饰地与所有其他的系统相关方进行平等的争吵。

如果忽视软件架构的价值，系统将会变得越来越难以维护，终会有一天，系统将会变得再也无法修改。如果系统变成了这个样子，那么说明软件开发团队没有和需求方做足够的抗争，没有完成自己应尽的职责。