天下武功、唯快不破-应用快速开发能力杂谈

11月份的时候，部门内有个紧急需求，需要重新开发一套CMS系统，其实之前已经通过外包的方式开发过两版CMS系统，但运营一直不满意。由于需要将CMS系统和我们的主营业务做紧密挂钩，所以会有大量的定制化的需求，外包商一方面对需求的理解不到位，另一方面，开发周期和开发质量也差强人意，最终部门决定基于内部力量重新开发一套。为了配合年底的运营活动，要求一个月内上线！排除测试及数据迁移的时间安排，留给系统开发的时间不到3周。年底了，各个项目都吃紧，人力方面只能安排一位架构师带一位外包。

设计数据模型花了一天时间，整体评估工作量后发现——人手不够！更重要的是，由于有些基础功能只能串行化开发，就算加人，也不解决问题。

怎么办？！

和负责项目的架构师商量了一下，靠人不行，那就靠工具吧！

我把用了多年的代码生成器翻出来，针对这个项目的框架，花3天时间开发了2套代码模版，分别针对单表的CRUD操作及主从一对多表的CRUD操作。又用两个小时，给开发团队做了完整的原理及使用介绍。

接下来，势如破竹！在这套代码生成器的协助下，项目的开发效率倍增。

CMS的后台管理端是典型的2B业务，从UI到服务端功能，全部直接生成、再由开发人员做少量的调整；后端API及服务的主体功能由代码生成器批量生成；前端2C端功能由于比较个性化，UI还是H5团队单独设计。通过多端团队在一个迭代周期（两个星期）的紧密配合，CMS基本完成开发并达到可测试状态。

我的职业生涯中已经经历了无数次紧急需求，这套2007年开发的源码只有300多K的代码生成器也无数次扮演了开发效率倍增器的角色。这一小而神奇的代码生成器其实只是当年开发的快速开发平台的一部分，平台早已不用了，工具却一直保留了下来。这十几年，其模型和源码基本上没有变化，唯一变化的是积累了无数的代码模版。我每到一个新的单位，或者开发一套新的平台，都会开发几套代码模版结合代码生成器来解决大量的重复性开发工作。

实践证明，非常有效。

重新把2008年发在JavaEye上的关于快速开发平台的文章附上（估计当年很多读者还在学校里吧），其中也有关于代码生成器的介绍，希望能对大家有所帮助。十年前的企业级平台在服务化和资源拆分上肯定不如今天，希望大家不要拿砖砸我啊^_^

JavaEye（现在叫ItEye）上的文章链接：https://www.iteye.com/topic/232219

忘掉普元EOS、构建自己的企业级快速应用开发平台

希望这篇文章能够对那些正在或即将开发自己团队的J2EE应用快速开发平台的个人或公司能有所启发！

像EOS这样动辄几十上百万的平台不是每个公司都愿意花钱去买的！因此构建一套穷人级的企业快速开发平台成了很多团队的首选，而对于小团队来说，构建一套自己可以维护的开发平台才是最重要的。下面，我将以我的平台的开发过程为例来详细解析这个过程！

如果能把项目中大量的代码编写工作变得轻松，是多好的一件事!

在使用了AppFuse之后，我有个想法，能不能利用velocity这个优秀的模板引擎，用一种更加直观的模式，把开发项目中的重复代码让它自动生成， 生成之后的基础代码，按照实际的需求稍作修改便可以运行，极大的提高工作效率。这样的话，程序员就可以从大量的重复劳动中解放出来，将精力更多的投入到业 务分析及学习中。

这个想法一直在我的脑海里横亘不去，尤其在做了大量的重复模块后，深刻体会了重复Coding的那种浪费生命的痛苦后，这种冲动尤为强烈。

离开旧公司，到了新公司之后，由于职位和公司定位的不同，让我有时间开始把快速开发平台和自动代码生成器的开发真正的摆上开发日程上了。

第一步，自动代码生成器生成 的是业务模块，那么底层必须有一套框架能够为它提供支撑，而且这套基础框架要足够灵活，并且和单个模块的耦合性要比较弱。要解耦模块之间的联系，势必要用 到MVC分层设计。感谢Java的开放性，使它有这么许许多多的MVC框架可以使用。我采用的当然是目前最流行的 SSH（Struts＋Spring＋Hibernate）的组合（以前项目一直在用，也有些成熟的积累），花了三个月的时间，通过一个项目的实际应用来 使这个框架基本成型。目前功能包括：

1：灵活完善的权限管理功能（包括用户管理、角色管理、组织机构管理、资源管理、资源角色映射管理...）。原来计划采用开源的JGuard来托管这部分 的功能，因为一些特殊的原因放弃了（考虑要和工作流引擎的权限部分做集成），只采用了其权限管理的一些设计思想。

2：基于Spring的AOP实现的日志和权限管理（通过Spring的代理也将Struts的Action托管了，使的对Action的调用也能被 AOP侦测到），这样对每个功能的调用，如果需要日志纪录的话，之间将其配置到Spring的配置文件中就可以了。

3：UI上实现了类似.NET的Validation验证，这点很重要，想必大家都深刻体会到利用JavaScript或Struts的验证机制来实现前端页面数据验证的痛苦了吧：），我们实现的功能如下图所示：

4、多套UI风格样式。这个不是很必须，但是作为一套成功的系统，良好的用户体验也是必不可少的。

