隨著對能應付日益增長的各種信息處理任務的軟件系統需求的增長，找到能降低新的代碼項目的生產成本的辦法對軟件公司是一種誘惑。最明顯的辦法之一是提高其它項目的代碼的可重用程度。
在程序員設計一個新系統時，由此出現的更常見的問題中的兩個是：
系統應該有多大的可擴展性？
我能使系統具有多大的可擴展性？
如果原始系統被設計成可擴展的，那麼重用代碼是最佳的辦法。否則，重用代碼時碰到的困難可以容易地抵消任何已獲得的生產率。但是，要設計成可擴展的，在軟件設計中就要考慮各種各樣的新問題。
我將在本文討論一些辦法，這些辦法能使一個軟件系統對將來的項目是可擴展的。
忠告
在進行任何努力之前，請讓我澄清一下，我不是主張在所有情況或者甚至大多數情況下都為了可擴展性進行設計。有利於許多設計的可擴展性選擇常常會妨礙其它需要考慮的因素，例如性能或可測試性。可測試性最好的系統常常也是最簡單的系統，但可擴展性設計卻常常會大大增加系統的復雜性。
幸運的是，也有可擴展性最好的設計也是最簡單的設計的時候，但能兼顧二者的時候真是太少了。
因為這個原因，我建議只在您能肯定得益會大於花費時才采用可擴展性策略。這通常意味著您 知道系統將會被以一定的方式擴展。
在極端編程著作中，常常把可擴展性的收益和購買股票期權相比較：您早先購買了期權，因此在將來您可以容易地擴展系統。如果最終您行使了這一期權，則可以獲利頗多。
但如果您從未行使這一期權，則您將損失掉期權的價格並且沒有任何回報。所以，“買主須謹慎！”
下面，我們來看看術語 可擴展性的各種定義方式。當討論程序的可擴展性時，我們所指的本質上有三種不同類型 ― 黑箱可擴展性和兩種類型的 白箱可擴展性。圖 1說明了可擴展性類型的差別。
黑箱可擴展性
黑箱可擴展性是指這樣一種方式：不直接擴展原始代碼即可擴展程序。這通常通過使用配置語言或向導來完成，向導引導您完成對系統的擴展。
稅務程序就是一個示例，這個程序包含一種配置語言，用於指定各種稅務申報表。當政府發布新的稅收申報表時，只需通過用配置語言說明新的稅收申報表的結構即可擴展該系統。
黑箱可擴展性最適合用於研究這樣的專有組件和框架，這裡原始開發小組的業務模式要求兩條：
程序是專有的（非開放源代碼）
外界開發者在定制組件的功能性方面有一定程度的靈活性
支持用戶定義腳本或宏的程序（如 Emacs、MS Office 等等）就是具有黑箱可擴展性的系統的示例。
白箱可擴展性
白箱可擴展性，相反地，是指可以通過修改或添加源代碼對程序進行擴展的方式。我喜歡把白箱可擴展性區分為兩個子類型： 開放箱和 玻璃箱。
開放箱可擴展性
當允許對原始源代碼進行修改時，我稱這個系統是開放箱可擴展的。當然，原則上說，這樣的程序可以任意擴展，但不是所有的擴展難度都一樣。
對開放箱可擴展性的研究主要涉及在必要的時候如何在給定的修改程序能力下使各種各樣的擴展更容易。這種形式正是與開發小組在生產他們自己產品的下一版本時關系最大的可擴展性形式。
在有些情況下，這種類型的可擴展性也是想利用現有的開放源代碼軟件的開發者的興趣所在。但以這種方式擴展開放源代碼系統會碰到諸多問題。
最大的問題是當“官方”維護小組決定發布該軟件的一個新版本時該怎麼辦。把他們的更改和您的更改熔合起來可能既困難又費時。即使該系統是充分模塊化的，足以使您已更改的實際代碼也不沖突，要確保新代碼預設的不變量未被您的更改破壞掉也是困難的（盡管如果代碼帶有單元測試，這個問題可以得到很大改善）。
玻璃箱可擴展性
玻璃箱可擴展性是指這樣一種方式：當可以查看源代碼，但不能修改時，用此種方法可以擴展軟件系統。
因為上面所討論的涉及改動外界維護的開放源代碼代碼的問題，所以在任何有必要的時候對這種代碼只使用玻缡箱擴展是明智的。流行的、玻璃箱可擴展的系統的一個很棒的示例是 JUnit。每一個單元測試都可看作是原始代碼基礎的一個擴展。
圖 1. 每種方式由代碼對擴展者有多大的可訪問性決定
關於箱的更多內容
這些不同類型的可擴展性各適用於一定的環境，其中的一些環境我已經談到過。例如，在專有軟件允許“外界”開發者對程序進行擴展（但不允許查看底層代碼）的情況下，黑箱方案是合適的。
當要將底層代碼開放以進行查看或修改時，白箱方式中的一種是合適的。
每一種情形，當然，都有它自己衍生的軟件設計方面的問題。此外，在一個給定的系統中，可能會用到不止一種可擴展性形式。
在下一部分中，我將繼續這個討論，研究與白箱可擴展性有關的問題。在以後的文章中，我將剖析使用多種可擴展性類型的系統的示例。
