軟體設計需要有一點曆史觀

軟體設計需要有一點曆史觀

吳旻

泰岩網路工作室

 

         國慶假期去看了一下趙州橋，就是我們小學課本中描述的，那座已經存在了1400多年的石拱橋。

         更精確一點的說法是，趙州橋建於公元605年，距今1407年。其間，經曆了10次水災，8次戰亂和多次地震；橋建成至今共修繕9次，平均150多年維修一次（注意，不是重建）。

說實話，我太喜歡趙州橋這種簡單而又實用的設計了。讓我用對比的方式解釋一下這座橋的技術優勢。

一、圓弧設計。這是相對於半圓設計來說的，意思就是橋面比較平坦，上橋容易，下橋簡單。典型的半圓設計是園林景觀中的“小橋流水”裡的小石拱橋，僅限於特定環境中的美觀，實用那就是有那個意思就行了。而趙州橋的圓弧設計，在使用上已經接近於現代的平面橋面了。

二、單孔拱橋。見過頤和園的17孔拱橋的就明白了，那個橋下是很難通過大一點的船隻的。而趙州橋則不然，因為沒有更多的橋墩，所以幾乎對通航沒有任何影響；同時也意味著河水對橋的衝擊也更少些。

三、敞肩拱橋。這是相對於實肩拱橋來說的。拱橋的“肩”指的是橋的兩端與河岸相連的部分，在趙州橋的照片上，就是兩邊各有的一大一小2個“n”型的橋孔的地方。如果沒有這些孔，那就是實肩了。敞肩的優勢非常明了，建橋時省材料，發洪水時增大泄洪量，當然也有人認為如此這般橋的外觀更漂亮一些。

四、使用腰鐵和鐵拉杆使橋更穩定。在橋長的方向上，使用了腰鐵把石塊固定住；在橋寬的方向上（即河流的方向上），使用鐵拉杆來固定橋身。縱橫兩個方向上，都確保了橋身在受外力衝擊時不會散架。通俗一點的比喻就是，在橋建好後，又用“繩子”把建橋用的石塊捆綁得更結實了。

 

         本質上，我是一個喜歡簡單實用設計的人。在我看來，優秀而又簡單實用的設計，常常透著某種大氣，並且包含著一種能讓我驚歎的美。那些看似簡單的背後，其實是無數複雜而又精確計算的結果，是化繁為簡的神奇，是深刻理解萬事萬物本質的洞察，是對宇宙無窮變化歸類後的抽象層面的精準拿捏。

 

好了，讓我們來談一談軟體設計。其實，要把軟體往複雜了設計並不難，難的是把複雜的羅吉斯迴歸於一種簡單與實用。比如，SQL類型的關係型資料庫其實就是在挑戰人類處理複雜問題能力的極限；直到有一天NoSQL這種非關係型的資料庫的出現，直白的告訴我們，非關係型資料庫的簡單與實用多麼讓人驚歎。

應該說，代碼一定會越寫越多；但我也強烈反對代碼“越寫越多”。其實，這是兩種完全不同的“越寫越多”：前者是強壯，是必要的“肌肉組織”；而後者則完全是因為“肥胖”，是輕而易舉就會引起高血壓、心臟病的“肥胖”！

我們的代碼和設計，應該是儘可能的不產生或者少產生“肥肉”，並且同時多產生“肌肉”。也只有這樣的代碼和設計，才能經得住時代的考驗。把“肥肉”變成“肌肉”，其實就是一種優雅而又美觀的實用，並且看起來也足夠簡單。

這不容易，這真的非常不容易。現代的應用軟體開發，更多的還是搭建，甚至是快速搭建。不是經常可以看到類似如下的廣告詞嗎？“使用我們的開發平台，可以讓您快速搭建應用，幫您捕捉稍縱即逝的商業機會！”

搭建真的很容易，但也真的很難設計，所以才會有12306.cn的是是非非。

其實搭建依然可以有很優秀的設計，而且可以優秀到1400多年依然讓人有所借鑒與思考，比如說，趙州橋！看過了你就會明白，趙州橋就是用石塊搭建出來的，輔之以極少量的金屬鐵。

 

如果我們開發設計的軟體，前輩人看了說：垃圾；同時代的人看了說：垃圾；我們後輩的人看了還說：垃圾！想想，我們該有什麼感覺。

如果我們開發設計的軟體，前輩人看了說：有創新；同時代的人看了說：很好用；後輩人看了說：值得參考。想想，這時我們又會是什麼感覺。

         所謂曆史觀，就是前人會怎麼看我們，同時代的人會怎麼看我們，我們的後輩會怎麼看我們。