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

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

引用

秀一下我的快速开发平台
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程序员可能都有一个好大喜功的特性，环境所致把。

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

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

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

评论

102 楼 jxausea 2008-11-20  

否决楼主意见！人正是因为偷懒，所以才产生计算机代替人做事的！

101 楼 pf_miles 2008-11-05  

若经常做点什么东西，可以自己写一些小小脚本，小小的工具，只有自己或者身边的人会用，让大家做这类事情的效率提高，就达到目的了；
若打算做一个“框架”，那就是打算让很多人来用，是很费力气的；
有时候应该考虑其投入产出，是否值得花这么大力气去做？你认为很NB的东西是否能达到同样NB程度的效果？
这么考虑之下，我也不赞成随便地认真地就将“做框架”当回事儿.

不过话说回来，楼主大可不必去泼人家冷水，因为我认为这些做框架的人也不是“很傻很天真”，不可能真的为了写一个将来人人都要用的“世界级”的框架而操劳，其实他们大多数人都只是想玩玩而已、试一试而已，把自己玩的阶段性成果跟大伙儿showshow而已，对不？反正类似的应用技术，蹦达来蹦达去也就那么点东西...而正是这些陈出不穷的玩物构筑了JE的生态圈么~

100 楼 daquan198163 2008-11-05  

aws 写道

假设，一个不恰当的假设，用hibernate+mysql做一个桌面的应用，可能让用户随意修改hbm配置文件么，这是基本不可能的事，hbm配置文件就是专用型配置文件，这种类型的配置就应该放到代码中去，增加可读性。专用配置是写给开发人员看的，不是让用户随随便便改来该去的。

但有支持不同类型数据库的需求，使用hbm文件的换一套映射文件就行了，写注解岂不是要换代码

改dialect即可，怎么会需要换hibernate映射

99 楼 icewubin 2008-11-05  

aws 写道

假设，一个不恰当的假设，用hibernate+mysql做一个桌面的应用，可能让用户随意修改hbm配置文件么，这是基本不可能的事，hbm配置文件就是专用型配置文件，这种类型的配置就应该放到代码中去，增加可读性。专用配置是写给开发人员看的，不是让用户随随便便改来该去的。

但有支持不同类型数据库的需求，使用hbm文件的换一套映射文件就行了，写注解岂不是要换代码

那照你的逻辑，这算是客户需求么？如果是的话，是不是说但凡桌面应用用到数据库必须提供一套类似hbm的配置文件，凡是不能提供此类文件的全都是不够灵活的桌面应用？

这个需求就是臆想出来的。

1.对客户来说，不存在这样的需求。

2.对开发人员来说，换数据库为什么要修改字段？请详细说出真实项目这样的场景，核心代码不变，数据库改了，但是只有字段名改了其他任何东西（如表之间的关系）都一模一样，可能么？


hbm配置文件的本意是用来提高灵活性的么？不是，本意是用来配置关系映射的（因为早期JDK不支持注解这种方式），不是用来实现不存在的需求中的灵活性的。

另一个例子就是ibatis的配置文件，难道最大的原因是为了改sql不改代码么？这不是最大的理由，因为这个配置文件是为开发人员服务的，集中的存放了sql语句，便于开发人员维护和调优。

struts 1.x中的配置页面逻辑的配置代码就更莫名其妙了，只改页面跳转路径就能搞定某些修改需求么？不可能的事。早期的Java框架就是这种配置优于代码的思想高高在上，导致开发、修改、维护效率（相对的）低下，当出现ROR型的框架，现在开始反思了，反思中的一项就是，造出这么多实际项目根本不会出现的需求场景有必要么？

98 楼 aws 2008-11-05  

假设，一个不恰当的假设，用hibernate+mysql做一个桌面的应用，可能让用户随意修改hbm配置文件么，这是基本不可能的事，hbm配置文件就是专用型配置文件，这种类型的配置就应该放到代码中去，增加可读性。专用配置是写给开发人员看的，不是让用户随随便便改来该去的。

但有支持不同类型数据库的需求，使用hbm文件的换一套映射文件就行了，写注解岂不是要换代码

97 楼 icewubin 2008-11-05  

laoxing521 写道

典型的简单的事情复杂化
没有强制你所有的代码都用代码生成器，也没有强制你从项目一开始到后期维护全都用代码生成器，更没有说是动态生成。只是在需要的时候，生成一下， 简少一些机械性的重复劳动，为何不用？


打个比方，项目刚启动， 要写一堆POJO，DAO，XML，这个时候你是愿意用代码生成，只要往生成器里面填个类名，填几个属性，按钮一点，就把一些雷打不变的JAVA文件，映射文件，DAO中的CRUD方法都生成了，然后再抛开代码生成器，根据实际需要具体事情具体做，

