The Inner-Platform Effect roughly states that by making a system too flexible and configurable, the configuration of the system itself becomes so complex it takes a specialist in order to maintain it - thus re-introducing the problem that the system was attempting to solve. Or in other words, the configuration becomes a platform itself, requiring all of the tools and special knowledge of any programming language... effectively creating a system in a system.
——Maven 2 User Guide
这个反模式是第二次让我有切肤之痛。
第一次是在Moto设计和实现Common Platform的时候,当时的业务领域是对讲机的配置软件(CPS) , 当时面对的最大问题也是Common Platform试图去解决的问题就是——不同的CPS平台的融合和软件需求的频繁变化。Common Platfrom统一了软件开发平台,频繁变化的需求通过需求工具捕捉成XML数据,然后通过代码生成工具编译(实际是宏替换)生成最终的目标语言的代码,然后编译生成可执行文件。将不变的东西平台化(这个东西自开始就没有被重视和精心设计,最终扼杀了上层的所有东西),将变化的需求用XML来表达,实际上是在创建一种DSL(Domain Specific Language), 这里的语言是广义的计算机语言,可以是具有函数/逻辑控制/面向对象,也可以是简单的软件配置。DSL可以被解释执行,也可以通过编译成低级语言来执行。DSL和MDA有紧密的关系, 需求的捕捉工具最终将演变成建模工具。代码自动化是一个挺雷人的噱头,Manager会认为它可以极大地提高生产率,但后来的实践证明远不是这么回事。
DSL如果是解释运行的话,那么下面的平台将成为一个虚拟机;如果是编译模式,编译成的目标语言代码和平台的代码混合编译成可执行代码,那么需要有一个聪明的编译器(或者代码生成工具)。无论哪种方式,都需要实现一个灵活健壮的软件层(虚拟机/编译器),DSL的灵活性需要在下层付出代价(良好的设计,足够的稳定),而远离技术的Manager是看不到这个东西的重要性。当现实对灵活性的需求逐渐降临DSL的时候,没有良好设计的下层的维护代价将会拖垮整个项目。DSL的IDE也就是Modling tool也存在不断更新维护的问题。
第二次就是当前的项目组,我们的产品模块就是把一个Information Model映射成另外一种Information Model,源信息和目标信息都可以用XML来表达。也许你象我们的几个Team Member(被Mediation Framework的Architecturer Jussi蛊惑了的)立刻抛出这样问题:为什么不用XSLT来做这种tansformation呢?
是的,XSLT是个straightforward的技术选型,但我想在这里陈述一下我们的领域背景: 已有的系统虽然transform的数据源和目标数据都不是XML,但描述tranform规则的配置文件FlexMapping却是XML,这个XML有自己的Schema和语义,在运行时被一个引擎读入形成自己的数据结构,然后所有的tranformation都基于这个数据结构来进行,我不得不承认,这个engine设计得很不错,而且比较灵活,配置起来也足够straightforward (我们的Customization Team和测试人员很容易学会如何配置,只要他们有3GPP规范的基本知识)。
XSLT是可以实现我们的需求的,但有什么问题呢?首先,从代码(我们坚决认为XSLT编写的xsl文件是一种XML格式的代码,请不要简单认为所有的XML都是配置文件)的的可维护性上讲,XSLT代码中掺杂了目标XML格式/函数/Java Code, 长度是原有的FlexMapping的至少5倍, 难以维护是个问题。其次,从对Customization Team和测试人员的知识要求来看, 他们需要理解3GPP规范+XSLT语言。
两种实现方式的本质区别是抽象层次的高低:被充分检验的已有的FlexMapping是和我们的产品领域紧密相关的DSL,它是被下层的引擎解释执行的; 采用XSLT来实现因为采用的是抽象层次低但通用性更强的通用语言——XSLT,所以它的上层Code必然要复杂一些,要更难维护。
也许Jussi会狡辩——XSLT代码的复杂性可以通过tools来屏蔽,没错,但这样的tool是和领域相关的,也只有我们自己来开发这样的tool, 复杂性没有减少,而是转移了。
这是一个很有意思的balance问题,这种问题让软件开发更像计算机科学而远离工程学。