rules of abstraction

在開發軟體的過程中，總是會有幾回，一不小心失手，寫了失敗的 abstraction 。然後，日後再來痛苦地修正。比方說，把這個 abstraction 放棄掉，先變成大量、重複的程式碼，再來觀察規律，重新提鍊。

那有沒有什麼法則，可以用來提醒自己，做簡單的 checklist ，避免自己寫出糟糕的 abstraction 呢？ 有的。

rule 1: Wait until the code is repeated three times before you extract it.
rule 2: If you can't think of a good name for your abstraction, it is probably not a thing.
rule 3: Understandable and reusable abstraction is usually less than 10 lines.

法則 1：重複三次才提鍊
法則 2：想出好名字才提鍊
法則 3：一個容易理解、可以重用的抽象，往往少於 10 行。


仔細想想，為什麼寫好 function 是如此的困難呢？ 大概是因為我們同時做了三件事吧：

• invent a new purpose
• invent a new implementation
• name it 

Clojure made simple / What is good software?

Clojure made simple 是 Rich Hickey 用來解釋 Clojure 的 value proposition 的一部影片，仔細看過之後，我覺得影片一開始 10 分鐘的分析，非常的深刻。它提供了 Rich Hickey 對於 good software 的看法。

開頭沒有多久，Rich Hickey 就提到寫程式是一種 economic activity ，換言之，你是有雇客或是老闆的。那…雇客/老闆要什麼？他們要的東西就是兩件事：
(1) Something good
(2) Soon

那怎樣子的軟體算是 Something good 呢？定義該是什麼？Rich Hickey 定了三個條件：(Rich Hickey 有特別去強調， type 或是 tests 只是達成目標的手段之一，不能成為目標的定義。)
(a) Does what it is supposed to do
(b) Meets operational requirements
(c) Is flexible enough to accommodate change

然後，這三個 good software 的構成條件又可以拆解開來：
首先對於 (a)
It is very difficult to determine if large or elaborate or stateful programs do what they supposed to do.
而 Clojure 設計的目標之一，就是 making it easier to understand whether or not your program is going to do what it is supposed to do by making it substantially smaller and also by making it more functional.

對於 (b) ，有下列三個目標：
=> 1. Deployment/environment
=> 2. security
=> 3. performance
Clojure 可以透過 host 在 Java/Javascript 上來達成。

對於 (c) ，達成目標的重點在於 loose coupling