给做快速开发框架的人泼泼凉水

最近论坛里出现了不少关于此类的文章：

引用

秀一下我的快速开发平台
http://www.iteye.com/post/711399
http://www.iteye.com/topic/258458

忘掉普元EOS、构建自己的企业级快速应用开发平台
http://www.iteye.com/topic/232219

我也做过类似的东西，现在也一直在用。
但是越来越感觉那是鸡肋。
http://www.iteye.com/topic/95580

有一次，开发一个公司内部使用的图书馆里系统，前后只花了一个下午，把老板吓一跳，并支持我利用工作时间完善那套框架。

确实，在某些情况下，他可以极大的提高我们的开发效率。

但是，我们忘记了这类系统高昂的开发和推广、学习、维护成本。

刚才查了一下，我那个代码生成器，单源代码就是6.5M。
如此一个不知名的第三方开发的庞大的系统，你不搞清楚其内部逻辑你敢随便使用吗？而真正搞清楚这些东西的代价有多大，后期扩展，维护的风险多大！

从我来讲，我不敢用。

我想，做这种东西有一个强大的后台公司支持还好，如EOS后面有普元。
而作为个人开发者，我们如何能打通这条产业链，如何让别人信任，学会，并采纳你的设计思想，让足够多的人去分享去使用你的产品，这些可不是一个技术问题。

Java程序员可能都有一个好大喜功的特性，环境所致把。

但是我们还是应该充分认识到自己个人力量的有限。

要做什么东西的话，先别想着如果别人用这个东西可以提高多少多少的开发效率。
只有它能给自己带来足够的好处，你才能做下去，否则很难生存。
穷则独善其身。

有什么考虑不对的地方，大家来提提把。

评论

82 楼 daquan198163 2008-11-03  

justshare 写道

严重同意这位老兄的意见：快速开发并不一定是代码生成。
我们公司内部也做了一个快速开发的系统，大体的思想是这样的：
定义一套固定的XML模板
1。定义与数据库中对应的节点。
2。定义列表节点。
3。定义查询页面的元素(其中包括什么CSS文件，文本框属性什么的)。
4。定义修改，插入等页面的无素
......
然后通过JAVA程序来解析这套XML模板。
支持SQL，视图，存储过程，触发器等。
不需要写代码，也不会生成JAVA文件，你要做的就是：配置好XML文件。
有多少个模块，你就配置多少个XML文件，最后将这个文件名传过去，让相应的模块调用相应的XML文件即可。

优点：
只要你会写SQL，视图，存储过程，触发器，往里面配置一下就行；
不会生成JAVA文件，所以就不存在维护代码问题；

缺点：
由于是一个通用的模板，对于界面的排版是固定的，比如一行放两个文本框等，不那么灵活。

赶走一只狼，引来一只虎

81 楼 justshare 2008-11-03  

yanwt 写道

首先说明一个问题，快速开发并不一定是代码生成。
我的理解，代码生成只是帮助程序员实现一些重复的体力劳动而已（这种重复有可能是设计本身的问题），就像是很多人都喜欢用一些工具生成hibernate的映射（或注解）一样，并不是替用户解决业务逻辑问题。
至于后期扩展，维护的问题是软件架构设计的问题，这个和快速开发没什么关系。如果系统耦合度高你开发的慢也是存在上面的问题。

严重同意这位老兄的意见：快速开发并不一定是代码生成。
我们公司内部也做了一个快速开发的系统，大体的思想是这样的：
定义一套固定的XML模板
1。定义与数据库中对应的节点。
2。定义列表节点。
3。定义查询页面的元素(其中包括什么CSS文件，文本框属性什么的)。
4。定义修改，插入等页面的无素
......
然后通过JAVA程序来解析这套XML模板。
支持SQL，视图，存储过程，触发器等。
不需要写代码，也不会生成JAVA文件，你要做的就是：配置好XML文件。
有多少个模块，你就配置多少个XML文件，最后将这个文件名传过去，让相应的模块调用相应的XML文件即可。

优点：
只要你会写SQL，视图，存储过程，触发器，往里面配置一下就行；
不会生成JAVA文件，所以就不存在维护代码问题；

缺点：
由于是一个通用的模板，对于界面的排版是固定的，比如一行放两个文本框等，不那么灵活。

80 楼 kenken0y 2008-11-03  

动态和代码生成结合起来可能比较好

框架里面用反射,proxy,cglib,asm增加动态性,可以预览快速原型,因性能要求或者需要个性化的时候再代码生成出来维护,生成的代码就不要再歧视它就行