5、支撑模块：2套报表引擎（一个是基于JasperReport实现的B/S版本报表；另外一个是类Excel的报表引擎），流程引擎（其实就我个人来看，工作流引擎才是这套系统的灵魂，有了它，所有流程性应用包括表单、业务流、权限都可以通过配置并结合Beanshell脚本来获得，以下是我们报表和流程设计器的一些截图：

工作流引擎截图：

报表截图：

6、i18n的支持，由于我们有很多国外的客户，这块是必须的。

有了这个基础支撑平台之后，就可以开始着手开放我们的代码生成器了。

第二步：开发代码生成器。 AppFuse基于Ant的自动代码生成模式让我深恶痛绝，究其原因，一句话－－“不够人性化”，我们做的首先必须考虑可用性，因此决定采用可视化的UI 模式。由于我用的是NetBean编辑器，做可视化的Swing开发不成问题（这点要感谢SUN啊，出了个和VB一样简单的IDE）。我实现的代码生成器 的界面如下：

怎么样？是不是够傻瓜化啊？是个人就能用！

从上面大家可以看到，我们这个代码生成器和Hibernate的POJO对象生成工具类似，也是基于数据库的模型来生成代码的，不同的是，我们生成的代码 范围更广，不仅包括了POJO对象暨相应的hbm.xml文件，另外还包括相应的DAO（Server层）、相应的Action、Form类、相关的 JSP文件（list页面、edit页面、Excel导出页面等等）、资源文件及相关的Struts和Spring的配置子文件（Struts和 Spring均支撑将配置拆分成多个配置，我们利用这种特性来减低模块之间的耦合性。）

至于数据库模型的获得，可以利用JDBC的MetaData（元数据模型）的功能来获得，我们目前维护了表的完整的主键、外键关系（父子表）

第三步：配置模板。有了可视化的数据库表映射模型，也获得了数据库表及其主外键关系的详细信息，接下来当然是根据这些信息来生成代码了。这里我们用了强大的Velocity模板技术，这样不仅可以灵活的处理复杂的表映射对象之间的关系，也能够灵活的进行变更升级。而且我们能够通过所获得的数据库模型，在页面上自动实现基于Javascript的数据验证“非空验证、字符长度验证、数字验证，日期验证”。

通过以上3个步骤的工作，我们的基础开发平台和自动代码生成器就大功告成了！目前我们生成的代码可以直接编译通过，通过简单的系统配置后，可以直接在服务器上跑！ 由于模板种类多，而且模板中自动实现的代码功能已经非常完善了，所以一些特殊的业务需求只需要在自动生成的代码基础上做简单修改就可以了！

基础开发平台和代码生成器投入使用后，对我们项目开发的资源投入的改善是非常明细的，目前基于基础平台和代码生成器的配合，我们已经做了6、7个系统了，平均每个系统的开发时间至少要比以前节约40％，有的项目甚至达到了80％以上（我们最高的一天，处理了40多个表的增、删、该、查的功能，及中文本地化）。而且，另外 很重要的一点，生成的代码无形中统一了程序员的设计风格，我们通过这套开发机制，能够最大限度的保证我们开发的系统质量，保证模块可以在不同系统之间的自 由迁移，最大限度的实现复用！在项目开发中节省出来的大量时间，也让我们可以去研究更多的开源中间件和系统，来增强我们的基础平台，从而形成一个良性的循 环！

我们做了多套模板，能够针对单表操作，及父子表操作来自由组合搭配。以下就是我们系统的一些功能截图，除了中文化之外，基本上没有修改：

单表操作

父子表关联操作

以上是快速开发平台的基本能力，顺便通报一下我们平台目前的状况：

1、增加了Web Service接口功能，基于spring-xfire实现的，目前基于server这一层的所有接口，在代码生成器生成代码（或手工添加接口） 时，xfire会对其自动封装并对外暴露。并同时集成访问接口。程序员不用直接接触wsdl了（安全方面目前只是通过IP过滤来简单实现）。

这样的话，同样基于平台的A、B两个独立系统，可以通过WebService进行相互调用，同时，从本地调用变更为webService调用不需要修改任何代码，只要修改配置文件的一行定义就可以了！

这个应该算是我们平台的一个标志性的里程碑了吧！从一定意义上来说，这才真正成为一个开放的平台，算SOA化了！

2、模板更加丰富了，基于工作流应用我们目前已经有了一套通用模式，可以和流程引擎进行无缝结合！针对流程应用的模板可以生成绝大部分引擎相关部 分的代码，程序员只需要修改流程定义模板的名称就可以了！同时针对一对多，一对一关系的模板进行了大量优化，能够适应更多的企业应用场景了！

目前的平台还是主要针对开发人员，是企业应用快速开发平台，我们后续规划将其和我们已经有的一套应用快速搭建平台进行整合，以使其能够同时被业务人员和开发人员使用。简单业务就由业务人员通过搭建平台的可视化的流程和表单配置来实现，复杂业务再由技术人员通过开发平台来实现。

最后再谈一下应用快速开发平台的定位吧，相信这也是大家最近争论的一个焦点，说有用的有之，说用处不大的也有之。

我个人的观点是：只要你的平台够灵活，模板够多、够复杂、兼容的业务场景越多，它就有用，而且很有用；反之，如果平台底层呆板，模板简单，它的用处就不大。至于其它的什么维护的便利性什么的我就不再多说了，免得有吹嘘之嫌了，反正大家仁者见仁，智者见智！套用一句常话就是－－－寒天饮冰水，冷暖自知！

-完-

欢迎关注，欢迎分享！

一起感悟码码人生