软件可以这样功能扩展

在所有关于软件维护的故事中，功能的扩展是一个永恒的话题。正因为软件系统需要功能的扩展，需要新功能的加入，才使我们的编程需要那么多的设计。可以说，正是因为新功能的扩展，使得原有的系统质量下降；正是因为软件质量的下降，才使我们需要进行深入的分析与研究，制订设计原则，总结设计模式；正是因为要解决软件质量下降的问题，经过一番艰苦卓绝的摸索过程，我们才认识到系统重构才是解决该问题的最佳方案。

然而，事情总是这样的，每个系统当我们进行初次的设计时，设计思路、程序结构总是比较完美的。可是当初次设计结束后，我们在日后的维护中，开始往系统里添加新功能时，系统开始不完美了，甚至开始出现问题了，新增的功能总是或多或少有些水土不服。怎么办呢？要保证每次需求的变更时软件质量不会下降，必须记住这样一个原则：先重构再添加新功能。

添加新功能前先重构原有系统，其目的有两个：
1. 软件的设计总是与软件的复杂程度有关的，原有的设计是在原有需求不复杂的条件下做出的，但随着新功能的加入，软件复杂度在发生着变化，因此必须要调整原有的设计以适应新的需求；
2. 为了提高软件的可维护性与易变更性，添加新功能应遵循OCP原则。而要遵循OCP原则，我们应当在不添加新功能的前提下先进行重构，设计出可扩展点出来，然后再添加新功能。

是的，明白这两点非常重要。软件维护越来越困难，不是因为客户提出了需求变更，而是因为我们没有随着软件复杂度的增加改变我们的软件结构。软件需求起初比较简单，是几乎所有软件的共性。但随着软件复杂度的增加，我们却不敢有效地调整现有的软件结构，以适应新的需求，这就真正是我们的问题了。不敢调整，是害怕原有功能会出错，但不调整，则意味着我们软件设计的问题会越来越大，进而越来越难于维护。改与不改，我们面临着两难的抉择。

解决这个两难的难题其实不难，实际上就是一层窗户纸一桶就破了。试想，我们不敢修改原有代码的真正原因是因为害怕改出问题影响原有功能的正常运行。那么，我们找一个方法使我们在修改原有代码时不会出现问题，换句话说是出现问题以后会及时发现，则问题就可以解决，这个方法就是重构与测试。

客户判断一个功能是否正常运行的标准，就是当输入一个值后，能得到客户期望的结果，不管系统内部是怎样运行的。因此，建立这样一个测试用例，让软件系统在重构前后都能通过这些测试用例，就可以保证重构的正确性（关于如何建立，我们还会在后面仔细讨论）。重构以后，外部功能是一致的，但内部程序结构却变得更加易于添加新的功能，使新的功能与原有系统可以有机地融为一体，这才是我们的目的。说起来比较抽象，我们来举一个示例吧：

在许多系统中，只要有报表出现就有需求要实现Excel数据