打破開發傳統 "差點的更好"設計理念的興起
我和幾乎所有的Common Lisp和CLOS(Common Lisp Object System)的設計者都極度深受麻省理工學院/斯坦福大學(MIT/Stanford)設計風格的影響。這種風格的本質可以用“正確的做法(the right thing)”這個短語來概括。對于這樣的設計者，重要的就是要遵循下面的這些設計理念：
簡單性—設計必須簡單，這既是對實現的要求，也是對接口的要求。接口的簡單要比實現的簡單更加重要。
正確性—設計在任何值得注意的方面都要保證正確。不正確是絕對不允許的。
一致性 — 設計必須保持一致兼容。設計可以允許輕微少量的不簡單和不完整，來避免不一致。一致性和正確性同等重要。
完整性—設計必須覆蓋到實際應用的各種重要場景。所有可預料到的情況都必須覆蓋到。簡單性不能過度的損害完整性。
我相信大部分的人都會同意，這些理念都是一些好的實施原則。我把采用這種設計哲學的方法叫做“麻省理工方法(MIT approach)”。Common Lisp(包括CLOS)和Scheme代表著麻省理工方法的設計和實現。
“差點的更好(Worse is Better)”的理念只是稍微有點不同：
簡單性—設計必須簡單，這既是對實現的要求，也是對接口的要求。實現的簡單要比接口的簡單更加重要。簡單是設計中需要***重視的因素。
正確性—設計在任何值得注意的方面都要求正確。為了簡單性，正確性可以做輕微的讓步。
一致性— 設計不能過度不兼容一致。為了簡單，一致性可以在某些方面做些犧牲，但與其允許設計中的這些處理不常見情況的部分去增加實現的復雜性和不一致性，不如丟掉它們。
完整性 — 設計必須覆蓋到實際應用的各種重要場景。所有可預料到的情況都應該覆蓋到。為了保證其它幾種特征的品質，完整性可以作出犧牲。事實上，一旦簡單性受到危害，完整性必須做出犧牲。一致性可以為實現的完整性作出犧牲;最不重要的是接口上的一致性。
早期的Unix和C語言是使用這種設計理論的代表，我把采用這種設計策略的方法叫“新澤西方法(New Jersey approach)”。我一直在有意的諷刺這種“差點的更好”理論，讓人們相信它顯然是一種不好的理論思想，新澤西方法就是一種不好的軟件實現方法。
然而，我相信，即使在一種假象的情況下，這“差點的更好”理論也要比“正確的做法”理論有更大的生存空間，也就是說，在軟件開發上，新澤西理論要比麻省理工理論更實用。
讓我來復述一個故事，向大家展示麻省理工方法和新澤西方法之間的真實區別，以及為什么各個理論的支持者都完全的相信他們的理論更好。
兩位著名的人物，一位是來自麻省理工，另一位來自伯克利學院(但是研究Unix的)。一次，他們遇到一起討論操作系統問題。來自麻繩理工的人對ITS(麻省理工學院人工智能實驗室的操作系統)非常熟悉，并閱讀過Unix的源代碼。他對Unix如何解決PC機的loser-ing問題非常有興趣。當一個用戶程序調用系統例程去執行一個長時間的、并包含有重要狀態的操作時，例如IO緩沖，loser-ing問題就有可能出現。如果在執行這個操作時，發生了中斷，用戶程序的狀態必須被保存下來。因為對系統例程的調用通常是單指令的，運行用戶程序的PC機無法捕捉到例程的過程狀態。系統例程要么退出，要么強行繼續運行。“正確的做法”是退出，復原用戶程序調用系統例程的指令，讓用戶程序在中斷之后能重新恢復運行，例如，重新進入系統例程。這被叫做“PC loser-ing”，因為PC機被強制進入一種“弱勢(loser)模式”，其中，“弱勢”者是麻省理工對“用戶”的一種愛稱。
麻省理工的人沒有看到有任何的用來處理這種情況的代碼，問新澤西人，Unix是如何處理這種問題的。新澤西人說，Unix人清楚這個問題，但提供的解決方式是針對系統例程通常能正常完成的情況的，當系統例程不能成功的完成運行時，它會返回一個錯誤碼，指示操作運行失敗。一個正確的用戶程序這時需要去檢查這個錯誤碼來決定是否需要再次調用這個系統例程。麻省理工人不喜歡這個解決方案，因為這不是“正確的做法”。
新澤西人說，Unix的解決方案是正確的，因為Unix的設計理論是追求簡單，而這“正確的做法”太復雜。除此之外的好處是，程序員能容易的添加這種錯誤探測，重復他們的操作。麻省理工人指出，這種實現方案確實簡單，功能性上的接口卻變的復雜。新澤西人指出，這就是Unix在設計上做出的合適的取舍。實現上的簡單比接口上的簡單更重要。
麻省理工人這時嘟囔著說：有時你需要讓一個強壯的人去變成一種軟弱的小雞。新澤西人沒明白他是什么意思(我也不太明白)。
現在，我開始主張“差點的更好”確實是更好。C語言是一種為開發Unix而設計的語言，它的設計采用的是新澤西方法。C語言因此是一種很容易就能寫出漂亮的編譯器的語言，它要求程序員編出的代碼要易于編譯器去解釋。有些人稱C語言為高級匯編語言。早期的Unix和C編譯器都非常的簡單，易于移植，需要很少的硬件資源來運行，它提供了你從一個操作系統和編程語言里想得到50%—80%的功能。
現有的機器有一半在任何方面都低于中等配置水平(更小，更慢)。而Unix和C語言在它們上面運行良好。“差點的更好”理論表明實現的簡單性具有***的優先級，這意味著Unix和C語言很容易在這些機器上進行移植。因此，如果任何一臺機器，Unix和C能在功能性上提供50%的支持，那它就會無處不在了。Unix和C就是這樣，不是嗎?
Unix和C語言是***電腦病毒。
“差點的更好”理論另外一個好處是，程序員可以有條件的犧牲某些安全性，方便性，全力去獲得優良的性能和較少的資源使用。使用新澤西方法開發的軟件既能在大機器上運行，也能在小機器上運行，程序具有很好的可移植性，這是因為它們是在一個病毒程序是寫出來的。
有一點很重要，初始病毒必須基本上好用。病毒的傳播由于它的可遷移性而得到保證。一旦病毒傳播開來，迎來的壓力會促使它進一步改進，促使增加功能至接近90%完備的水平，但用戶此時已經有條件的習慣了這種比“正確的做法”差一點的東西了。所以，“差點的更好”的軟件會首先獲得人們的接受，然后會有限制的讓用戶降低期望，***進行改進，直至接近“正確的做法”。在實際情況中，1987年的Lisp編譯器當時和C編譯器都是非常的優秀，但是很多的編譯器專家仍然努力讓C編譯器做的更好。
1995年的好消息是我們有了一個好的操作系統和編程語言;而壞消息是它們分別是Unix和C++。
“差點的更好”還有***一個好處。因為新澤西式的語言和系統不夠真正的強大來開發出復雜巨型的軟件，大型系統必須在設計上進行組件重用。因此，一種整合的傳統就此迅速出現了。
那“正確的做法”的表現如何呢?我們有兩種常見的模式：“復雜的大型系統”模式和“鉆石類珍寶“模式。
“復雜的大型系統“模式通常像這樣：
首先，”正確的做法“需要去設計。然后實現過程需要去設計。***，進行實現。因為這是”正確的做法“，它會提供100%預期的功能，實現的簡單性從來不是一個可考慮的因素，所以你要用很長的時間去完成它。它巨大而且復雜。它需要復雜的工具，工具需要能正確的使用。其中20%的功能會花去你80%的精力，所以，”正確的做法“需要很長的時間來完成，它的運行只有在采用先進技術的硬件上才會表現的令人滿意。
“鉆石類珍寶“模式通常表現如下：
”正確的做法“花了大量的時間去設計，但這種方式，在單個功能點上，其實并沒有占多大比重。這種設計的實現，如果想讓它運行的快，要么是根本不可能，要么是超出了大多數開發者的能力。
頭一種模式也是經典的人工智能軟件的開發模式。
”正確的做法“出來的通常是大型的軟件，但除了”正確的做法“會把軟件設計的巨大外，沒有其它的理由造成這種局面。也就是說，大型軟件里很多功能是偶然會用到的。
從這些事情中我們學到的知識是，人們通常不喜歡按照”正確的做法“做事。但你***要采納一半的”正確的做法“，讓你的軟件能像病毒一樣流傳。一旦人們被它吸引，花時間去改進它，使它接近90%的”正確的做法“。
一個錯誤的認識是只理解表面意思，認為C語言是開發AI軟件有力的武器。50%正確做法的方案平常是可行的，但AI上不行。
但是，有一點我們可以下結論，Lisp社區真的需要認真的反省一下他們在Lisp設計上的立場。我會在以后更多的談論這個問題。
原文：http://www.aqee.net/2011/07/18/the-rise-of-worse-is-better/
【編輯推薦】
