摘抄

我们似乎总是低估那些好的、良好设计的、整洁的代码的重要性。

架构师的目标：软件架构师必须创建出一个可以让功能实现起来更容易、修改起来更简单、扩展起来更轻松的软件架构。

需要重视测试。

软件架构师需要定义可以方便地进行证伪（测试）的模块、组件以及服务。

产品上线以后重构工作就再没人提起了，市场的压力永远也不会消退。

工程师们经常相信的另外一个错误观点是：“在工程中容忍糟糕的代码存在可以在短期内加快该工程上线的速度，未来这些代码会造成一些额外的工作量，但是并没有什么大不了。”相信这些鬼话的工程师对自己清理乱麻代码的能力过于自信了。

某些软件研发工程师可能会认为挽救一个系统的唯一办法是抛弃现有系统，设计一个全新的系统来替代。但是这里仍然没有逃离过度自信。试问：如果是工程师的过度自信导致了目前的一团乱麻，那么，我们有什么理由认为让他们从头开始，结果就会更好呢？

要想跑得快，先要跑得稳。

优秀的软件设计师和架构师会花费很大精力来设计接口，以减少未来对其进行改动。

如果一段程序调用了某个库函数，编译器就会将这个函数的名字输出为外部引用（externalreference），而将库函数的定义输出为外部定义（externaldefinition）。加载器在加载完程序后，会将外部引用和外部定义链接（link）起来。这就是链接加载器（linkingloader）的由来。

对大部分应用程序来说，可维护性的重要性要远远高于可复用性。

不要依赖不需要用到的东西。

如果我们想要保持高效率的开发，就不能频繁地进行构建操作，设计良好的架构可以让系统便于理解、易于修改、方便维护，并且能轻松部署。

基本上，所有的软件系统都可以降解为策略与细节这两种主要元素。策略体现的是软件中所有的业务规则与操作过程，因此它是系统真正的价值所在。

软件架构师的目标是创建一种系统形态，该形态会以策略为最基本的元素，并让细节与策略脱离关系，以允许在具体决策过程中推迟或延迟与细节相关的内容。例如，在开发的早期阶段应该无须选择数据库系统

我们在运行测试的时候不应该运行Web服务，也不应该需要连接数据库。

ORM系统应该属于系统架构中的哪一层呢？当然是数据库层。

修改一个通用的系统组件可能会导致成百上千个测试出现问题，我们通常将这类问题称为脆弱的测试问题（fragiletestsproblem）。

我们在系统设计与测试设计时，应该让业务逻辑不通过GUI也可以被测试。

如果你在代码中嵌入了SQL或者是代码中引入了对某个平台的依赖的话，其实就是在写固件代码。

如果只能在特定的平台上测试代码，那么这一定会拖慢项目的开发进度。

如果没有完善的测试流程，那么你就等着无穷无尽的手工测试吧——同时还有纷沓而来的Bug报告。

你必须明白，如果一旦在项目中引入一个框架，很有可能在整个生命周期中都要依赖于它，不管后来情形怎么变化，这个决定都很难更改了。因此，不应该草率地做出决定。

看不懂的

1.关于3种编程范式的描述：

结构化编程对程序控制权的直接转移进行了限制和规范。

面向对象编程对程序控制权的间接转移进行了限制和规范。

函数式编程对程序中的赋值进行了限制和规范。

2.插件式架构

知道那个意思，但不知道怎么做。

一个架构设计良好的应用程序应该将状态修改的部分和不需要修改状态的部分隔离成单独的组件，然后用合适的机制来保护可变量。

任何层次的软件设计如果依赖了它并不需要的东西，就会带来意料之外的麻烦。

依赖开源算不算？不可能把某个开源包的代码抠出来吧。

软件复用的最小粒度应等同于其发布的最小粒度。

如果软件架构师早先就考虑到这些部署问题，可能就会有意地减少微服务的数量，采用进程内部组件与外部服务混合的架构，以及更加集成式的连接管理方式。

通过将系统切分为组件，并使用稳定的接口将组件隔离，我们可以将未来新功能的添加方式明确出来，并大幅度地降低在修改过程中对系统其他部分造成伤害的可能性。

在开发的早期阶段也不应该选定使用的Web服务-不知如何做。

依赖反转

利用动态多态技术，我们将源码中的依赖关系与控制流的方向进行反转。不管控制流原本的方向如何，我们都可以让它遵守架构的依赖关系规则。

很多数据访问框架允许将数据行和数据表以对象的形式在系统内部传递。这么做在系统架构上来说是完全错误的，这会导致程序的用例、业务逻辑、甚至UI与数据的关系模型相互绑定在一起。

编程经验

if（driver.getDispatchUri（）.startsWith（"acme.com"））…

然而很明显，任何一个称职的软件架构师都不会允许这样一条语句出现在自己的系统中。因为直接将“acme”这样的字串写入代码会留下各种各样神奇又可怕的错误隐患，甚至会导致安全问题。