用Unix的設計思想來應對多變的需求

做者：陳皓  原文  　　以前，@風楓峯 在「這是誰的錯？」中說過開發團隊對需求來者不拒，而@weidagang 也在「需求變動和IoC」 中說過用IoC來最大程度地解決需求變動。今天我也想從Unix設計思想的角度來講說什麼是好的軟件設計，什麼樣的設計能夠把需求變動對開發的影響下降。（注意：這並不能解決用戶或是PM的無理需求，面對無理需求，須要仔細分析需求，而用技術的手段沒法搞定這個事，可是能夠減輕需求變動帶來的痛苦）   　　我曾經在《Unix傳奇》的下篇中寫過一些Unix的設計哲學和思想（這裏重點推薦你們看一下《The Art of Unix Programming》，我推薦過屢次了），之前也發過一篇「一些軟件設計的原則」，不過，這些東西都太多了，記不住。其實，這麼多年來，個人經驗告訴我，不管是Unix設計，仍是面向對象設計，仍是別的什麼如SOA，ECB，消息，事件，MVC，網絡七層模型，數據庫設計，等等，他們都在幹三件事——解耦，解耦，仍是解耦！所謂解耦，就是讓程序員的模塊和模塊間儘可能少地依賴起來。 現實當中的例子 讓我先舉幾個現實生活中的例子： 一、現實社會中，製造燈具的工廠徹底不關心製造燈飾的工廠，製造燈飾的工廠徹底不關心製造燈具的工廠，可是，燈具和燈飾能夠很完美地組合成用記所喜歡的樣子（這和@weidagang 在「需求變動和IoC」說到的那個PC的例子相仿）。他們是怎麼作到的？ 二、互聯網上，作網站的人徹底不用關心用戶在用什麼樣的操做系統，什麼樣的瀏覽器，反過來，上網的人也不關心作網站的人在用什麼的技術開發網站。可是你們在徹底不關心對方的狀況下，能夠很正常地協同工做在一塊兒。爲何？   這樣的例子太多了。爲何能夠作成這樣呢？由於你們依賴的是一個接口，燈具和燈飾並不互相依賴，他們依賴的是一個接口，作網站的人和瀏覽網站的人依賴的仍是接口——HTTP協議。這就是面向對象的核心思想——依賴於接口而不是實現，這就是觸耦。當你看過這兩個例子之後，我但願你之後設計的軟件至少不能比咱們現實社會中的這些方法要差。否則，你就是在讓社會倒退了，呵呵。 你會說，這和Unix，和應對需求變化有什麼關係？好讓咱們再來看一下Unix的設計。 Unix設計的例子 下面是幾個Unix下的例子： 一、Unix下，全部的硬件均可以經過文件的方式存取。其通通在/dev下。因而，軟件和硬件的耦合被解開了，操做系統只須要把硬件通通變成文件，而程序只須要使用三個東西，一個是fd，一個是read()，一個是write()，就能夠來操做任意的硬件了，這就是抽象，簡單到不行。 二、Unix下，全部的命令均可以用管道串起來（管道絕對是個偉大的發明），這樣，全部的命令間的交互所有解耦到只依賴於STD_IN, STD_OUT設備上。最酷的是，用戶可使用管道任意地拼裝那些命令，以完成各式各樣的功能。管道這個設計思想能夠映射爲今天的Web Service，你能夠任意地拼裝各類Web Service。 看到這裏，你會發現，這仍是解耦，本質上來講，也是一種依賴倒置——OOD的精髓。可是，Unix還不只僅是這些。咱們再來看幾個例子： 一、Unix下，軟件都是綠色地安裝。在iOS上更明顯——各個程序間基本上互不干擾，這個程序產生的垃圾文件不會影響到另外一個程序。你刪到一個程序不會讓另外一個程序不舉，各是各的空間。你能夠刪除這些程序，只要把內核心留着，系統照樣能夠啓動。 二、Unix下，你能夠經過設置一些環境變量，讓多種環境同時存在，好比：某個LAMP用的是Apache 2.0, Mysql 4.0, PHP 4.0，某個LAMP用的是Apache 2.2, Mysql 5.0，PHP5.3，你不但能夠方便地在系統中切換這兩個環境，你甚至還能夠同時啓動他們。 三、Unix下，你能夠隨意地替換你想要的程序。好比，你不喜歡bash，你能夠替換成ksh/csh等，你不喜歡awk，你能夠替換成gawk，全部的東西都像零件同樣，你不喜歡什麼，你就能夠替換什麼。 這三個例子告訴了咱們——當你把你的軟件設計地耦合度很是地低時，你能夠隨意地組合，隨意地安排你的系統。想當的靈活，靈活到Windows到今天都學不會。 應對需求變化 看到這裏，你可能明白我想說的是什麼了，你可能開始以爲怎麼樣的系統設計會更有效了。若是你還記得《Steve Y 對平臺的長篇大論》，你就會知道我想說什麼了。是的，我想說的就是，當你真正瞭解了Unix的設計思想後，你會以爲今天的這些東西都是對Unix設計思想的一種傳承或是變種。這種東西就是： 1）解耦，解耦，解耦。儘可能地讓你的模塊不要在實現上耦合，而是耦合某個規範，某個標準。 2）KISS，KISS，KISS。要作到高度解耦，你的模塊就必定要很簡單，固然不是說簡單到只有幾行代碼，而是簡單到只幹一件事，並把這件事幹到極致。而後經過某個標準拼裝起來。 3）拼裝，拼裝，拼裝。我想不起來是誰說的了，這句話是這樣的，當我想用一個模塊的時候，我直接調用就行了，沒有必要像C或Java同樣，還要編譯。是的，拼裝須要一個框架，須要一種標準協議，而後讓全部的系統都耦合在這種規範上，各自獨立運行，就像一個機器上的各個部件同樣，當我以爲這個部件不爽，換了就是了。（例如，當咱們在嘗試不用的算法的時候） 想一想建材和傢俱市場，不管用戶過來想裝修什麼，我均可以知足用戶的不一樣需求，只要你是和家裝相關，我基本上都能知足你，不是嗎？不管你怎麼變，只要不變態，我基本上均可以知足你。這就是解耦，拼裝帶來的好處。 你可能會說我說得太簡單了，另外一方面，你可能以爲有一些系統這樣作不必，我認可，不過，你能夠有選擇的或多或少地試試。（其實，我相信你已經在不自以爲或多或少地使用這種方式開發軟件了）