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

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

引用

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

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

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

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

评论

22 楼 gaoran2008 2008-10-30  

其实,大家看上去都美.

21 楼 reasonsoft 2008-10-30  

，用它来做配置文件的工作是绝对不妥当的。还不如直接在代码里面硬编码呢。

quote]
你用过jpa吗，用过Annotation吗

20 楼 qamer 2008-10-30  

快速开发 <> 代码生成

19 楼 Frederick 2008-10-30  

毕业后第一次工作，一个前辈就跟我说如果项目需要使用代码生成器，那么一定是设计有问题。
呵呵，从那以后，从来都没有想过也没有在项目中发现过有使用代码生成器的需要。

18 楼 axeon 2008-10-30  

快速开发是好东西，省时省力怎么能说坏呢？
提高工作效率老板也高兴，员工也开心啊，客户也爽啊。

上面说的一些问题也有道理。
1.封装。我想这也可以理解是针对本土化项目的一种改良。老外的东西未必都是好的，未必适合中国人。比如老外的炊具，又是不锈钢，又是医用材料，贵就一个字，做出来的中国菜难吃的要命。就这还一帮子人捧双立人之类的臭屁。有些玩意，除了可以摆出来看，真的没法用的！

2.代码生成。生成后的东西，我想如果需要重复生成的，那么就从设计上避免手工修改这块，否则真的没法用。但是灵活使用代码生成，真的可以提高效率。

从某些程度上来说，做基于ssh的快速开发，整个就是捧ssh的臭屁。这些玩意压根就和快速开发没关系。所以要做，干脆就脱离ssh，程序运行效率会高上一层楼的。

快速开发框架不能广泛传播，我想原因有二：
1.只是改良不是创新。改良的东西确实缺少噱头，没噱头的东西就难以推广。要是整一套什么soa，云计算，或者干脆你起一个英文缩写的名字，后面追屁的人一堆一堆的。当然最好是源自外疆的，要是国内的，没准一棒子sb还要通过用砖头砸你来证明他的高明。
2.本身是一套解决方案，而不是几个jar包，或者所谓框架吧。解决方案就需要有整套的咨询，推广难度要更大。这种东西确实适合公司来推广，无论是不是一堆狗屎，你放心，也能推得出去。你的就算是黄金，靠口口相传，也传不了几个人。

17 楼 swachian 2008-10-30  

yanwt 写道

raymond2006k 写道

很同意大家回复的观点。

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

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

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

国人实干的人太少了，大部分都是光说不做的。

没办法,我们以说为荣,以做为耻.

16 楼 amonlei 2008-10-30  

longlongriver 写道

jindw 写道

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

引用

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

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

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

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

很有幸，我也被楼主列为反面教材了，呵呵！
不过楼主能把一个代码生成器的源代码整成6.5M，在我看来实在是夸张了些，我不敢说你对平台的理解有误，但我可以肯定，你把平台这个东西复杂化了！也许是在下粗鄙，做的东西实在不登大雅之堂，我的整个代码生成器也就40多个类，不到5000行的代码量，这个估计也抵不上楼主的一个零头了吧！
至于这个东西有没有用，有什么用，我想在我的文章里大家都已经仁者见仁，智者见智了，实在也没必要在这里再重复个一二三了！
其实我个人觉得这完全没有必要成为一个问题，也不应该是个问题！是不是自己做基础平台和代码生成器这个东西，完全是你个人、团队的事，有能力就做，没有能力就别做！至于做出来的人要在这里发个贴，给感兴趣的同仁们一个参考什么的，也完全是一片好意，完全没必要上纲上线。大家都是从事脑力劳动的人，有意识，有主见，也不是我们这些小程序员一两篇文章所能忽悠的！
至于楼主说整这个东西得公司行为，个人做不了。我倒不敢苟同，至少对于我们团队来说，我们把这个东西做出来了，而且用的很好，这就足够了，至于别人是不是认可我们的东西，我倒不是太关心（诽谤除外 ：） ），我们也没有成天想着如何把这个东西像ＸＸＸ公司那样卖他个百八十万的，我们这些文章，大家若觉得有用就笑纳，没有用就当放屁，呵呵！不过单从文章的访问量来看，我想也不至于人人都当俺们是放屁吧，呵呵！
另外也给楼主提个建议，不要动不动把普元扯进来，难免让人此地无银三百两，沦为枪手贴之嫌！

有点激动了，给楼主冷水泼的，不过说实话，代码生成器，看起来很美，用起来。。。呵呵。。。鸡肋

15 楼 Julien 2008-10-30  

