现在的企业应用跟十年前的MIS可是大不一样了，需求不断变化，修改没完没了。而互联网应用呢？在变化的剧烈和频繁方面，与企业应用相比可谓有过之而无不及。这本质上是因为企业在迅速变化，消费者在迅速变化，人们的需求在迅速变化，世界在迅速变化。现在经验比较丰富的企业开发者越来越达成共识，即事先分析企业应用、对抗需求变更，几乎肯定是死路一条，不管你采用什么先进的软件工程方法、建模工具、UML语言，都无法根本解决问题。你所服务的对象自己都天天在变，你怎么可能实现量好人家的需求然后慢吞吞地去添砖加瓦呢？既然无法避免变化，不如适应变化。与其想办法预见变化，不如让自己有能力迅速随需应变，提高自己对变化的反应能力，降低变化带来的成本。
这已经是共识了，问题在于怎么随需应变。分歧就在这里了。今天做ASP.NET、J2EE开发的离不开XML，就是为了“随需应变”，在变更发生时用XML来重新配置系统。以J2EE为例，高水平的J2EE开发者把XML文件越写越复杂，最后根本就就是把XML当成领域语言来用。说白了，就是把J2EE往上扩展成一个面向领域的引擎，再用一层标准化的、薄博的XML来最后的编程，我称之为“强引擎，弱脚本”方案。这样做是有原因的，Java/C#好歹是个编译语言，变更修改重新部署的成本比较大，所以要配合XML使用。但结果怎么样？并不理想。首先系统设计难度还是很大，你还是要设计一个强劲的引擎，设计得不好就带不动XML脚本。而设计这个强劲的引擎还是挺难的，设计错了修改起来还是挺麻烦的，发布以后也难免还要花大力气维护的。这问题没解决多少。
其次，也是我个人最反感的，就是XML的滥用。XML那东西本质上是用来在程序之间进行数据交换用的，是给程序读写的，不是给人读写的。无论从哪个角度来看，XML对人的阅读和创作都是非常不友好的。结果为了配合J2EE，硬是赶鸭子上架，让XML充当DSL，逼程序员去学习读写XML这种非常没有趣味的“语言”，真是不人道。更有甚者，为了使用各种框架、面向各个领域，开发者还很可能要学会多种不同语义的XML方言，而且很多这样的XML方言根本就没有经过设计，是土法炮制出来的。两种截然不同的语言搅和在一个系统里已经够糟了，更糟的是多种土法炮制的XML方言土语一起搅和在系统里，结果搞得各种语义不同的XML就像癌细胞一样在程序里扩散，这样的系统只能用恶心来形容。
总之，这种“强引擎，弱脚本”的方式，我认为是没有前途的。
文章来源于领测软件测试网 https://www.ltesting.net/