关键还是本身的架构要好

79 楼 dunsword 2008-11-03  

科诺已经倒了，普元还能坚持多久？ 底层框架，OpenSource是王道！

78 楼 sunwine 2008-11-03  

javaeye上总能看到许多对快速开发产品的讨论，感觉很多人对这块很关注，也在探索。但大多都是持否定态度，其实对于软件平台产品目前主要存在3种类型，一种是业务平台，以特定行业业务为核心，和开发关系不大，另外两种是开发性的平台，一种关注代码生成，一种关注逻辑复用。

我们一直在做逻辑复用类型的开发平台，感觉虽然平台开发复杂、涉及面广，但如果有好的支撑体系，还是可以开发出较好效率、较广应用面的平台产品。

快速开发平台并不是万用的平台，也不能一劳永逸的解决所有问题，但再面对一个项目或产品时，有平台在手上可以大体忽略开发问题，而把重心放在更为核心的需求调研和系统设计上。

对于快速开发平台，建议不要过于菲薄，视为仇敌，快速开发平台能够降低成本，提升开发效率，这时毋庸置疑的，而且从长远看，平台化的软件开发也是大趋势，象硬件系统一样的模块化组装也是整个行业的追求。

77 楼 sunwine 2008-11-03  

关于快速开发框架或平台永无休止的争论只是因为大家都没有用心去做
不用否定，也不用夸张的下结论
我们也做快速开发平台，2001年起步，一直在做，通过平台开发的项目也近百个，没发现有这么多杞人忧天的问题，总结一句，许多下结论说平台做不到或效率低下的问题，其实都不是问题，只是因为你的所谓的平台不够好，你没有投入大量精力和成本进去。

http://www.extraction.com.cn:8855 这是个用平台开发的产品范例，没有一行java代码，开发工程师以前进行PB开发，不属性Web开发

76 楼 Joel 2008-11-03  

这两天看了一些这样的框架东东，个人能搞出来都是花了极大的精力哦，赞一个！！！
我做了两年的ERP研发，公司以前是在delphi的模板下开发的，的确对我们研发效率有很大的帮助，后来公司在.Net下也搞了一个类似的模板用起来就不是那么爽了哦，呵呵
个人也参与了一部分功能的开发，说真的对那个东东没用很多的信心，后话就不说了！
个人这里只是想从商用和业务角度对于这个东东的理解：
    这类开发框架想要商用，可扩展性应该是最为重要的，公司想要使用也许对于其自身的整个研发流程都要有较大的改动，用了你的东东，软件公司是不会把你也请去做后期功能扩展的，所以大多数公司宁可自己搞一套，也不会采用个人开发的，更何况存在对个人技术和个人软件极大的不信任因素
    从业务角度来说，简易框架实现增，删，改，简单查询操作应该是没用问题的，但真的企业业务当中这样简单的功能其实是不多的，常规开发这样的功能也花不了多少时间。而对于复杂的业务功能个人认为这样的框架是很难实现的。
    个人感觉，这类东东要做到尽量“远离”业务，抽象出一些功能性的东东，应该更会好卖些哦，呵呵！！！

75 楼 key232323 2008-11-02  

我也在造重复的轮子……但觉得这个轮子值得……

74 楼 icewubin 2008-11-02  

fireflyc 写道

