阅读架构之美笔记

关于架构的一些描述：

1. 软件架构通常是分层的层次结构，这种层次结构将几种不同的结构放在一张图中。
2. 架构是系统设计的一部分，它突出了某些细节，并通过抽象省略掉另一些细节。所以，架构是设计的一个子集。关注实现系统组件的开发者可能不会特别关心所有组件如何装配在一起，而是主要关注少数组件的设计和开发，包括他们必须遵守架构约束和可以应用的规则，因此，开发者和架构师面对的是系统设计的不同方面。如果说架构关注的是组件之间的关系和系统组件外部可见的属性，那么设计还要关注这些组件的内部结构。
3. 外部行为描述展示了产品如何与它的用户、其他系统和外部设备进行交互，这应该表现为需求。结构描述展示了产品如何划分为多个部分，以及这些部分之间的关系。我们还需要内部行为描述，用于描述组件之间的交互接口。结构图上的描述常常展示相同部分的一些不同的视图，因为不可能把所有信息以有意义的方式组织到一张图纸或一分文档中。一个视图中的组件，可能是另一个视图中一个组件的一个部分。

架构师首要关心的不是系统的功能，而是系统的品质，系统品质主要有：

             1、性能  2、容量  3、生态系统  4、模块化  5、产品化  6、功能性 7、可用性  8、伸缩性 9、扩展性  10、安全性
在系统开发中应该注意的地主：

1、保持品质
2、简单、清晰、一致、有弹性
3、组件应该高内聚，有很好的角色定义。
4、功能和数据都应该放在一个定义好的地方。如核心服务的功能就应该放在核心部分来完成。
5、限制通信的线路，只提供绝对需要的。
6、模块间的依赖应该是单向的。
7、不要用硬编码。
8、使用共同的编码标准，使用共同的库。
9、组件、类和文件都应该有命名惯例。
10、有共同的构建系统。
11、胶带、shell脚本、Perl胶水与makefile和Visual Studio项目文件不要混在一起。
12、不要重新发明轮子。
13、一些简单的东西，如通用算法和数据结构应该整体成库。
14、系统应该有最低层，有控制中心.
15、好的设计应该考虑到内部组件的连接机制和连接数（以及连接性质）。系统的单个部分应该能够独立存在。紧耦合将导致不可测试的代码。

16、在项目开始时要明确构建的是什么。
17、不要有特殊的对象生命周期或奇怪的资源管理。
18、延迟设计决定：如果你不是马上需要，就不要去做。消除猜测的工作，确保设计正确。
19、不要在开始创建软件设计时就加入所有可能需要的东西，否则所有大部分工作会变成无用功，得到的只是额外的负担，导致不得不在整个变更
        生命周期性中支持这些设计。

20、单元测试的另一个好处在于，它们在很大程度上定型了代码设计：它们实际上迫使我们实现好的结构。每个小的代码组件都被定型成定义良好的实体
     ，可以独立存在，因为它必须能够在单元测试中构造出来，不需要围绕它构造系统的其它部分。编写单元测试确保了每个代码模块的内聚性，也确保
     了与系统其它部分之间的松耦合。单元测试迫使我们仔细考虑每个单元的接口，确保该单元的API是有意义的，内部是一致的。

注意事项：

            1、不好的公司结构和不健康的开发过程将在糟糕的软件架构中得到反映。
            2、不良架构的影响不仅限于代码。它会进一步影响到人、团队、过程和时间表。
            3、重要的是要在开始设计系统之前知道你打算设计什么。如果你不知道它是什么，也不知道它将做什么，暂时不要开始设计它。只设计你知道需要的东西
            4、架构有助于定位功能：添加功能、修改功能或修复缺陷。它为你提供了一个模板，让你将工作纳入到一张系统导航图中。
            5、清晰的架构设计将导致一致的系统。所有决定都应该在架构设计的背景下做出。
            6、清晰的架构有助于减少功能重复。
            7、软件架构不是一成不变的。需要时就改变它。要想做到可以修改，架构就必须保持简单。牺牲简单性的修改要抵制。
            8、延迟设计决定，直到你必须做出这些决定为止。不要在你还不知道需求的时候就做出架构决定。不要猜测。
            9、必须保持架构品质。只有当开发者们相信它并对它负责时，才能做到这一点。
          10、你的系统应该有一组不错的自动化测试，它们让你在进行根本的架构变更时风险最小。这为你提供了工作的空间。
          11、好的项目计划将带来好的设计。分配足够的时间来架构杰作，它们不会立即出现。
          12、团队的组织方式必然对它产生的代码有影响。随着时间的推移，架构也会影响到团队协作的好坏。当团队瓦解时，代码的交互就很糟糕。当团队协作时，
                   架构就集成得很好。
思考问题：
        1、什么是你看到过的最好的系统架构？
              你怎么知道它是好的？
              这个架构在代码集之内和之外带来了什么结果？
              你从中尝到了什么？
        2、什么是你看到过的最差的系统架构？
              你怎么知道它是差的？
              这个架构在代码集之内和之外带来了什么结果？
              你从中尝到了什么？