我自己做过代码生成器玩，生成的代码如果还要可以个性化编辑，其维护是个噩梦
比如说，今天你用代码生成器生成了20个文件，然后在之后的一个星期里持续的对其中的几个进行了修改，一个星期结束后，你发现需求发生了变化，你必须在代码生成器里作一个配置上的调整，然后重新生成20个文件
现在问题来了，你重新生成20个文件不是要覆盖你已经修改过的不确定诺干个文件么？你修改的内容不是白做了？难道重新再来一次？就算用SVN比对着一点一点重新把你的个性化特性加一遍也要一个晚上，你必须把新生成的代码全部重新读一遍才知道在哪里加某个东西，这部分工作量完全是无妄之灾
但是如果这个结构是由基类实现的，或者是用动态语言的注入系统，这个问题就很小很小。只有基础配置的修改影响到了扩展的实质性功能的时候才需要修改扩展部分的代码，否则就无缝过渡了。
java玩到最后觉得需要代码生成，说到底还是静态强类型语言能力太弱了。ROR里都是硬往类里eval函数代码的字符串，绝对是正宗到不能再正宗的代码生成，但是整个应用的逻辑仍然非常容易看懂非常容易修改和扩展，可以随时在基础配置上动手脚，不会造已经完成工作的颠覆性的破坏。

14 楼 ccxw1983 2008-10-29  

我们的目标就是提高效率，如果代码生成器确实方便，干嘛不用？
任何东西都不是完美的，所谓尺有所长，寸有所短，合适就好。一个简单的项目，有必要搞那么复杂？
诚然第一种方式是好，但是没有方法是万能的，我觉得2者要结合，如果逻辑上确实有很多公用的东西，能够放到公用类、父类里面，当然还是要提取出来，这方面的东西用设计模式来减少代码。
有些东西如jsp、vo类用代码生成器挺好的。生成出类似结构的东西并不是重复，因为只是只是相似而已，生成的这些文件的重复的东西已经用第一种方式精简过了的。生成实体的这些文件也方便调试、个性化的编辑。并且性能上比动态编译、用反射的那样好。

13 楼 raymond2006k 2008-10-29  

很同意大家回复的观点。

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

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

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

12 楼 cats_tiger 2008-10-29  

楼主说的有道理，给我这个打算做类似东西的人降了降温

11 楼 Julien 2008-10-29  

软件技术里面的类继承复用，xml配置，本身就可以说是一种代码生成技术
说不上是什么新玩意，只要你选用的语言足够能打（RUBY之类），
代码生成软件的工作都可以在代码本身的层面完成，不需要额外再进行自动生成
软件工程和工业工程的最大的区别就在于，软件工程是可以做到完全没有重复设计的。我们不需要流水线也不需要工人。

10 楼 mzhanker 2008-10-29  

我个人是很赞同代码生成的

  1):代码生成的前堤必有一个好的自已熟悉的框架.
 
  2):代码生成一般建议只做一些简单的CRUD的动作.不要作的太复杂,

     它只代替你以前的copy ,paster,replace的动作，与业务逻辑的复杂
    
     无关。

3):代码生成的东西般都是有规律性，这包括,jsp,service,dao，甚至是     javascript 

 
4):一般来说，代码生成后，还要靠人工来修修补补.

我一般是把它作为开发的一个辅助工具来使用,对于那些想商用的，或已经商用的，或做的特别

复杂的，我的观点和其它朋友一样，不太现实!

 

9 楼 jindw 2008-10-29  

fireflyc 写道

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

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

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

8 楼 jindw 2008-10-29  

呵呵，首先我得申明一下，我并没有任何恶意，看到你们做得东西确实也很不错。
大家都是过来人了，其中滋味我想大家自己也很清楚。当能，承认这里的个体差异。

有一天，我要去敲一个钉子，那么我有下面三个选择：
1。接合自身特点，自己铸一把锤子，把这个钉子丁下去。
2。市场上买把或者邻居家借把普通得锤子，把这个钉子钉下去。
3。随便找一快能用得石头，吧这个钉子钉下去。

没有任何一个选择是任何时候都正确。不同的人，不同的职业阶段，不同的环境我们会有不同的选择。

从成本的角度考虑，选择不同的方案取决于我有多少钉子去钉。
从个人成就感考虑，我们可能毫无疑问的选择方案一。

7 楼 longlongriver 2008-10-29  

jindw 写道

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

引用

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

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

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

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

