我在上個月看 Discovery 節目時,該節目很有趣,是介紹有史以來,前 10 大受歡迎與戰鬥力強的坦克車。
嗯,還是從二次大戰開始介紹的呢,其中,包括德國的虎式與豹式坦克,都名列上榜,而更為驚人的是,蘇聯的 T34,當時在德蘇大戰中叱吒風雲,令德軍第一次感受到他們的武器不如人,是名列 10 大中的第三名。而至於第二名的坦克,則是活躍於波灣戰爭中,但卻也有令人苦惱的問題,太過龐大與吃油量太重、維修不易等問題。
嗯,這要與我談軟體模組化有何關係呢? 嘿,當我看到榮登 Discovery 第一名排行榜的坦克時,實在驚訝與讚嘆不已。榮登第一名的是:改良過的德國製坦克 — 豹式二代。
話說原來,當時二次大戰中,德軍鑑於蘇聯 T34 的優異與靈活又兼顧火力的性能,而加以參考並改造他們的坦克,當時就有豹式坦克的出現。但是,豹式坦克雖性能優異,且砲火猛烈,但是,太容易故障了,而德國人龜毛完美的性格也反映在該坦克上,加上太多不必要的束縛與修飾,而這些,是在激烈的對戰中,大部分是不需要的。
而今的豹式二代,仍然呈現著豹式一代優異的性能與保持了德國人求完美的設計性格,但卻改善了最重要的一點 — 快速維修與保養的能力。怎麼作呢?在所有前 10 大坦克中,也只有豹式二代具有現今結合硬體與軟體的彈性設計 — 模組化!
我看了節目的展示,嘴巴合不攏嘴,實在驚訝不已。豹式二代一旦發生故障,維修人員只要拿出筆記型電腦,連結坦克的介面,即可以診斷出坦克的那一部分出了部分,再來呢,不是去拆開出問題的那一部份,而是,整個模組抽出來,就好像診斷出 PC 的顯示卡或記憶體模組出問題後,拔出來,再把新的給置換進去即可。我第一次看到,坦克的模組化設計,也能造成這種 P&P(Plug-and-Play) 的可抽換效果。
回歸軟體,看到好多產品都號稱是 “模組化” 的設計,每次呢,我到世貿軟體應用展,只要問展示販售 “進銷存” 產品的廠商,能否將 “進貨” 模組,與某家或是本來公司內部既有的 “存貨” 系統給 “兜” 在一起呢? 嘿,得到的解決方案就是利用 “資料庫” 來作系統整合。
而以資料庫為整合的解決方案,我就很清楚了,這些號稱是模組化,根本只是在業務層級的邏輯面,卻沒有確實在實體的系統面,達成模組化的設計。若要能達成在實體系統面的模組化設計,必然是首重於介面(Interface)的設計與溝通,至於資料庫,只是各個模組的 “私有倉儲(private storage)” 罷了。以資料庫為主的整合,是屬於 “草本植物” 式的整合,雜草叢生,而根卻早已彼此糾纏不清,剪不斷、理還亂了。
連龐然大物般的坦克車都可以確時達成模組化的設計,怎麼這些軟體產品,談模組化這麼久了,卻仍是用幼稚的資料庫整合方式,而無法確實分隔每個可被抽離與置換的模組,並且可以很容易地利用測試工具找出是那個模組出問題,乾脆就直接把壞的模組給 “抽換” 掉呢?
可否推薦一些世上軟體設計的規劃上的經典之作?
“Design Pattern” 不就是最為經典的軟體設計之作嗎? 🙂
Web Service ?
Web Service 是實現的手段之一。 真正的重新在於軟體設計的規劃上。
Hi Jason:
介面的標準化可說是會推往的方向。
不過,我是覺得,還有一樣比較重要的就是,軟體人員要能慢慢體會介面的設計之優美,這更是重點。
介面的標準化??
>整合需要的是模組化加上”標準”
非常贊同您的意見!!
“標準化而能造成的可替代性”,這句話非常有道理。