框架和平台的扩展性

我们的产品底层是一个平台，提供基础业务，以及扩展API。在平台之上，通过个性化配置，和定制开发，得到最终的产品

本文不谈配置的事，只说说定制

平台发布到不同的项目之后，各项目自行定制。由于不同的项目需求差异较大，有时候平台提供的扩展API无法满足，项目就直接修改或增加平台的代码。但是这样就有个问题，平台就不能随意升级了，因为项目对平台代码的修改不可控，平台升级之后，很可能与定制的代码冲突

延伸一下，我想到其实用到的各种开源框架也有这个情况

以struts2为例，把struts2也看做一个平台。初级的开发者，只会用到平台默认的功能。高级的开发者，会对平台进行扩展，比如自定义Interceptor、Validator等

这种扩展，都是基于平台事先设计开放的API来进行的，是“合理的扩展”，或者说是“预期的扩展”。在struts2升级的时候，只要有意识地保持这些API的稳定，那么用户自定义的扩展就不会受到影响

另一种扩展，则是在struts2没有“预料”到的地方，直接修改了平台的源代码，那么这种扩展，就跟本文前面提到的现象一样，是一种“意外的扩展”，实际上不叫扩展，而是"hack"，或者说“侵入”，是不鼓励的，因为框架升级以后，这些扩展很可能就冲突了。有时用户被逼无奈，必须做出这种选择。如果这种情况很多的话，那么可以认为框架的“扩展性”是比较差的

所以一个框架，应该在设计时，事先识别出扩展点，开放相应的API，以达到较好的扩展性。在升级时，也要注意向下兼容，尽量不要修改现有的接口

顺便也想通了一个问题，为什么很多开源框架都提供userguide和developerreference：

user指的是普通用户，不做扩展

developer指的是高级用户，会对现有框架做扩展，甚至修改，有时就是框架的作者

当然，这2类人群，实际上都是程序员