扩展已有系统

几个月前的东西，终于有时间整理了。

新系统都是每个人喜欢的，而维护一个已有系统，对任何人都是挑战。

完成新系统的过程只有两件事情需要做：就是分析需求，完成需求。

而维护一个已有系统，则还需要完成一件事情：明白如何使用手边的工具完成需求。

应该可以武断地说，不会有人去喜欢扩展一个不是自己写的已有的系统的——除非他是为了学习。

但是，世界就是这个样子的：

1 需求总是推陈出新。

2 市场总是喜欢新的需求。

3 不可能有解决一切的解决方案，解决一切一般也就是什么都没解决。

4 作为一个员工，一般你都会使用别人交给你的工具。

所以，扩展就成了几乎是必修课样的东西。

扩展也有多种办法，最为彻底的无非就是重写，或者另一个彻底的无非就是不做，一个累死，一个炒鱿鱼，都是诱人而又无法选择的方案。

不开玩笑，那么扩展的首要任务是必须明白自己的工具，这个引擎，究竟哪些地方可以扩展，哪些地方不能，扩展的代价。

扩展一般基于我们的需求，以及对于系统的两种认知：

对于需求而言，封闭原有的功能（即让原本的功能无效化）、UI修饰（不改变核心功能的前提下，修饰UI）、以及对原功能的BUG进行修正，都是很容易的。这几个方面都是外在的方面，并不是太严重，也容易完成。

相对来说，单一系统的修饰更加容易完成一些。在确定的输入和输出上，修改算法，这也不是太复杂，只要你明白输入域和输出域。函数在确定的输入和输出域上，只可能获取到你不希望的结果，而不可能获取到错误的结果。例如，你要修改光照计算的公式，将原有的一张高光图，使用HalfLife2的方法，做成法线空间内的多张高光图。这个相对就容易一些，因为输入域（Light Map）和输出域（颜色空间），没有质的变化。

然而，仍然需要注意的是：必须确认希望修改的这个系统，其输出是如何用于其他系统的输入的。不管三七二十一，一看注释，OK输出是这个意思，那么就对输出按照自己的意愿进行更改——这样的结果就是看人品了。只有明白了一个输出确定对于其他系统有什么影响，才能明确自己应该在怎样程度上利用这个输出。输入也是一样，只有明白了它能够接收其他系统怎样程度上的输入，才能够明白这些输入是该如何进行修饰。

如果牵扯到对原有系统功能的修改，那么就复杂了，人家好端端的系统放在那里，很可能是要跟各种系统发生关系的。就正如现在的mm们对那种从不出轨的男人不抱希望一样，作为程序员，我们很难相信这个世界上所有的引擎是绝对的、完整的、毫无保留的符合设计模式的封装性原则的。或多或少，设计总会出轨，这就是现实，尤其是游戏系统，作为一种特殊的系统、中小型的软件项目类型，它并没有经受过高强度的考验，它的设计就更加随意而符合个人意愿，探索占有的比重经常大于理性的分析，需求的把握。

在这种情况下，我们首先需要做的可能就是需要将需要扩展的功能分摊到若干个系统中，对于这些系统，确认每个系统所占的具体工作，以及这些具体工作需要修改，以及带来或者取消哪些输入和输出。之后的问题就恢复到了对于每个系统，在确定的输入和输出下，完成新的这些功能。

例如，我们如何使一个不支持动态加载的系统支持这个特性呢？道理大家都清楚：接管资源的创建（资源模块），以及资源使用时通知资源的调度（使用模块）。然后，剩下的问题就可以在这两个模块里面解决掉了。

说了半天，像是废话一样，其实就想表达一个意思：扩展其实并不是太复杂的工作，或者说，起码，求证一个系统是否便于扩展，并不是太复杂的东西，没必要害怕。

与其求着人给你什么什么，不如自己去帮助人家完成这些工作。

当然，如果别人都说自己要做了，那你也就别抢了，呵呵。