軟件的極簡主義

最近在公司同時帶了好幾個項目，在開發過程當中總會遇到不一樣的需求而後不斷的修改，最後回過頭來對比最初的項目設計發現一個很小的項目最後居然變得如此之複雜，冗餘的API和大量複雜的接口。

而這一切就是爲了知足不一樣的客戶需求，下降客戶的使用成本。可是這樣的設計最終會是一個軟件面臨死亡（複雜過分以致於在重構的代碼大大增長）。

反思本身所帶的項目內容和開發現狀，我想到了一個詞－－－軟件的極簡主義

軟件的極簡主義，雖然目前沒有明確的定義，就看成是個人瞎想吧。

通常認爲「極簡主義」是設計界的一種風潮，可是軟件發展至今，好像也漸漸有了這樣的趨勢，甚至我認爲這是將來的必然，咱們常常聽人說「flexible」這個詞，字面上來看就是「靈活的」，可是具體到這個軟件是否靈活，就不太好判斷了。

可是，簡單的軟件，必定是靈活的。

極簡主義的的大敵

軟件極簡主義的三個大敵：配置文件，冗餘的參數，和大量複雜的接口。

不少人熱愛配置，迷戀配置，認爲越多的配置項意味着軟件越強大，適用範圍越廣，但這是九十年代的事了。實際咱們仔細翻翻經常使用的軟件，90%的配置都是多餘，沒有人明白他是作什麼的，也沒有人但願去改變他。比方不少軟件的configure文件，經常能列出上百個配置項，可是咱們真的須要這麼多嗎？不，咱們須要默認的那些值就好了。何謂默認？由於軟件的設計者以爲這些是最優化也最有可能被選擇的配置，那麼既然是最優配置，咱們又有什麼理由去改變他們？

再說說冗餘的參數，linux中有一個很是強大的命令’tar’，從man文件看來他起碼有二十來個參數，可是我真的須要這麼多參數嗎？其實我只要記住壓縮是-c，解壓是-x就能夠了，那麼何須爲了1%的功能而去加上這99%的參數呢。

最後是複雜的接口，舉個栗子，全文搜索引擎solr很是強大，能知足咱們對於文檔索引的各類需求。可是他使用起來可不簡單，緣由我想就是由於他那種sql式的查詢接口，把一件很單純的事情搞複雜了。咱們來設想一下，須要找出包含某幾個關鍵詞的文章，必要的條件是什麼？關鍵詞，文檔，沒了。而文檔是存儲在服務器的，爲何咱們提供了關鍵詞以後，仍需加上各類條件，他才能告訴咱們想要的答案呢？我想軟件發展到必定的智能，他就應該像一部能說話的百科全書，提問，而後告訴咱們答案便可。

凡事都要對比着看，因此咱們找點軟件來對比一下。

redis 與 sql

redis很靈巧，全部源代碼加起來不滿5M，可是他很強大，hash結構能取代咱們80%對於sql的需求。他也有配置文件，可是選項不多，並且每一項都有詳盡的註釋，而且使用默認配置就能夠應對大部分的狀況。惟一值得詬病的就是他的接口種類繁多，但好在這些接口頗有規律可循，你只需瞭解了redis的基礎數據結構，那麼跟着官網的文檔就很容易搞懂全部接口的用途，並且大部分的接口都只接受3個之內的參數，這可好記多了。我剛接觸redis的時候，只花了半個小時就能玩得起來，我想面對sql恐怕沒人能這麼輕鬆的掌握吧。

zmq 與 rabbitmq

zmq是我見過的最具備極簡主義風格的軟件（組件）。一方面他要面對的任務很是繁雜，在異步通訊中全部咱們可能遇到的狀況，他都爲咱們考慮到了，可是他又將底層的複雜問題掩蓋起來，讓咱們看到一個光滑的表面，深藏功與名。一樣來看看他的同行rabbitmq，關鍵詞：中心服務，多線程，模式單一，最後一個特色，慢！而僅有1.7M的zmq，快是最直觀的感受，而分佈式和擴展性則是錦上添花。有人說zmq就像樂高積木，每一個人都能搭出他想要的形狀，這話一點都不錯。

結語

軟件的設計突飛猛進，未來確定會接觸到更多優秀的軟件，也許哪天我想法變了，也許哪天遇到了更神奇的方案，可能我會補充在這裏。