我只是想说明的是，注解带来的是硬编码，硬编码不但带来了需要编译，更带来了重复，还有代码可读性的下降。必须避免硬编码。再次强调：[size=xx-large; color: #ff0000;]注解是硬编码，注解是代码[/size]

1.使用注解的大前提就是减少重复，否则是不会用的。
例：比如默认的约定的声明式事务策略一般都是用配置文件来配的，不会用注解。实际使用时往往是默认的约定的声明式事务策略加少部分自定义的注解事务，自定义往往是需要特殊的事务隔离机制或传播机制。
注解一定带来重复，这条逻辑上根本是不成立的。更多的情况是，利用注解的特性能减少重复，xml中的各种和业务无关的标签和规范就是某种意义上的重复，而且还影响可读性。

2.接着上面的可读性来讲，以Hibernate的注解为例，可读性一定是注解优于配置的，看一个Java文件的速度一定是比.java + .hbm.xml要方便的，所以“xml配置可读性一定优于注解”也是不成立的，而且大部分情况下，xml可读性反而不如注解，这里的可读性包括IDE能提供的间接的可读性，比如我要借助IDE找到所有的引用此注解“@AccessType”的类。

3.请首先了解历史上为什么会出现“硬编码不好，配置优于代码”的起因，以前这样的论调是要解决什么问题。现在时代变了，有很多种方法来解决部署时的问题，降低各种人员成本和版本控制的成本。

我前面也说了，首先设计上就要区分开部署型的配置参数，然后利用ant全自动的修改部署型参数，剩下的参数就不要幻想会有临时修改配置的可能，如果你们公司真出现了这样的场景，我认为你们对生产环境的发版做的不够规范，很容导致浪费成本的情况出现。整个软件工程，成本最高的部分往往是修改、测试、部署、维护，而不是开发。

73 楼 fireflyc 2008-11-01  

<p>看了上面的回复。</p>
<p>有朋友提出了，配置应该是全局性的，不能随意修改。你在测试的时候由于支持热部署所以你使用注解还是配置都一样的。而在生产环境只修改一个配置文件就搞定一切是不可能的。所以可以注解还是可以代替配置的。</p>
<p>这种说法是很奇怪的。注意我上面强调过，<span style='color: #ff0000; font-size: medium;'>注解是硬编码，注解是代码</span> 没有任何修改是能在生产环境下完成的。那么总要在开发环境中完成，总要编译源代码的。完全可以使用硬编码啊。问题是硬编码不但带来编译的问题，更重要的它是一种重复。考虑一下web层的那些注解。如果有一天我们的目录结构变化了，我们的模板要引入换肤功能，所以需要调整。那么你就要挨个的修改所有的controller的java代码。假如引用配置文件，那么这些修改就是集中修改的了。当然这种修改概率是很小的，我只是想说明的是，注解带来的是硬编码，硬编码不但带来了需要编译，更带来了重复，还有代码可读性的下降。必须避免硬编码。再次强调：<strong><span style='color: #ff0000; font-size: xx-large;'>注解是硬编码，注解是代码</span></strong> </p>
<p> </p>
<p>还有一个是有人认为建筑行业比软件业更发达，其实不然。有朋友总喜欢拿电子行业和建筑行业和软件业打比喻。以证明所谓的模块化，封装的必要。我首先声明，本人是个电子爱好者，业余时间喜欢自己设计电子玩具玩。而且以前是个农民工，在工地上打过工。所以这两个行业多少我是知道点的。</p>
<p> </p>
<p>首先是建筑业，这个行业所能复制的只有设计而已。如果做一个的楼房那么是比较简单的，10个左右的工人就能建好。根本不需要设计，因为如何做都在这些工人脑海中已经形成了。最后的结果可能不太满意，但是总体而言是建好了。而且是比较坚固的，这里面并没有什么力学，什么土质，什么图纸之类的讲究。如果是一个高楼大厦，这个是要分工的。每个工种负责一点事情，每个小组有组长。他们非常清楚自己要什么事情。就现在而言都是框架的钢结构的。搭好架子，灌上水泥。然后就可以开工了。这个行业如果想降低成本，第一工人多做一点，第二就是质量牺牲一点。通常都是后者。</p>
<p> </p>
<p>电子业看似比较简单，因为有很多芯片可以拿来用。可是这些板子是不可能拿来就用的，这些是需要成本的，你不可能做到这个板子坏掉了，直接换掉另一个不同品牌的板子。你在使用这些芯片的时候必须了解这些芯片的性能，而且要根据电路来判断选择那一种的芯片和零件。</p>
<p> </p>
<p>所以想复用就不要封装，看封装不是封装才能达到复用。</p>
<p>只有朋友能制造出自动生成想要软件的工具，我对此会坚持——打死也不信。</p>

72 楼 icewubin 2008-11-01  

jindw 写道

配置的可修改性，估计就像那神七的逃逸塔吧。
虽然不一定能用上，他是有总比没有的好，但是有这个东西就更放心了。

我自己也没有碰到过实施阶段需要修改配置的情况，纸上谈兵吧。

“Java框架思想综合征”就是这个毛病，什么都是有比没有好，好比java没有真正的析构函数，根据有比没有好的原则，难道放弃Java去用C++或者C，完全自己控制资源，有比没有好啊，总有场景会碰到需要自己主动释放资源的情况，对吧。

你再想想上面我说的反话，或者说，等你有了实际部署经验再来讨论吧。

我再一次强调，配置即使是部署型xml一样是要作为代码来看待的，必须要纳入版本控制，不能随意人工修改的，否则风险和部署时的bug不可控，所以单独只修改配置（不编译或者不调试或者不测试）的需求场景是根本不存在的。

而一旦部署型xml纳入版本控制，有以下好处：
1.极大的降低部署人员的素质要求，降低成本，尤其是产品型部署，不可能派开发人员频繁参与部署任务，那是对开发人员的极大浪费，开发人员也没有专门的支持人员更容易和客户沟通。国内还有个不好的习惯是，一旦放开发人员直接去部署，和客户熟了以后，客户往往直接找开发人员变更需求，这是绝对不可取，对公司的商务极其不利的结果，必须要有支持人员或者其他角色在中间拦截。一方面不能随意浪费开发人员的成本去为客户修改（带来商务上的极大的不利，开发人员不是销售，随口一句“我半天就能搞定”往往害惨所有相关人员），另一方面即使真要修改也不能随便答应，客户脱口而出未经仔细推敲的需求往往是有隐患的，或者是他表达的意思不完全，匆忙的交待往往是会产生需求歧义的。

2.能很好的控制测试任务、版本发布和分支版本的bug修改。通过制定的svn版本和实现全自动化的ant，集成测试人员能够很方便的自行打包测试，完全不需要去打扰开发人员，减少沟通成本。实施人员也能够根据要实施的客户、版本号来自行或者委托集成测试人员打包（为了节约成本，集成测试人员和实施人员完全是可以兼任的），不需要修改任何配置，带着war包就能去部署了，尤其是异地部署这样做更是方便。

71 楼 jindw 2008-11-01  

配置的可修改性，估计就像那神七的逃逸塔吧。
虽然不一定能用上，他是有总比没有的好，但是有这个东西就更放心了。

我自己也没有碰到过实施阶段需要修改配置的情况，纸上谈兵吧。

70 楼 icewubin 2008-11-01  

amonlei 写道

yuzhu712 写道

你开个软件公司就明白了 利润,成本,时间是最重要的,甚至超越了质量...

开玩笑，没有质量，哪来的利润？靠忽悠？

您说对了，大部分的政府项目就是这样的。

说具体点就是，当某个政府领导发现有三家乙方的质量是差不多的（即使真的有上下，不等于这个领导有能力分辨出来），这个时候就看谁关系硬，谁更能忽悠。

至于回扣等其他黑幕我就不一一列举了。

69 楼 icewubin 2008-11-01  

jindw 写道

icewubin 写道

我不明白的是你为什么会产生改Hibernate配置的需求，我们可以探讨一下你是什么场景需要，至少我认为是不需要的。

其他的类似，我既然说大部分配置是为代码服务的意味着这些配置只要修改，往往就需要修改代码，如果真出现你认为的只改配置不改代码我认为是有问题的。有兴趣我可以深入和你探讨各种细节。

至于实施型配置文件，我也说点具体的：
我认为实施的时候即使是实施型xml也不能随意修改，都应该用ant统一自动修改并打包，这样才能便于测试和发布、版本的跟踪和分支控制，否则都靠人工该配置，很容易失控，或者是由于配置引起的bug而导致回归测试不能重现错误，都是要尽量避免的。

如果是一个独立的项目，修改的可能性是不大，如果作为一个通用的产品这种需求还是会比较常见的，譬如，如我们可能修改一些Spring服务的可选具体实现。hibernate配置的需求更少见一点，但也不能完全排除这种需求，比如对一些缓存参数的设置。可能会更具具体环境做修改。

我现在的一个项目的情况如下，一个项目要发布成两个应用，一个对外业务，另一个对内，对外的屏蔽管理员功能，两个应用打包过程都要绑定不同的一些应用服务器相关信息，因为用的是webshphere，再加上发布的最终目标是三个，公司局域网测试服务器，张江公网测试服务器，北京正式上线服务器，三个服务器+2个版本总共6种打包方式，6种打包方式互相之间相关不同的参数有5-10个，全部通过build.properties事先设定，在ant中就是6个任务。而且ant任务不依赖于eclipse，是根据svn复制（相当于cvs的tag）的一个目录，取指定的版本，然后自动编译，修改所有配置参数，再打成war包，全程自动化，测试人员自己就能操作。整个过程大致这样，不需要手工去改什么东西，除非是临时性调试，基本不会碰到，这样发布的版本才能控制好，否则现场支持人员由于自身的失误，改错了一个配置，异地的开发人员是很难高效的查出问题所在的。

如果是通用产品，就更应该用全自动ant的方式，全部自动化，这样复杂度就转变成了ant脚本编程和参数设置，本身也可以放入svn进行版本控制。

好，上面说的是关于配置型参数的解决方案。如果是牵涉到某些业务配置的话，那更多的就是设计上的问题，3种办法：
1.ant脚本在编译之前修改源代码中的注解信息，呵呵，刚刚拍脑袋想出来的，好像也没啥不好的，未经实践论证，感觉理论上也可行啊。
2.像Hibernate的注解和配置是可以同时使用的，把必要信息放在配置文件中，风格和方式不统一，不是很好。
3.设计上事先确定好哪些参数是要随不同的环境或不同的客户需要在ant任务中灵活修改的，这些参数就必须要独立出来，采用配置文件的方式，剩下的就可以认为和实施层面无关的参数，凡是能用注解简化配置的尽量用注解。那这个方法的关键就是“是否是实施参数”的标准，这个标准每个人都不一样了，有人会说某个参数实施的时候可能会变，但是实际情况是这个可能性根本不存在。

68 楼 amonlei 2008-11-01  

yuzhu712 写道

你开个软件公司就明白了 利润,成本,时间是最重要的,甚至超越了质量...

开玩笑，没有质量，哪来的利润？靠忽悠？

67 楼 jindw 2008-11-01  

icewubin 写道

jindw 写道

这里我倒是看到了xml和annotation之间有一个代码生成的需求。

annotation最大的好处是，IDE语法检查，重构非常友好。
代码紧凑，同一个事情不必不同文件间反复跳转。

这对开发非常有利。

但是一到实施就麻烦了，不要我改一点配置就重新编译吧。

hibernate 有自己的官方annotation2xml转换工具，其他的呢？webwork，spring这方面有没有工具支持？

我不明白的是你为什么会产生改Hibernate配置的需求，我们可以探讨一下你是什么场景需要，至少我认为是不需要的。

其他的类似，我既然说大部分配置是为代码服务的意味着这些配置只要修改，往往就需要修改代码，如果真出现你认为的只改配置不改代码我认为是有问题的。有兴趣我可以深入和你探讨各种细节。

至于实施型配置文件，我也说点具体的：
我认为实施的时候即使是实施型xml也不能随意修改，都应该用ant统一自动修改并打包，这样才能便于测试和发布、版本的跟踪和分支控制，否则都靠人工该配置，很容易失控，或者是由于配置引起的bug而导致回归测试不能重现错误，都是要尽量避免的。

如果是一个独立的项目，修改的可能性是不大，如果作为一个通用的产品这种需求还是会比较常见的，譬如，如我们可能修改一些Spring服务的可选具体实现。hibernate配置的需求更少见一点，但也不能完全排除这种需求，比如对一些缓存参数的设置。可能会更具具体环境做修改。

66 楼 icewubin 2008-10-31  

jindw 写道

这里我倒是看到了xml和annotation之间有一个代码生成的需求。

annotation最大的好处是，IDE语法检查，重构非常友好。
代码紧凑，同一个事情不必不同文件间反复跳转。

这对开发非常有利。

但是一到实施就麻烦了，不要我改一点配置就重新编译吧。

hibernate 有自己的官方annotation2xml转换工具，其他的呢？webwork，spring这方面有没有工具支持？

我不明白的是你为什么会产生改Hibernate配置的需求，我们可以探讨一下你是什么场景需要，至少我认为是不需要的。

其他的类似，我既然说大部分配置是为代码服务的意味着这些配置只要修改，往往就需要修改代码，如果真出现你认为的只改配置不改代码我认为是有问题的。有兴趣我可以深入和你探讨各种细节。

至于实施型配置文件，我也说点具体的：
我认为实施的时候即使是实施型xml也不能随意修改，都应该用ant统一自动修改并打包，这样才能便于测试和发布、版本的跟踪和分支控制，否则都靠人工该配置，很容易失控，或者是由于配置引起的bug而导致回归测试不能重现错误，都是要尽量避免的。

65 楼 jerry 2008-10-31  

大家都在用着快速开发生成的javaeye确又在异口同声的说着ROR不好。呵呵

64 楼 edwardpro 2008-10-31  

lz自己理解的快速开发和现在的快速开发不是一个概念,快速开发不是代码生成,java本身不是脚本语言,不合适搞代码生成,搞配置生成还可行.grails应该是真正意义上的快速开发框架.而楼主的代码生成器,代码一旦静态化之后就有很多问题,包括版本更新等都是不可预见的...所以我觉得本身lz理解上就有偏差,那后面的评价就不置可否了.

63 楼 anky_end 2008-10-31  

我比较赞同楼主的想法。
其实随着业务的复杂化，代码生成器或者所谓快速开发框架越发变得不适用。
与其为了生成所谓快速代码而投入精力，
不如采用简化的结构，在设计和可维护性上下功夫。