一个Java框架引发的思考：语言、框架、范式转换和软件生产力

前几天，iteye上的pojo同学，发来了他四年前写的一个框架demo(原帖在这里1 2)，那一年，我也写过一个App框架。
我们的出发点都差不多：利用Java语言提供的弱类型、动态性，来解决Java语言本身的死板、臃肿。
另外，在数据建模上，我们也差不多。其实，所有的原子级数据结构，都可以简化为Map、List、Tree这三种基本类型，而且Tree还可以进一步原子化为Map+List。

先说说pojo同学这个eXtream框架吧。
它建模于数据管道这个概念，可以理解为Linux的管道模型，如grep命令。管道模型可以分为两块：
1、数据流的输入源、输出端。如Linux grep命令可以将数据查询、处理结果输出到文件、控制台等
2、数据流在管道里的处理过程(filter模式) 。如more命令的“|”参数

eXtream框架解决了2，对于1，只是用PipeUtil工具类解决，如HttpServletRequest/Response等输入输出，我认为这是完全可以进一步抽象化的，就如同java.io数据包里的类设计。

eXtream这个框架技术实现细节我就不提了，我从更实际的角度来谈一下eXtream以及编程语言和生产力的关系。

语言、框架及软件生产力
像我和pojo同学，都是对Java语言这些特性提出质疑，才开发自己的框架。现在想起来，只是“不识庐山真面目，只缘身在此山中”。如果我们真的想Java足够的动态、灵活，为什么要选择它呢，Ruby是一门更优秀的语言啊，它的ActiveRecord足够强大了。

我当初之所以会开发这一框架，还是站在个人生产力+软件开发阶段角度。从项目管理和商业角度，决定一种语言和框架是否适合，有两点：
1、团队生产力
2、软件全生命周期(可维护性)

对于1，一种语言对团队的要求是，必须规范、一致，绝不允许太个性化(容易出现Bug黑洞)。Java语言提供的静态编译和强类型，以及eclipse等工具的即时检查，让几十人的开发团队可以一起协作，有序、持续的开发。
附带说一下，如果ActionScript(flash)不是基于强类型、静态编译型，Flex就很难在企业应用Rich Client上大有作为。ActionScript和Java我感觉没有本质上区别。
当然了，如果你们是精悍小团队，希望软件尽快上线，那些灵活的框架，如RoR用用也无妨。
之所以很多人觉得Java笨，我认为是不知道怎么剪裁，就像RUP，不会剪裁基本上就没法应用，Rational公司还专门针对敏捷开发，出了RUP剪裁版。

对于2，还是因为Java语言的强类型和简单性(代码即文档)，让软件代码整洁、易读，再加上前期的规范约束，“易改”(可维护性)成为了可能。
大家知道，软件开发行业，developer在一家公司平均呆两年，如果他不离职，在一家公司呆了两年后，也基本上会换岗。而一个企业项目的生命期一般有3-10年，甚至更长，维护者和开发者肯定不是同一批人。再说，开发人员(打江山)和维护人员(守江山)完全是两类个性的人，比如维护人员不太可能是有野心、有激情、喜欢挑战的人。

语言、框架的范式转换
每一种框架都有其设计理念，比如struts和webwork本质上没啥区别，都是基于Request/Response模式，所以学会了struts很容易上手webwork。但JSF就完全不一样，基于event的模式让人很难思维转换，这也是JSF不太容易上手的原因，因为它不太符合开发人员的“直觉”：Web开发不就是http请求/响应吗？
如果你做过Flex或是Swing开发，你会发现Event-Listener模式是其核心，一旦了解了Event-Driven原理，开发就很简单了。
还有，像Web Flow这类思想的框架，把一系列页面都串联成flow也让人费解，因为从Web角度考虑，页面只是在一个请求/响应生命期，没有工作流的概念。

再说说eXtream，它将Web请求/响应，业务处理等特定逻辑，都抽象为数据管道，一个人要进行这种范式转换，有个适应期。这就像为什么用惯了Windows的人，非常不适应Mac系统，反之亦然。
再说，进行业务处理时，总要想到in、out、一次次对数据进行filter这种技术逻辑，是不是和我们的出发点：专注于业务相悖？
像苹果的iPhone(iOS)，就让我们忘记“文件系统”这个概念，专注于你的资源。

也许，你这种框架，适合特定的应用场合，充当基础设施，如数据转换、传输。

每一种技术、业务场景，都有其最适合的概念建模，如果这种建模和该业务场景匹配，则我们很容易理解。一直用命令式语言，如C/Java朋友，试试Lisp这种函数语言，你就知道自己有多么的不适应，因为你的思维已经定势了。
大家有没有想过：sql是一种和Java并列的描述型语言？
JavaScript是基于prototype这个概念。不了解prototype，JavaScript永远都谈不上精通。
建议顺着这篇文章一直读下去：http://en.wikipedia.org/wiki/Programming_paradigm

当然了，如果见过大量不同设计思想的语言、框架，你就会上升到更抽象、本质的高度。做J2EE开发的朋友，如果立志做架构师，一定要看看.net是如何处理类似问题的。

再说eXtream的技术实现。从开发的角度，如果通过框架再重新定义一套规则，如sql查询，这会加大学习成本，影响新人的上手速度。Hibernate用到HQL，就已经够折腾了(sql确实没法解决解决对象查询)。

最后总结一下。
如果你是架构师，你应该了解eXtream这类框架的设计及实现；
如果你是项目经理，你应该坚决地放弃这种框架的引入，因为项目经理永远考虑的是成本、收益、进度和风险。再说，从纯技术角度去提高软件生产力，微乎其微(人月神话大家都认同吧？)。