还是愿意连长得都一个样的POJO都自己一个一个去写？

-----------－－－－－－－－－
快速开发框架 >> 代码生成器

这些快速开发框架并没有说要给你解决所有的问题，什么情况下都能用上，让你自己连一行代码都不用写。它它只是对常用的开发模式，一些遍地都能用上的方法进行封装，并附上一个代码生成器，让那些长得都一个样的代码动生成，并保护你的键盘，免得你把ctrl+c, ctrl+V给敲坏了。


如果我们的项目不是很个性化，那我们为什么要抛弃这些框架？

问题就出在“只是在需要的时候”，什么时候是需要的时候？每个人理解不一样，偏向性不一样，导致框架的发展方向也不一样。

举个例子，ror中的约定大于配置思想，hibernate中也可以自动把类名和属性名从驼峰式命名自动转换成数据库下划线分隔式命名（NormalUser -> NORMAL_USER，userName -> user_name），参考org.hibernate.cfg.ImprovedNamingStrategy。这是一种策略，当然另一种策略就是完全靠代码自动生成“注解”或“hbm”。

在有这两个策略之前，不同的人的倾向性一定会往不同的思路上去解决问题。当然不是所有的代码生成的实践都能用某种技巧或约定或运行时生成来代替，但是人一旦思维懒惰，当碰到一些棘手问题，本人已掌握的解决重复的能力（比如OO）不能很方便的解决时，就求-助于代码生成，这样的思维方式就是不对的。代码生成应该是比较靠后的解决方案，而不是优先方案，或者说在可能的情况下尽可能减少代码生成的比例。还是以上面这个例子为例，假设整个POJO都是代码生成的，如果用了ImprovedNamingStrategy，则可以减少代码生成的代码量，也是推荐的。

最后再说一下，“只是在需要的时候”每个人理解都不一样。

96 楼 laoxing521 2008-11-05  

典型的简单的事情复杂化


没有强制你所有的代码都用代码生成器，也没有强制你从项目一开始到后期维护全都用代码生成器，更没有说是动态生成。只是在需要的时候，生成一下， 简少一些机械性的重复劳动，为何不用？


打个比方，项目刚启动， 要写一堆POJO，DAO，XML，这个时候你是愿意用代码生成，只要往生成器里面填个类名，填几个属性，按钮一点，就把一些雷打不变的JAVA文件，映射文件，DAO中的CRUD方法都生成了，然后再抛开代码生成器，根据实际需要具体事情具体做，

还是愿意连长得都一个样的POJO都自己一个一个去写？

-----------－－－－－－－－－
快速开发框架 >> 代码生成器

这些快速开发框架并没有说要给你解决所有的问题，什么情况下都能用上，让你自己连一行代码都不用写。它它只是对常用的开发模式，一些遍地都能用上的方法进行封装，并附上一个代码生成器，让那些长得都一个样的代码动生成，并保护你的键盘，免得你把ctrl+c, ctrl+V给敲坏了。


如果我们的项目不是很个性化，那我们为什么要抛弃这些框架？

95 楼 icewubin 2008-11-04  

fireflyc 写道

上面认为硬编码好的原因是居然是因为可以热部署，是动态的。

这就荒唐了。动态特征自古就有。动态性自古也有。
http://fireflyc.iteye.com/
如果说动态性能支持硬编码的话那么实在是说不过去的。

按照这个理论所有的配置我都定义常量好了，反正总是要重新编译重新打包发布的。
~也许我们期望有一天tomcat没有了配置文件，而是提供一堆java代码，我们修改常量然后编译发布。我们修改apache代码然后编译，使用。
我们还必须让windows公布源代码，因为注册表实在是太麻烦了。我们修改windows源代码，然后编译。任何安装程序都必须重新编译操作系统内核。

如果仅仅把软件把java作为一个简单的web开发未免太狭隘了。

至于说注解是否符合阅读性我觉得是仁者见仁的问题。为什么？注解本身就是一种附在代码上的东西，说它影响阅读那是一点也不差的。

对于是否减少重复的言论，可以这样说明，注解几乎是不可能减少重复的。你说配置我能做，那么注解也能做。哪里的注解比起配置是减少了配置所做的重复呢？

java语言本身的从1.4开始几乎没有进步。每次升级无非是增加更臃肿的API而已。仅仅如此。比起C#它可以说是一直在原地踏步走。

以上讨论我的所有观点不涉及商业，如果硬扯商业那就没有边了，我们坐下来能扯3天3夜。;-)~~~

热部署的言论我愣是没看到，估计是我不仔细吧。

