軟體的模組化(Modulize)設計應該要徹底實踐！
我在上個月看 Discovery 節目時，該節目很有趣，是介紹有史以來，前 10 大受歡迎與戰鬥力強的坦克車。
嗯，還是從二次大戰開始介紹的呢，其中，包括德國的虎式與豹式坦克，都名列上榜，而更為驚人的是，蘇聯的 T34，當時在德蘇大戰中叱吒風雲，令德軍第一次感受到他們的武器不如人，是名列 10 大中的第三名。而至於第二名的坦克，則是活躍於波灣戰爭中，但卻也有令人苦惱的問題，太過龐大與吃油量太重、維修不易等問題。
嗯，這要與我談軟體模組化有何關係呢？ 嘿，當我看到榮登 Discovery 第一名排行榜的坦克時，實在驚訝與讚嘆不已。榮登第一名的是：改良過的德國製坦克 — 豹式二代。
話說原來，當時二次大戰中，德軍鑑於蘇聯 T34 的優異與靈活又兼顧火力的性能，而加以參考並改造他們的坦克，當時就有豹式坦克的出現。但是，豹式坦克雖性能優異，且砲火猛烈，但是，太容易故障了，而德國人龜毛完美的性格也反映在該坦克上，加上太多不必要的束縛與修飾，而這些，是在激烈的對戰中，大部分是不需要的。
而今的豹式二代，仍然呈現著豹式一代優異的性能與保持了德國人求完美的設計性格，但卻改善了最重要的一點 — 快速維修與保養的能力。怎麼作呢？在所有前 10 大坦克中，也只有豹式二代具有現今結合硬體與軟體的彈性設計 — 模組化！
我看了節目的展示，嘴巴合不攏嘴，實在驚訝不已。豹式二代一旦發生故障，維修人員只要拿出筆記型電腦，連結坦克的介面，即可以診斷出坦克的那一部分出了部分，再來呢，不是去拆開出問題的那一部份，而是，整個模組抽出來，就好像診斷出 PC 的顯示卡或記憶體模組出問題後，拔出來，再把新的給置換進去即可。我第一次看到，坦克的模組化設計，也能造成這種 P&P(Plug-and-Play) 的可抽換效果。
回歸軟體，看到好多產品都號稱是 “模組化” 的設計，每次呢，我到世貿軟體應用展，只要問展示販售 “進銷存” 產品的廠商，能否將 “進貨” 模組，與某家或是本來公司內部既有的 “存貨” 系統給 “兜” 在一起呢？ 嘿，得到的解決方案就是利用 “資料庫” 來作系統整合。
而以資料庫為整合的解決方案，我就很清楚了，這些號稱是模組化，根本只是在業務層級的邏輯面，卻沒有確實在實體的系統面，達成模組化的設計。若要能達成在實體系統面的模組化設計，必然是首重於介面(Interface)的設計與溝通，至於資料庫，只是各個模組的 “私有倉儲(private storage)” 罷了。以資料庫為主的整合，是屬於 “草本植物” 式的整合，雜草叢生，而根卻早已彼此糾纏不清，剪不斷、理還亂了。
連龐然大物般的坦克車都可以確時達成模組化的設計，怎麼這些軟體產品，談模組化這麼久了，卻仍是用幼稚的資料庫整合方式，而無法確實分隔每個可被抽離與置換的模組，並且可以很容易地利用測試工具找出是那個模組出問題，乾脆就直接把壞的模組給 “抽換” 掉呢？
阿富
關鍵在於”利益”二字,
基於利益就會產生私心,
德國與美國的坦克可能模組化互相使用嗎? 不可能!
不只是軍事上的機密, 更重要的是在於利益上的衝突, 兵工廠的利益多驚人啊!!
相同的, 軟體可能模組化到互相抽換使用嗎?
只要牽扯到利益, 事情就永遠不會這麼單存.
111
在概念、設計跟後續的使用上，硬體跟軟體都有著本質上的不同。坦克跟軟體比起來，不算是複雜的東西，看過幾部電影跟幾個模型的孩童，都可以對坦克的功能說上幾句，但他對稍具商業用途軟體的理解就完全不可能如此，這點大人也好不到哪裡去。
坦克的演化也比軟體久得多，功能介面大抵都已經很清晰，變動性跟軟體完全不能比。一部坦克開始服役後，也許可以用個 10 年甚至更久，如果沒有大 bug，中間幾年僅會『小改版』，跟汽車一樣（尤其這類硬體都有安全性考量，所以更不輕言改版）。但軟體，尤其是客製化產品或專案，極少可能這麼久都不變動。
軟體模組化（元件化）是典型知易行難的問題，說穿了還是成本考量，而且要各方配合：
必須要有最高管理階層長期的支持（這一句是政治廢話，以下才是真章）；
必須要有專職的元件總設計師、元件程式設計師、元件測試工程師、說明文件設計工程師（到 104 找找看有沒有這種職務，到各大補習班找找看有沒有這種課程）；
必須要有客戶或使用者長期而頻繁的參與（這一點最難掌握，但效益最大，可以用減價當誘因，因為客戶參與也要花他們自己的成本）；
必須要培養程式設計師樂於使用元件的習慣跟文化（不要文人相輕）；
如果有蓬勃的商用元件市場，那就更好了（國外有，但本地很多程式設計師的英文不夠好）。
…
在國際級的軟體大廠中，上述條件或許都成立，但克明兄逛到的國內進銷存軟體廠商，大概只有第一條成立 — 而且極可能成立在大老闆的口惠上，亦即，嘴巴上說支持，但完全沒有做到。
大老闆一定也會跟你說，生存都不易了，還搞這些東西幹嘛？他說的也沒錯，所以，到底是哪個環節出了問題呢？我對此現象也一直感到困惑。
我以前有個朋友在一家轉搞軟體元件的公司，但該公司在軟體元件這一塊沒幾年就銷聲匿跡，銷聲匿跡之前也沒聽過接到什麼像樣的軟體元件訂單。
所以最後的結論，就會是你現在看到的這個樣子，大家整合都用資料模型而不用物件模型，一份資料，各自表述，各取所需，搞到最後 SQL、XML 變成王道，就跟有些網站根本多數只用 HTML 而不用 ASP/JSP/PHP… 一樣。其實想想，規模不大的軟體用這種方式，好像～也沒什麼錯啦！殺雞何必用到牛刀呢？
同人
整合並非不可行，重點您是以什麼觀點來看設計。如果您把方便整合的觀念溶入設計中，您會設計減震點(Decouple point)，把模組化與差異化的部分巧妙地隔開，這種設計策略就是所謂的延緩策略(Postponement)，好處是可能待需求確認後才開始實始生產差異化的部分，而共用的模組則可以重覆使用增加開發績效，縮短開發時間及成本。其實就是所謂的(DFx,Design for ＸＸＸ），例如克明兄所說坦克的例子就包含了Design for maintenance的設計概念。
所以軟體開發能如果做到元件模組化，服務差異化，那整合一點都不困難。可惜大部分的公司都是反其道而行－元件差異化，服務模組化。結果反而造成系統變得更複雜，整合更加困難。
其實不做整合的主要的原因還是市場利基及公司策略方向，如果人家很容易把我整合進去，那我還有什麼搞頭，當然要把系統弄得別人很難整合進去。但標準化，同步工程及整合是不可擋的趨勢，如果忽略它們，那未來將被新的浪潮所淹没。
Kenming Wang
Hi:
請問是我認識的那位賢智嗎？ 若是的話，請留個 Email 給我，好久不見啦。
我沒有說「整合兩家公司的模組」不可行，是那些賣進銷存系統公司所號稱的模組不可行喔。
後面你那句話太過牽強了，”讓德國的坦克用美國的模組行嗎”，你應該反過來說，美國的廠商是否有意願推出符合該坦克所需的料件？若有利可圖，那就需依循該坦克的模組規格。
這句話，”模組化，有時還是很抽象的東西”，就因如此，才會導致許多軟體公司所推出號稱的模組僅位於業務層面的泛稱而已。
實在感嘆，業界至今仍舊不重視介面的設計。
賢智
就如你所說的，整合兩家公司的模組不可行。同樣的，你讓德國的坦克用美國的模組行嗎？模組化，有時還是很抽象的東西。因為設計理念的複雜性，以及延伸整合，都會影響模組規格的設計。到最後，你會發現0,1是最後的可以被用的模組，但是已經沒有多大的用處了。