莊周夢蝶

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