我强调了不知道多少遍的部署型配置和专用型配置，不过好像只适合于项目，既然你谈到APP了，那就可以认为是不能用ant解决的部署型配置，那很正常啊，但是绝不等于专用型配置文件会让客户随意修改配置，这是不可能的。请不要总是把这两大类配置文件混在一起讨论，以前JDBC写出来的程序应用哪会有hbm这种配置文件，难道你就能说以前写的那种程序无可配置性？是因为这类配置文件根本就不是为客户服务的，是为开发人员服务的。

假设，一个不恰当的假设，用hibernate+mysql做一个桌面的应用，可能让用户随意修改hbm配置文件么，这是基本不可能的事，hbm配置文件就是专用型配置文件，这种类型的配置就应该放到代码中去，增加可读性。专用配置是写给开发人员看的，不是让用户随随便便改来该去的。

除了通用型配置（如spring的事务配置），xml配置（专指xml）的字符数一般一定是超过注解的，还有不要以为注解就是简单的配置用途，如果要实现某些配置文件中“继承”的特性要方便得多，请先多实践一下annotation的本质（这又不是简单的xdoclet文本）。

根据我说的两种配置文件的分类，请再仔细想想专用配置文件的用途到底是什么。

岔出去举个例子，某些动态语言，本身写起来就像写配置文件，然后你就把它看成配置文件不就行了，针对配置文件编程嘛。

回过来我还可以说，你如果写C的话，不也是写配置文件么，这个配置是用来告诉编译器生成二进制代码用的，不是么？

你怎么提到Java语言和C#的问题了？有人挑头了？

减少成本肯定是和商业有关的，否则为什么要说时间成本，技术的改进有相当一部分就是用来减少软件工程中各个环节的时间成本。

94 楼 fireflyc 2008-11-04  

上面认为硬编码好的原因是居然是因为可以热部署，是动态的。

这就荒唐了。动态特征自古就有。动态性自古也有。
http://fireflyc.iteye.com/
如果说动态性能支持硬编码的话那么实在是说不过去的。

按照这个理论所有的配置我都定义常量好了，反正总是要重新编译重新打包发布的。
~也许我们期望有一天tomcat没有了配置文件，而是提供一堆java代码，我们修改常量然后编译发布。我们修改apache代码然后编译，使用。
我们还必须让windows公布源代码，因为注册表实在是太麻烦了。我们修改windows源代码，然后编译。任何安装程序都必须重新编译操作系统内核。

如果仅仅把软件把java作为一个简单的web开发未免太狭隘了。

至于说注解是否符合阅读性我觉得是仁者见仁的问题。为什么？注解本身就是一种附在代码上的东西，说它影响阅读那是一点也不差的。

对于是否减少重复的言论，可以这样说明，注解几乎是不可能减少重复的。你说配置我能做，那么注解也能做。哪里的注解比起配置是减少了配置所做的重复呢？

java语言本身的从1.4开始几乎没有进步。每次升级无非是增加更臃肿的API而已。仅仅如此。比起C#它可以说是一直在原地踏步走。

以上讨论我的所有观点不涉及商业，如果硬扯商业那就没有边了，我们坐下来能扯3天3夜。;-)~~~

93 楼 zhang3 2008-11-04  

各位业内资深人士们，我要告诉你们我的多年的思考结论：

可理解性才是各种开发框架最本质的需要。这种需要是超越一切名词之争压倒一切的。

可理解性，就是指在看到一段代码的时候，是否能够快速的理解这一段代码的功能。
结构化编程，对象化编程，层次模型，高内聚低耦合，乃至现在流行的动态语言，
泛型，AOP，等等等等，无一不是在为此服务。



至于现在流行的开发框架，本人离开正经的软件行业已经很久了，所知不多，就不班门
弄斧了。仅仅对一个特点做一下评论，常见的开发框架，为了达到灵活的目的，常常采
用极其庞大的配置文件。这一点，是与可理解性背道而驰的。背负着庞大的配置库的一
段过程代码，无论如何是做不到容易理解的，往往还不如写入到代码中更为简洁明快。

其实，即使是配备庞大的配置文件，开发框架也可以通过各种我称之为“代码透视图”
的方法来达到这种可理解性的要求，让使用，生成和各种层次的修改都变得简洁。这
是另外一个层次的事情了，就不多言了。

92 楼 Else 2008-11-04  

作为一个软件设计人员，我们一直追求又＂好＂又＂快＂，然而它们是那么的难以和谐．EJB很好，但是不够快，于是就有了ssh，J2EE很好，但是不够快，于是有了RoR,RoR很快，但是还不够好，我们又要给它install plugin．

快速框架没有什么不好，但是要着眼于我们要解决的问题．这几年快速框架这么流行是因为我们发现我们的业务原来大部分都不是很复杂，共性的东西很多．

一个好的框架，至少是要满足开闭原则的．当碰到一个比较特别的需求时，查是让我把它开肠剖肚把源码改一遍，肯定是个不合格的产品了．

