莊周夢蝶

    入這行也有四年了，從過去對軟件開發(fā)的懵懂狀態(tài)，到現(xiàn)在可以算是有一個初步認識的過程，期間也參與了不少項目，從一開始單純的編碼，到現(xiàn)在可以部分地參與一些設計方案的討論，慢慢對設計方案的評判標準有一點感受。讀軟件工程、架構(gòu)設計、模式之類的書，對于書中強調(diào)的一些標準和原則的感受只是感官淺層的印象，你可以一股腦從嘴里蹦出一堆詞，什么開閉原則、依賴倒轉(zhuǎn)、針對接口編程、系統(tǒng)的可伸縮性、可維護性、可重用等等，也僅僅停留在知道的份子上。不過現(xiàn)在，我對一個設計方案的評價標準慢慢變的很明確：簡單、符合當前和一定預期時間內(nèi)的需求、可靠、直觀（或者說透明）。
   簡單，不是簡陋，這是廢話了。但是要做到簡單，卻是絕不簡單，簡單跟第四點直觀有直接的關(guān)系，簡單的設計就是一個直觀的設計，可以讓你一眼看得清的設計方案，也就是透明。一個最簡單的評判方法，你可以講這個方案講給一個局外人聽，如果能在短時間內(nèi)讓人理解的，那么這個方案八成是靠譜的。記的有本書上講過類似的方法，你有一個方案，那就拿起電話打給一個無關(guān)的人員，如果你能在電話里說清楚，就表示這個方案相當靠譜，如果不能，那么這個方案很可能是過度復雜，過度設計了。
   簡單的設計，往往最后得出的結(jié)果是一個可靠性非常高的系統(tǒng)。這很容易理解，一個復雜的設計方案，有很多方面會導致最后的實現(xiàn)會更復雜：首先是溝通上的困難，一個復雜的方案是很難在短時間內(nèi)在團隊內(nèi)部溝通清楚，每個開發(fā)人員對這個方案的理解可能有偏差；其次，復雜的方案往往非常考驗設計人員和開發(fā)人員的經(jīng)驗、能力和細致程度，復雜的方案要考量的方面肯定比簡單方案多得多，一個地方?jīng)]有考慮到或者不全面，結(jié)果就是一個充滿了隱患的系統(tǒng)，時不時地蹦出一個BUG來惡心你，這并非開發(fā)人員的能力問題，而是人腦天然的局限性（天才除外，咳咳）。
   第二點，符合當前和一定預期時間內(nèi)的需求。我們都知道，不變的變化本身，指望一個方案永久解決所有問題是烏托邦的夢想。復雜方案的出爐通常都是因為設計人員過度考量了未來系統(tǒng)的需求和變化，我們的系統(tǒng)以后要達到10倍的吞吐量，我們的系統(tǒng)以后要有幾十萬的節(jié)點等等。當然，首先要肯定的是對未來需求的考量是必需的，一個系統(tǒng)如果實現(xiàn)出來只能應付短時間的需求，那肯定是不能接受的。但是我們要警惕的是過度考量導致的過度復雜的設計方案，這還有可能是設計人員“炫技”的欲望隱藏在里頭。這里面有一個權(quán)衡的問題，比如這里有兩個方案：一個是兩三年內(nèi)絕對實用的方案，簡單并且可靠直觀，未來的改進余地也不錯；另一個方案是可以承載當前的幾十倍流量的方案，方案看起來很優(yōu)雅，很時尚，實現(xiàn)起來也相對復雜。如何選擇？如果這個系統(tǒng)是我們當前就要使用的，并且是關(guān)鍵系統(tǒng)，那么我絕對會選擇前一個方案，在預期時間內(nèi)去改進這個方案，因為對于關(guān)鍵系統(tǒng)，簡單和可靠是性命攸關(guān)的。況且，我堅定地認為一個復雜的設計方案中絕對隱藏著一個簡單的設計，這就像一個復雜的數(shù)學證明，通常都可以用更直觀更簡單的方式重新證明（題外話，費爾馬大定理的證明是極其復雜的，現(xiàn)在還有很多人堅信有一個直觀簡單的證明存在，也就是那個費爾馬沒有寫下的證明）。最近我們的一個方案討論也證明了這一點，一個消息優(yōu)先級的方案，一開始的設想是相對復雜的，需要在存儲結(jié)構(gòu)和調(diào)度上動手腳，后來集思廣益，最后定下的方案非常類似linux的進程調(diào)度策略，通過分級queue和時間片輪詢的方式完美解決了優(yōu)先級的問題。這讓我想起了軟件開發(fā)的“隱喻”的力量，很多東西都是相通相似的。
   上面這些亂彈都是自己在最近碰到的一些討論和系統(tǒng)故障想起的，想想還是有必要寫下來做個記錄。