A. 老爱丽舍鼓风机关了以后还微风什么处理
还是查查电路吧，因为爱丽舍这车的鼓风机是关不掉的，即使你把风量旋钮放到关的位置他也是非常低的速度运转！
B. 简单是容易之母
本文整理自Clojure语言发明人Rich Hickey发表于2011年的一次题为《Simple Made Easy》的演讲，该演讲虽然年代久远，但一直备受推崇，也曾推荐为每个程序员都要看的十大技术演讲之一，可以说是相当经典。
在这次演讲中，Rich Hickey从辨析简单和容易的词义开始，清晰地指明了它们的辩证关系，以及复杂性的根源，同时也给出了如何构造简单系统的方法，以及我们使用的语言中，哪些是可以用来帮助我们构造简单系统的工件，而哪些又蕴含着复杂性。整个演讲风趣幽默，又不乏金句，虽然并不一定所有的观点都正确，但足以带给我们很多启示，值得反复观看，每次可能会有不同的收获。
由于文章篇幅较多，又有很多晦涩难懂的地方，赶时间的同学可以看看这些核心观点：
如果我们需要建立一个好系统，那么应该建立的是一个简单的系统，而这一点通常不被我们重视。
研究单词的起源很有意思，可以让我们了解它的本义，从而更精确地使用它。
Simple（简单）这个单词由sim和plex两个词根组成，表示一次折叠。它的反义词Comlex（复杂）则表示多次折叠、编织在一起。
常常与Simple（简单）混淆的一个词是Easy（容易）。而Easy首先关联到古法语单词aise，又（被Rich Hickey强行）追溯到拉丁语单词adjacens，找到它的本义为“躺在...附近”。而Easy的反义词为Hard（艰难），词义并不是“躺的很远”，而是“曲折”。
那么，什么是简单的东西呢？
简单的东西应该只有一个角色，它们只完成一项任务，或是只有一个目标，只关乎一个概念，一个维度，比如安全性。
当你在寻找简单的东西时，你希望它 专注于某一领域 ，而不是把东西组合在一起。
但是我们也不能机械地执着于“一个”，简单并不意味着只有其中之一，并不意味着接口只有一个操作时才称得上简单。 简单最重要的特性是没有交织，而不是只有一件事。
简单还有一个重要特性，那就是客观性，和具体人没有多大关系，这是和容易显着的区别。
再来看容易。
上面说了，容易的本义是“就在附近”，意味着物理上很接近，唾手可得，手到擒来，易如反掌等等。
容易也可以引申为“与我们的理解接近”，或者就是我们已经拥有的技能，就是对我们来说很熟悉。
区分简单和容易还有一个关键点，那就是 容易是相对的 ，拉小提琴对于某些人来说很容易，而对于大多数人来说很难。所以， 容易是一个相对术语，是主观的 。
对于软件，首先要区分制品和构造。
我们只能把可靠性寄希望于我们能够理解的东西上。 而这通常是需要做出权衡的，因为太注重扩展性和动态化的东西可能在理解上就变得不容易。
然而， 我们的理解能力总是有限的 ，对于那些我们试图理解并需要确保正确的事，终会受限于我们的理解力。 我们只能同时处理少数事情，当许多事情纠缠在一起时，我们就无法单独对待其中一个。
如果每次我认为我拿出软件的一个新部分时，我需要理解它，然而它与另一件事有关，我不得不把另一件事拉到我的脑海中，因为我无法撇开其中一个思考另一个。这就是它们纠缠在一起的本质。因此， 每一个相互纠缠的因素都在增加我们理解事情的负担。 所以，从根本上说，这种复杂性，我的意思是这种事物的相互牵扯，将限制我们理解系统的能力。
介于这种情况，我们将如何来修改已有的软件呢？
我在今天的一次演讲中听说，敏捷和极限编程已经表明，重构和测试可以使我们能够以零影响进行变革。我不能确定，这实际上不是一件可知的事情。 有测试保障，并不鼓励不加小心地修改代码。
如果你要修改软件，你需要分析它的作用，并决定它应该做什么。你知道，我的意思是，至少你将不得不去问，“这种潜在变化的影响是什么？”“我需要去软件的哪些部分来实现更改？” 无论是使用XP还是敏捷或其他任何东西，都不能回避这个现实问题。如果你不能对你的程序进行推理，你就无法做出这些决定。
对于软件来说，通常都需要做两件事情，一件是添加新功能，另一件则是修补现有功能。
让代码通过类型检查，通过所有测试，这是一种护栏编程，并不能为我们指引方向，引导我们到达期望的目的地，我们必须对程序进行“推理”。
什么样的跑步者能从比赛一开始就跑得尽可能快？答案是只有那些短跑的人。
在软件开发中，如果你忽视复杂性，你终究会放慢脚步，时间越长越是这样。
当然，如果你正在做一些非常短期的事情，你不需要任何这些。你甚至可以用1和0来写它。
对于大多数软件项目，如果选择了容易，会很快有进展，但随着时间的推移，累积的复杂性最终会把项目扼杀掉。你每次只能进展一点儿，而多数时候在重复已经做过的事情。而如果选择了简单，项目启动速度会变慢，因为必须在开始之前对问题进行一些思考。
容易的东西也可能是复杂的 ，我们经常会碰到描述简洁、熟悉且易于使用的复杂构造，我们把这种复杂性称为偶然复杂性。
具备简单性的软件有什么好处呢？至少是容易理解的，也是可以轻松更改的，调试起来也很方便，最终也带来了灵活性。
通过模块化和将事物分开，将赋予我们调整和移动它的能力。当我们让事情变得简单时，就会在决策上拥有更大的独立性。
拥有一个测试套件和重构工具会让改变编织的城堡比改变乐高城堡更快吗？不可能。
我们可以学习更多的东西，通过熟悉来让各种事情变得容易，但是我们不能让我们的大脑变得更聪明，必须通过简化事物来“接近”它。
即使最了不起的杂耍演员，也最多在空中抛9到12个球，但是不能多达20或100个。与我们面对的复杂性相比，我们整体都处于同一级别，非常有限的级别。
因为我们只能玩这么多球，所以必须做出决定，希望这些球中有多少是偶然的复杂性，有多少是你希望成为问题的复杂性？还能多出多少球？
以上是一句挖苦Lisp程序员的话，也反映出了 程序员只喜欢强调新工具或新方法的好处，但很少提及缺点或权衡。
来看一下我们的工具包中的对象。
状态（State）和对象（Object）是复杂的，而值（Value）更简单一些，许多情况下，可以用值来替换对象。
方法（Method）是相对复杂，而函数（Function）和命名空间（Namespace）则简单些，这是因为方法通常在一个类中，在一个很小的、不好的命名空间中。
变量（var）是复杂的，而托管引用（Manged ref）相对简单。
继承、Switch、模式匹配都很复杂，可选的多态策略则是简单的。
语法是复杂的，而数据是简单的。
最终一致性对于程序员来说很难，需要同时思考相关的东西。
组合就是单纯地放在一起，它是简单的，而一旦相互交织在一起则是复杂的，将简单的组件组合起来也会是简单的，这就是编写强大软件的方式，我们可以通过模块化来创建简单的系统。
简单意味着可以方便地垂直分区和水平分层，但是能够分区和分层并不一定是简单的，复杂的东西也可以做到，但不会带来任何好处。
在系统中处理状态从来就不是一件简单的事，这是因为状态天然是一个由值和时间构成的交织体，你没有能力脱离时间去获取值。
状态的复杂性是无法摆脱的，即使用上了模块化的方法，因为有状态的东西封装起来还是有状态的。你每次使用相同的参数去调用它，然而得到的却会是不同的值，复杂性就油然而生。相当于你每次问它相同的问题，却总是得到不同的答案，这就是复杂性。
请注意这种复杂性和并发性无关，我们谈论的是你如何理解你的程序。
一些闪亮的新语言，也有变量和引用，但是却没有让状态变得简单。
另一些把不可变作为默认特性的语言，大大减少了对状态的使用，是非常好的。
而Clojure和Haskell在这方面就显得特别优越，它们通过一些小的构造将时间和值组合在一起，并提供某种抽象来通过时间获取到值，真正回到了简单的路上。
首先是状态，它将时间、标识和值三者混编在一起，让我们无法分解开来。
方法则编织了函数和状态，甚至在有些语言中还将命名空间编织进来。
语法则编织了含义和顺序，无论你多么喜欢你使用的语言中的语法，它都不如数据简单。
继承则编织了类型，将两个类型彼此编织起来。
Switch和Match（匹配）将多对谁将做什么以及将发生什么编织在一起，并且局限在一个地方完成所有这些操作，这非常糟糕。
变量会将时间和值密不可分地编织在一起。我们只能从内存地址获得一个单词、标量，却无法获得一个复合对象。
循环编织了你正在做什么和如何做这两件事。高阶函数也同样地暗示了事物的顺序。
条件判断散布在整个程序中，编织了整个程序的组织结构。
获得更简单生活的第一步就是选择更简单的东西。
函数也是一种简单的工具，多数语言都支持，它就像是无状态方法。
命名空间是真正需要语言做的东西，而多数语言做的并不好。
数据其实很简单，多少年来，数据的本质没有太大变化，还是Map、Set、线性表、顺序数据这些。但是我们创建了数十万个变体，这些变体与本质无关，却难以操纵。我们应该操纵数据的本质，这并不难。
我们如何设计简单的东西？首先就是使用简单的构件。
但我们有时必须编写自己的构件，如何抽象才能简单呢？要一次又一次地把一些东西拿开，将事物的物理特性剥离出去。
有时人们通过抽象粗暴地隐藏一些东西，这不是抽象的本质，不会真正地帮助到你。
关于如何正确抽象，可以从两方面进行。首先是去做5W1H分析，把这些东西分别列出来，然后通过回答“这方面是关于谁的”“这是关于它的哪一方面”这些问题来将事物拆开。然后是通过确定哪些东西“我不知道，也不想知道”来把它们解开。
[微风]What
但是抽象应该非常小，比我们通常看到的都要小。分解包含巨型接口的程序将困难很多，最好将它们多态化。
最重要的是， 抽象表达的是“What（是什么）”，千万不要和“How（如何做）”编织在一起，将它们严格区分开来，是为他人避免问题的关键所在。
[微风]Who
Who指的是数据或实体，这是我们的抽象最终要连接的东西，用来实现抽象。
在构建较大的组件时，将子组件作为参数传递，不要将他们硬连接到他们的父母身上，以提升灵活性。
要使用更多而不是更少组件，以利用小接口的简单性。
不要将组件和组件之间、实体和实体之间编织起来，不要尝试去了解对方的细节，从而避免提升复杂度。
[微风]How
How代表的是如何做，是真正用来完成工作的代码。最好 用多态性将它们和抽象、实体连接起来 。如果使用了switch和模式匹配，那么就会带来把所有东西都混在一起的问题。
要尽可能地隔离实现，避免和其它任何东西编织在一起。
[微风]When、Where
关于何时、何处的简化规则很简单，就是不要把任何东西和它们编织起来。但是，人们在设计一些直接连接对象的系统时，问题就会溜进来。如果A调用了B，那么你就把它们编织了起来。调用时，你需要知道B在哪里，而A什么时候调用B。
解决这种问题的方法就是 使用队列（Queue ），如果您没有广泛使用队列，则应广泛使用队列，你应该立即开始。
[微风]Why
Why是关于程序的策略和规则的部分，这部分是很难简单化的。我们通常将它们直接放在应用程序中，如条件判断、控制流等。这样，当你与用户讨论应用是如何做的时候，就必须坐下来一起看源代码，这非常困难。
[微风]信息
对象不是被设计用来作为信息载体的，不要把对象用于信息，它是复杂的，会破坏我们构建通用数据处理的能力。
ORM也将业务逻辑与数据展现编织在一起，带来了复杂性。
所以，数据就是数据，把它放在那里，语言中如果有Map、Set，直接用它们就好，不要专门为信息创建类。
[微风]Work
我们选择简单的工具，写出简单的东西，有时不得不去简化别人的东西，简化问题空间或者别人写的代码，这本质上也是一种“解开”。
在开始之前，我们需要花一些时间对事情进行简化。在简化事情的过程中，我们往往会得到更多的东西。简单并不是数量少，我们宁愿让更多的东西整齐划一，而不是让少数东西纠缠在一起。把这些编织的东西分开的美妙之处在于你可以获得更多的能力。