很有幸，我也被楼主列为反面教材了，呵呵！
不过楼主能把一个代码生成器的源代码整成6.5M，在我看来实在是夸张了些，我不敢说你对平台的理解有误，但我可以肯定，你把平台这个东西复杂化了！也许是在下粗鄙，做的东西实在不登大雅之堂，我的整个代码生成器也就40多个类，不到5000行的代码量，这个估计也抵不上楼主的一个零头了吧！
至于这个东西有没有用，有什么用，我想在我的文章里大家都已经仁者见仁，智者见智了，实在也没必要在这里再重复个一二三了！
其实我个人觉得这完全没有必要成为一个问题，也不应该是个问题！是不是自己做基础平台和代码生成器这个东西，完全是你个人、团队的事，有能力就做，没有能力就别做！至于做出来的人要在这里发个贴，给感兴趣的同仁们一个参考什么的，也完全是一片好意，完全没必要上纲上线。大家都是从事脑力劳动的人，有意识，有主见，也不是我们这些小程序员一两篇文章所能忽悠的！
至于楼主说整这个东西得公司行为，个人做不了。我倒不敢苟同，至少对于我们团队来说，我们把这个东西做出来了，而且用的很好，这就足够了，至于别人是不是认可我们的东西，我倒不是太关心（诽谤除外 ：） ），我们也没有成天想着如何把这个东西像ＸＸＸ公司那样卖他个百八十万的，我们这些文章，大家若觉得有用就笑纳，没有用就当放屁，呵呵！不过单从文章的访问量来看，我想也不至于人人都当俺们是放屁吧，呵呵！
另外也给楼主提个建议，不要动不动把普元扯进来，难免让人此地无银三百两，沦为枪手贴之嫌！

6 楼 stephen830 2008-10-29  

能够互相结合是最好的。80%的工作由电脑自动完成，剩余的20%再花脑子去完成。

5 楼 superdandy 2008-10-29  

downpour 写道

做Java也几年了，从来不觉得所谓的代码生成技术有什么好处，也从来没有看到一个框架能做到所谓的快速开发。

在企业应用领域，业务逻辑都比较复杂，简单的代码生成不具备可用性是毋庸置疑的，这些logic你都能生成？客户来一句业务限制你马上歇菜。

在互联网领域，由于界面和设计上的改动，整体结构的变化很大，所以代码生成技术带来的好处也不大。至于说到快速开发框架，谁能保证它的性能？谁能保证它的无限可扩展性？

综合来说，踏踏实实写你的代码，不要试图通过投机取巧来获得任何好处，这样的结果只能让项目变得更烂。

另外想提一点，在开发过程中，最佳实践总是不断总结的，而还有一些通用组件会被不断提取出来，这些通用组件与所谓的代码生成或者快速开发框架并没有很大的联系，不过这些最佳实践和通用组件能大大降低我们的开发成本。

确实如此。用手写代码，不光是一个编写的过程，更是一个体会的过程。 如何，把一些近乎公式化的代码写得更优雅，更有效。 而这些快速开发框架，只能秀出开发人自己的技术有多强大，对于实际业务没有什么用处，可能还会有一些隐藏的问题。

针对我现在的项目，手下的几位仁兄一直抱怨框架烂，很多重复的代码什么的。 我开始也是这种想法。 但是没有办法，在我接手的时候，框架早已完成了。 于是按照这种情况，我也给他们设计了一个基本的代码设计器。 由于是贴合业务的，所以说并不复杂。 但是，随后在客户websphere发布时出的一个十分诡异，甚至花高价请专家都无法解决的问题，让我彻底放弃了我那个自动代码生成器。 放弃了所有由那个生成器生成的代码。

4 楼 downpour 2008-10-29  

做Java也几年了，从来不觉得所谓的代码生成技术有什么好处，也从来没有看到一个框架能做到所谓的快速开发。

在企业应用领域，业务逻辑都比较复杂，简单的代码生成不具备可用性是毋庸置疑的，这些logic你都能生成？客户来一句业务限制你马上歇菜。

在互联网领域，由于界面和设计上的改动，整体结构的变化很大，所以代码生成技术带来的好处也不大。至于说到快速开发框架，谁能保证它的性能？谁能保证它的无限可扩展性？

综合来说，踏踏实实写你的代码，不要试图通过投机取巧来获得任何好处，这样的结果只能让项目变得更烂。

另外想提一点，在开发过程中，最佳实践总是不断总结的，而还有一些通用组件会被不断提取出来，这些通用组件与所谓的代码生成或者快速开发框架并没有很大的联系，不过这些最佳实践和通用组件能大大降低我们的开发成本。

3 楼 ajf8 2008-10-29  

本人的思路就是减少代码量
生成的代码也是代码，而且都是重复代码，通过一些手段可以消除这些重复
达到精简代码，快速开发的目的
有兴趣可看看鄙人整的东东
 
http://www.iteye.com/topic/257804