随着对能应付日益增长的各种信息处理任务的软件系统需求的增长，找到能降低新的代码项目的生产成本的办法对软件公司是一种诱惑。最明显的办法之一是提高其它项目的代码的可重用程度。
在程序员设计一个新系统时，由此出现的更常见的问题中的两个是：
系统应该有多大的可扩展性？
我能使系统具有多大的可扩展性？
如果原始系统被设计成可扩展的，那么重用代码是最佳的办法。否则，重用代码时碰到的困难可以容易地抵消任何已获得的生产率。但是，要设计成可扩展的，在软件设计中就要考虑各种各样的新问题。
我将在本文讨论一些办法，这些办法能使一个软件系统对将来的项目是可扩展的。
忠告
在进行任何努力之前，请让我澄清一下，我不是主张在所有情况或者甚至大多数情况下都为了可扩展性进行设计。有利于许多设计的可扩展性选择常常会妨碍其它需要考虑的因素，例如性能或可测试性。可测试性最好的系统常常也是最简单的系统，但可扩展性设计却常常会大大增加系统的复杂性。
幸运的是，也有可扩展性最好的设计也是最简单的设计的时候，但能兼顾二者的时候真是太少了。
因为这个原因，我建议只在您能肯定得益会大于花费时才采用可扩展性策略。这通常意味着您 知道系统将会被以一定的方式扩展。
在极端编程著作中，常常把可扩展性的收益和购买股票期权相比较：您早先购买了期权，因此在将来您可以容易地扩展系统。如果最终您行使了这一期权，则可以获利颇多。
但如果您从未行使这一期权，则您将损失掉期权的价格并且没有任何回报。所以，“买主须谨慎！”
下面，我们来看看术语 可扩展性的各种定义方式。当讨论程序的可扩展性时，我们所指的本质上有三种不同类型 ― 黑箱可扩展性和两种类型的 白箱可扩展性。图 1说明了可扩展性类型的差别。
黑箱可扩展性
黑箱可扩展性是指这样一种方式：不直接扩展原始代码即可扩展程序。这通常通过使用配置语言或向导来完成，向导引导您完成对系统的扩展。
税务程序就是一个示例，这个程序包含一种配置语言，用于指定各种税务申报表。当政府发布新的税收申报表时，只需通过用配置语言说明新的税收申报表的结构即可扩展该系统。
黑箱可扩展性最适合用于研究这样的专有组件和框架，这里原始开发小组的业务模式要求两条：
程序是专有的（非开放源代码）
外界开发者在定制组件的功能性方面有一定程度的灵活性
支持用户定义脚本或宏的程序（如 Emacs、MS Office 等等）就是具有黑箱可扩展性的系统的示例。
白箱可扩展性
白箱可扩展性，相反地，是指可以通过修改或添加源代码对程序进行扩展的方式。我喜欢把白箱可扩展性区分为两个子类型： 开放箱和 玻璃箱。