91 楼 gujianxin 2008-11-04  

谈谈个人看法，首先分析一下所谓快速开发框架的背景和目的，应该不外乎以下4种：
1，一切从0开始，既没有快速的，也没有不“快速的”，为了做东西而做；
2，已经有成熟的框架，不够“快速”、重复代码多，为了减少这些弊端，针对具体业务进行重构，加快开发人员的开发速度；
3，为了学习，在研究自己框架的同时，加深对现有框架的理解；
4，像LZ这样的有心人，别人做的我也能做，还要比别人做的好，比别人的开发起来快，生成代码、灵活配置。。。。。

===========
这样一分析，结合LZ的观点，我想大家可以统一意见吧？
前两种是适可而止，有益无害，我们不会反对。
第三种个人学习，不强求别人，在一定领域中实现其价值，也是鼓励的。
第四种应该就是LZ所要表达的意思，由于在学习推广和应用推广方面的问题，不宜投入太多。

90 楼 zhenjia 2008-11-04  

凡是代码生成的一般绝对不会去使用，
ORACLE ADF那套东西拖拉就行，或者知道表结构以后点几个按钮 N个针对表的维护页面就已经出来了，确实快，但是维护起来很恐怖。

生成代码不如好好设计设计框架，组件重用就好。慢也慢不到哪去。

89 楼 fkpwolf 2008-11-04  

很多人谈到市场去了。。。。。

88 楼 czwlucky 2008-11-04  

yuzhu712 写道

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

没有金钢钻就别揽瓷器活儿，只重质量不计成本者和只计成本不讲质量者，结局是一样的。但，最终目标的实现，还应该是建立在质量的基础上。如果忘了这一点，那么看看三鹿的结局就知道该如何选择了。楼上有朋友说如果你的项目中需要代码生成器，那么说明你的设计是有问题的(我并不知道这个说法是否成立，但其精神值得学习),同样，如果你需要追求成本降低，以"维持"生存，那说明你的选择也是有问题的。

87 楼 czwlucky 2008-11-04  

jindw 写道

fireflyc 写道

一种，减少代码量。
第二种，代码生成技术。
。。。。

总结的非常不错。
关于第一种情况，主要是框架乃至编程语言的改进。能做到这点当能是最好。

但是现实中我们往往只能退而求其次。我们往往是游走在不同的第三方框架提供的服务中，比如说我们用hibernate，用spring，用webwork，而他们是相互独立的系统，我们只是在他们的狭缝中游走，代码生成在这里也就成了一中可选的黏合剂。

“黏合剂”这个词用的不错 在利用第三方框架的时候，关于配置及一些类的生成确实是无聊枯燥的，借助代码生成器生成，也许是最省心省力的了，呵呵

86 楼 amonlei 2008-11-04  

icewubin 写道

amonlei 写道

yuzhu712 写道

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

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

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

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

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

政府项目 = 软件项目？？？政府项目又如何？我也是做政府项目出身的，每天死一次机看看你的公司还要不要开。。不要以点盖面。。。。

85 楼 amonlei 2008-11-04  

sphenx 写道

sphenx 写道

jindw 写道

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

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

这对开发非常有利。

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

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

用xml还是annotation的关键是，你的配置指定的属性到底是依赖于环境还是依赖于自己
1. xml是用于做外部资源指定的，它会随环境变化而变化。如，用xml指定连接的数据库的属性。
2. annotation是用来指定自身属性的，它只随自身的变化而变化。 如，用annotation指定一个bean是否是serializable。

如果在第一种情况下用annotation，显然有害无益；反之也一样。所以，xml和annotation各有优缺点，各有擅长。一味的用xml或一味的用annotation，都有问题。

xml重用性强，annotation方便、可读性强。

84 楼 amonlei 2008-11-04  

daquan198163 写道

justshare 写道

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

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

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

赶走一只狼，引来一只虎

严重同意

83 楼 lu674035 2008-11-04  

raymond2006k 写道

很同意大家回复的观点。

我的感觉， 美国人(或者外国人)做的东西， EJB，Hibernate，Spring，.... 中国人都会虚心学习；即便有缺点，也不太会有大的反对，而会探究是否是误用。

而同样的东西，中国人做出来，首先自己都觉得怀疑；还没详细了解清楚，就挑三挑四。中国人缺的就是自信，对自己自信，对他人自信。其实，我呆过的几个公司，都有技术牛人，能做二次封装，改良，或者框架等，而且做的都很棒；如几个牛人集中起来，也能做很多框架出来。现在 javaeye上的牛人也很多啊 。

只是希望国人对他人的创新多多互相评估，试用，以建设性的态度提意见，提缺点，提改进意见。

说的好！