軟體的病態性肥胖(2) 別讓開發過程的小細節，造成軟體的負擔

上回談到的框架、生產力觀念、彈性，是軟體肥胖的大環境問題，這回則補充哪些程式設計常見的思考模式與做法，也會間接造成軟體體積的負擔。

● 為了提高相容性：有些套裝軟體由於使用族群太廣，所以必須考量使用者的各種需求而提高相容性，可能的作法有：能夠打開20年前的廢棄檔案格式，可以開啟競爭對手不斷推出的新格式，可以支援各種古代電腦周邊設備、奇特的鍵盤配置，或是提供失能人士無障礙的操作介面（Accessibility）。

透過提高相容性來滿足大家的需求，似乎很可取，但也無法避免軟體複雜度和體積暴增的後遺症。關於這一點，還是要考慮到80/20法則，太離譜的相容性支援，做成插件（plug-in），不要直接整合進系統中，會是比較好的做法。

● 舊的設計不好，不能拿掉，只會加上新的：很多時候，當我們發現開發出來的軟體設計上有問題時，程式碼已經盤根錯節無法修改，一旦修改便會造成既有使用者不相容的困擾。例如，許多程式語言原本不支援Unicode，為了要支援Unicode，又不想全面修改String型別（因為既有的開發者會反彈），於是會提供新的Unicode型別。

為了徹底解決這類問題，語言設計者往往會推出大升級版本的分支（主要版本號碼提升一個數字），例如D 2.0語言、Python 3.0、REBOL 3.0都是這樣的分支，新分支和舊分支並行前進，新版本分支可以進行大翻修甚至重頭開始，而舊版本分支則繼續進行bug修正的維護與升級。

● 大量使用外部套件：由於開放程式碼與免費程式庫盛行，現在許多軟體開發都會大量使用外部套件，以提升開發速度，避免重新發明輪子，但是連鎖相依的副作用也就伴隨而來：嫁進家門的不光是你老婆，還包括她的一群遠房親戚，食指浩繁，讓你吃不消。

舉例來說：你只有使用套件A，但是套件A有使用到套件B和C，而套件B與C又用到其它套件，導致你需要的套件數量大增，軟體體積自然也大增。你要知道，這些套件都設計得相當泛用，畢竟不是專為你設計的，所以每個套件體積都不小，有一大堆你用不到的程式碼。

● 忽略物件導向的可能問題：有些國家的人民普遍肥胖，有些國家的人民則普遍偏瘦，這和他們的飲食環境有關。在軟體開發界，採用OO（Object Oriented，物件導向）飲食法的軟體通常都不瘦（但我還是有看過極少的特例），程式執行時，記憶體耗費更是可觀。物件導向程式很難減肥成功，因為這似乎已經是基因的問題了。

● XML：XML到處可見，用它標示文字資料，甚至用它標示原本是binary的資料，甚至用它標示不是資料（例如程式）也開始流行起來，設定檔（configuration）更是幾乎全面XML化。XML確實有其優點，但是它的缺點也不少，最嚴重的或許就是：它讓資料量不必要地暴增。

● 攜帶各種編碼表與字型：有的程式為了避免任何閃失，會自行攜帶各種編碼轉換表和字型，Java虛擬機器就是這樣的例子，但是，編碼表和字型的檔案往往都很大，也因此加重不少軟體體積。

從源頭下手，改造軟體體質
多年前的一部得獎記錄片《Super Size Me》（麥胖報告），裡面實際記錄一個人連續一個月天天吃速食後，導致整個人爆肥，而且健康檢查的各種指標都出問題。這部片讓許多肥胖人士看了之後，心生警惕。

身處軟體界的我們，也應該注意Super Size Me的問題。軟體要如何減肥？多吃粗糙食物（例如Win32），少用精緻的食物（例如.NET）；多攝取DSL，少攝取OO；時時刻刻注意是否有局部發胖的情形；少用XML與程式碼產生器；相容性的部分用轉檔解決，轉檔的部分做成軟體服務或下載套件；多攝取「綠色食物」，少攝取「肥肉」，以鼓勵廠商生產綠色軟體（你可以上網查一下綠色軟體的定義）。

看了上面這些建議，你可能覺得實在不容易做到，甚至不切實際。嘿！哪個營養師開出來的減肥計畫會讓你說：「這很簡單，我做得到？」增胖容易，減肥難呀！當然，很多時候，開發時程與成本等考量比軟體體積更重要，所以，你可能會兩手一攤，說：「胖！就給它胖吧！」

或許我不該在這裡提起軟體肥胖的話題，畢竟胖才是美已經成了軟體界普遍的審美觀。「不重則不威」，許多顧客買了我們的軟體之後，拿到好幾片滿滿的光碟，安裝需要耗費一整個下午的時間，顧客反而會覺得這個軟體很有價值。如果只給一個不到1 MB的檔案，顧客還會質疑這小玩意值不值得這價錢？軟體終究還是逃不了秤斤論兩的命運呀！

作者簡介：
蔡學鏞－技術顧問
清華大學資訊工程碩士，曾任華碩集團軟體工程師、元智大學資訊系講師、美商歐萊禮出版社技術編輯、臺灣微軟特約專欄作家。