[轉]Lisp.自下而上的編程

    一個程序的函數元素不能太大是一個長期存在的編程風格原則。若是程序的某些組件增加到讀難以理解的成都，它就變成一大堆的複雜東西，它們隱藏錯誤就像一個大城市隱藏逃亡者同樣簡單。這樣的軟件將很難讀、很難測試、很難殺臭蟲。

    遵循這個原則，一個大的程序必須被分紅不少片，一個程序越大，就須要被越多地分割。你怎樣分割一個程序呢？傳統的方法是自上而下的設計：你說「這個程序的目的是作這7件事情，因此我把它分紅7個子功能」等等。這個過程持續到整個程序有正確水平的粒度——每塊均可以獨立地作一些事情，可是可以做爲一個單元小到能夠讀懂。

    有經驗的Lisp程序員以不一樣的方式來分割他們的程序。就像自上而下的設計，他們遵循自下而上的設計——改變語言以適應問題。在Lisp中，你不只僅是根據語言去寫你的程序，你也根據你的程序區創建語言。當你正在寫一個程序的時候，你可能想"我但願Lisp有這樣這樣的操做符"，因此你就去寫它。以後，你意識到使用新的操做符將簡化程序其它部分的設計，等等。語言和程序一塊兒演進。就像兩個正在戰爭的國家的邊界同樣，語言和程序的邊界被不斷地重畫，知道最後沿着山脈和河流，你問題的天然邊緣。最後你看的程序，就像這門語言就是爲它設計的同樣。黨語言和程序相互協調很好，你獲得的將是清晰、小巧和高效的代碼。

    值得強調一下，自下而上的設計不只僅意味着以不一樣的順序寫同一個程序。當你自下而上的工做，你一般最後會獲得一個不一樣的程序。你將獲得一個擁有更多抽象操做符的更大的語言和用它寫的更小的程序，而不是單一的、龐大的程序。你將獲得一個拱門，而不是一個橫樑。

    典型的代碼中，一旦你抽象出僅僅記帳的部分，剩下的就很簡短了；你在越高的層級上創造語言，貫穿它所需的距離就越少。這帶來了幾個好處：

1. 經過讓語言作更多的工做，自下而上的設計產生的程序更加小巧和敏捷。一個小的程序沒必要要被分紅那麼多的組件。越少的組件也意味着組件之間的關係也越少，也就意味着那裏有更少的機會出錯。工業設計人員儘量減小機器中須要移動的部分，有經驗的Lisp程序員使用自下而上的設計來減小程序的體積和複雜度。

2. 自下而上的設計提高了代碼的可重用性。當你寫兩個或者更多程序時，爲第一個程序寫的一些工具對隨後的程序也頗有用。一旦你擁有了大量的工具，在你開發一個新程序的時候花費的精力只有用原生的Lisp的一小部分。

3. 自下而上的設計使得程序更加易讀。這種類型的抽象讓讀者理解一個通用的操做符；函數抽象讓讀者去理解一個特定的子功能。

4. 由於它使得你一直關注於你代碼的模式，自下而上的工做會幫助你澄清你程序設計的想法。若是兩個相隔較遠的模塊在形式上是類似的，你將被引導注意到這種類似性，可能你就會從新以一種更簡單的方式來設計這個程序。

    自下而上的設計在非Lisp語言中也能夠在必定程度上實現。當你看到庫函數的時候，就是在進行自下而上的設計。然而，Lisp在這方面給與你更寬廣的力量，而且使語言在Lisp風格的上扮演愈來愈重要的角色——Lisp不只僅是一種不一樣的語言，也是一種徹底不一樣的編程方式。

    這種開發風格適合於那種能夠分紅幾個小組來開發的程序。然而，同時，它擴展了一個小模塊的限制。人月神話中，Frederick Brooks指出一個小組的的生產力和程序員的數量不成正比。隨着小組的擴大，每一個程序員的生產力開始降低。Lisp編程的經驗以一種愉快的方式來表達這個規則：隨着組的縮小，每一個程序員的生產力上身。一個小組成功，相對來講，僅僅是由於它小。當一個小組能夠利用Lisp所帶來的技術時，它能夠一會兒成功。