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
我們選擇簡單的工具，寫出簡單的東西，有時不得不去簡化別人的東西，簡化問題空間或者別人寫的代碼，這本質上也是一種「解開」。
在開始之前，我們需要花一些時間對事情進行簡化。在簡化事情的過程中，我們往往會得到更多的東西。簡單並不是數量少，我們寧願讓更多的東西整齊劃一，而不是讓少數東西糾纏在一起。把這些編織的東西分開的美妙之處在於你可以獲得更多的能力。