最近开发了一套代码生成工具。

好久没更新日志了，我最近花了大概一个多月的时间做了个代码生成工具，生成的代码都是和公司的框架相关的，生成相应的后台代码和前台代码和配置文件，目前可以通过数据表和po来生成相应的代码，那么可以生成单表，树型单表，主从表，树型主从表这几种模式。当然它生成的只是这个项目里面最常用的操作，比如新增，修改，删除，导出等等。那么生成的逻辑都是最简单的逻辑，开发人员可以在生成后的基础上，将具体的逻辑判断加进去。生成的界面就是列表页面，新增页面，修改页面，查看页面。当然如果是主从表，那么就会生成从表的维护页面，那么前台页面的基本验证都可以生成好了，比如日期，是否为空，是否是数字等等。


我个人感觉它有以下三个作用。
1.可以提高一定的工作效率，因为可以生成60%-80%的代码，而且有IO处理，是可以直接生成到你指定好的工作目录里面去。开发人员之用将生成的配置文件拷贝到相应的目录即可，那么开发人员可以把更多的精力投入在复杂业务逻辑和技术攻关里面。
2.可以让项目做的更统一，因为生成的后台代码和前台代码是统一的，界面也是统一的，那么项目就是统一的风格，不会出现这个人的界面是一样，其他人又是另一样。
3.可以节约单元测试，系统测试的成本，不用局限于测一些共性，简单的功能。

但是这个生成工具是以一个稳定的开发框架和一套界面标准为基础的。

在下一版本，我将做以下修改。
1.增加xml数据源和json数据源（目前是数据表 或者po）
2.将框架的模板，代码和 业务数据分开。（这是个大的工作量），这样可以适应各个不同的开发框架。
3.加上预览的功能，主要是预览界面的布局。
4.加上高级布局功能，让布局更加灵活。

希望大家对我这个生成工具多多提些建议，我想3月初就在公司里投入使用。

评论

95 楼 guichenguang 2008-10-26  

不知道楼主对本公司的框架的依赖程度大么？主要框架是什么？开源当然好，继续关注。

94 楼 xmx0632 2008-10-26  

俺觉得,代码生成器的质量,主要取决于代码模版本身的代码质量的好坏.只要代码模版够简洁,生成的代码越少,就越容易维护.跟你代码生成器是用什么eclipse插件、emf、freemarker、velocity写的毫无关系.

ps:俺理解的代码生成器的本质就是根据一些元数据生成一个个字符串，按照一定的目录结构写到一个个对应的文件里。

93 楼 erikchang 2008-10-26  

个人认为这种生产工具只能起到很小的作用，使用模板技术很容易生成，某些时候还不如动手复制粘贴一下！

92 楼 21xionghua 2008-10-25  

代码生成在很大程度上还是可以方便我们的。难道反对代码生成的同志们还每次手工去写set/get方法？如果100张表那是多么恐怖的事。
另外可以起到一个团队开发中命名规范等效果，至于业务逻辑当然得手工来弄。
顺便说一下我的代码生成工具：JSmart，是以eclipse插件形式出现的。像常规环境、代码生成都有集成。
地址：http://www.iteye.com/topic/255542

91 楼 williamy 2008-07-15  

罗嗦的和唐僧一样，有本事就搞一个好的东西出来，
不管是抄袭也好，直接把别人的拿来改个名，还是全部自己开发都好
无所谓，只要能够拥有里面的思想，同时这个思想很伟大，那么都是值得赞赏的

至于唐僧那种嘴里老是去取经，却一直不行动的那种，基本上应该拉出去喂青蛙

90 楼 soleghost 2008-07-15  

公开下代码嘛，我想看看从代码上学习学习这个底层的代码生成工具

89 楼 lijingbo9512 2008-07-07  

加油啊 ，我试试看

88 楼 kimmking 2008-06-22  

我们也做了一些工作

觉得freemaker或者velocity做的太死，生成项目的灵活性太差，不能修改后增量生成。


现在考虑emf，gmf之类的东西来做。

87 楼 leemingjun 2008-06-22  

基于模型的话，这个是可以定义的，就是说可以定义字段的唯一性、对于CRUD过程中出现的错误如何处理等等
也就是说部分通用的也无逻辑可以在代码自动生成的时候考虑进去的

downpour 写道

惊鸿逝水 写道

不管是不是ORM，就算是简单的DAO也可以用一条语句实现，但是面对类似的几十个的CRUD(只是表名不一样)，用代码生成器选择多个表，1秒钟就帮你批量生成所谓的重复代码，总比手写有效率吧！

和你怎么说不明白呢？在一个复杂的企业应用里面，是极少有纯的CRUD代码的。你在添加一个User的时候，难道不用去校验其用户名是否已经重复，就直接save进数据库了？对于每个表，CRUD的逻辑都不一样，你的代码生成有甚么意义？

基础代码的含义是针对框架的简单封装，具体的业务逻辑开发需要的则是大量的业务分析和单元测试，这恰恰都是一个软件和核心，迷信甚么代码生成的，我敢说，写出来的代码多数都是无法满足严格的单元测试的。

86 楼 leemingjun 2008-06-22  

如果代码基于模型，就是说用户关心的业务模型的话，那么，这个代码自动生产还是有用处的

代码模板是以局限性的，是固定的是不变的。但是不同的项目来说，需求是变化的，所以基于
模型就可以灵活的生成针对需求的代码。

任何程序都可以细分为三个部分，输入、加工、输出。输入方面现在的应用系统来说往往是
用户的操作和内置的。输出就是呈现来。对于业务逻辑的处理功能肯定是需要手工开发的。
但是输入、输出的工作是可以通过定义呈现模型加上少量修来来完成的。

从上面的意义来说，这就节省了工作量了。这个代码自动生成工具就有价值了，对吗？

daquan198163 写道

关于你说的三个作用：
1.可以提高一定的工作效率，因为可以生成60%-80%的代码，而且有IO处理，是可以直接生成到你指定好的工作目录里面去。开发人员之用将生成的配置文件拷贝到相应的目录即可，那么开发人员可以把更多的精力投入在复杂业务逻辑和技术攻关里面。
2.可以让项目做的更统一，因为生成的后台代码和前台代码是统一的，界面也是统一的，那么项目就是统一的风格，不会出现这个人的界面是一样，其他人又是另一样。
3.可以节约单元测试，系统测试的成本，不用局限于测一些共性，简单的功能。
=============================================================
1、我认为通过代码生成来提高工作效率很有限，因为磊代码只占整个开发工作量的很小一部分，
而且根据你的说法，应该是在一开始的时候一次性的生成一些基础代码，其实完全可以用项目模板来做这件事。
2、同上
3、能生成的只是少数，大量的新开发业务逻辑还是需要单元测试

85 楼 newdev 2008-06-18  

我也做过一些，主要是使用freemaker或者velocity等模板来实现，只能是符合公司的代码框架、规范，真的太小儿科，不是打击LZ，一个月时间真的太久，几个小时就可以完成的事情

84 楼 cljhyjs 2008-06-17  

fang9159 写道

.......
1.可以提高一定的工作效率，因为可以生成60%-80%的代码，而且有IO处理，
......

60%-80%的代码有点悬乎，呵呵，那么项目的业务代码能占多少呢？？

83 楼 lingzantia 2008-03-14  

代码生成的话,那需要代码模板配置,目录结构配置,建议参考jsp生成html的过程

82 楼 icewubin 2008-03-12  

<div class='quote_title'>fang9159 写道</div><div class='quote_div'>to icewubin: <br/>你好，感谢你给了我这么多的建议，非常感谢你能让我在不同角度去看待一些问题，让我的眼界开阔许多，当然我的理想也是向这方面努力。 <br/>我先想和你讨论下前台方面的问题，我们公司也是有你说的这种情况，浪费开发人员时间恰恰就是前台这一块，他们主要在以下方面浪费时间： <br/>1.js技术不扎实，新人一般是刚刚才接触，导致不好的代码风格而带来难维护性 <br/>2.他们不遵从界面标准，标准是有，但是他们不遵从，评审也做，但是执行效果不好，这又提到一个执行力的话题去了。 <br/>3.兴趣方面的问题，据我的了解，10个程序员大概只有2个人对前台技术感兴趣的。 <br/>这些原因造就了前台成为项目开发过程中的一个绊脚石。我呢，在这方面做了以下办法。不知道可不可以对你碰到的情况有一些帮助。当然有些办法是失败的，但我也提出来，也许开发环境和公司文化的不同，方法的效果就不同。 <br/>1.对前台技术做培训，虽然目前ext，jquery，包括锐道都是很不错的webui框架，但是也需要程序员对js，css，都有一定的基础。目前这一块没持续做下来。 <br/>2.前后台分层开发，这样做也有如下问题：(1):对设计师要求非常高，要求他们能够做比较好的任务分层和模块分层。(2):公司的资源也不够。 <br/>3.既然开发人员不遵从标准，那我们就给他生成这种标准。我们把他们感觉很烦也不想动手做的东西都生成出来（比如一些宽度，字体大小，一些验证，日期，非空，整数，一些控件的用法，combobox，datagrid等等这些用法).那么这个其实才是我做生成工具的初衷。 <br/>另外我们公司没有选择ext2.0。ext2.0的确做的不错。而且dwr与ext也是不错的结合，这些技术在公司推广还有一段时间，但目前公司的项目在启动。这中间有个时间矛盾。我们倒是开发了一些常用的webui控件，datagrid，日期控件，tree，menu，动态下拉框等等，这些也能够满足我们的需求。 <br/>第二个和你说说培训的事情，做很多事情是要有个基础的，比如公司本身的文化，我们也是很低的成本招聘一些刚毕业的新人，也是花了心血去培养他们，他们也非常忠诚于我们，但是他们不会忠诚公司。但我个人的想法和公司的想法其实不同的，我觉得只有员工在进步，整个公司才会进步，而且公司应该考虑适当的换一下新鲜血液。 <br/>第三个开源，我很想将这一套能够开源，但是目前不成熟，对个人也好，对公司也好，对项目也好，我都没有很多精力来维护和交流，这个我是计划这个项目能完成后，再拿出来开源。我也明白开源对我自己本身都好是会为我带来什么！而且目前这个工具和开源还是有很大距离的，因为毕竟做的不是eclipes插件。 <br/>好的，一下子说了这么多，如果你觉得我们的共同语言比较多，那可以加我qq或者msn。 qq是： 19805849 。 msn是： [e-mail] <br/></div><br/><p>我们公司的新人也碰到类似的问题，基本上和你说的比较接近，但是因为一些非技术的原因，使得结果不太一样。因为各种原因，比如我资历比较深，毫无保留甚至是不惜血本的培训精神，技术上和理念上的先进性（相对的），新人们对我说的话比较认同，基本认为我说的都是对的。也就是说，从一开始我就对他们详细分析前台展现的重要性，和选择EXT2.0的各种原因，使得大家对我说的都比较认同，另一方面就是EXT2.0的效果也确实吸引了不少人的强烈兴趣，当然最后能成为独当一面的前台牛人人数还是不会多的，我也只是希望，将来能做到每个项目有个前台强人就可以了。</p><p>接下来分析你提到的情况：</p><p>1.我们这里包括我自己也有类似的问题，但是我们基本会参照EXT2.0的源代码和我们事先写的最佳实践的例子来做，没有出现非常迥异的代码风格问题，这可能和我这里的执行力比较好有关。<br/>2.我之前也说过要得到公司支持的问题，这是很重要的的事，公司支持你做这个工具还不是最重要的，而是公司的制度上得要求程序员的代码规范要向你的工具生成的代码靠拢。<br/>3.控件的想法是对的，但是不要过度封装，要通过你的控件，让他们学习如何应用，像我们的原则要么不写组件，写的话一定要使用方便，注释绝对详细规范。关于DWR的争议，JavaEye上也有讨论，我们设计的就是CRUD都在一个页面内完成的，或者说从UI交互的风格设计上就是很倾向于Ajax的（但不是100%，90%左右吧），所以我认为DWR是不适合我们这种OPOA（One page one application）风格的，而且选择EXT2.0，在Ajax风格上就是选择重客户端的类型（是我选择EXT2.0的重要原因之一：不和服务段的MVC绑死非常好），DWR也好，GWT也好，虽然也没有和MVC绑在一起，但是理念上是属于服务段生成的，我是强烈反对这种形式的，要做就在客户端好好做，别再搞到服务段，这样客户端调试思路也清楚，还可以充分利用好的JS的IDE。</p><p>培训是个大问题，我个人性格的原因导致我很愿意给别人上课，我的理念是：<br/>1.教别人的同时我对这个东西的理解能更深刻（当然如果发现某些东西每次讲的都一模一样没有变化，就考虑成文了）。<br/>2.只有更多的人熟悉我的想法，认同我的理念，才能更好的推广我的框架，更好的帮我推广框架，更好的帮助别人学习框架和规范。</p><p>3.让新人感觉有很强的学习气氛，新人也会变老人，他们也会部分参照我的做法来对将来的新人。不要小看自己的个人力量和个人魅力，你是能够影响公司文化的。<br/>4.时间成本要得到上层认可，要让上层知道培训的投入是值得的，回报大于付出。</p><p>我说开源其实有点反话的味道，我知道你只用了三周离开源还是有不少距离的，只是提醒你可以从开源的角度去考虑你的工具的生命周期的问题，因为你不一定永远呆在同一个公司，后面不用我说了吧。</p><p> </p><p>我是懒人，还是你联系我吧：msn:<a href='mailto:[e-mail]'>[e-mail]</a>。</p><p> </p>

81 楼 ynstudio 2008-03-11  

我们也做了这么一个，可以参考一下，发到另外一个版里了。
http://ynstudio.iteye.com/admin/blogs/170319
http://www.iteye.com/topic/170320
这个从前到后一套生成，虽然不完善，不足够灵活，但对于项目内部确实省了我们很大的力气。

80 楼 tjlvan 2008-03-11  

我做的几个流程开发I工具基本上都是提供给用户一个UI流程编辑器，然后根据编辑器中的内容生成java代码，并且支持流程调试功能，如常规的逻辑流、页面流、工作流，
不知道对应流程的开发和调试还有没有其他的方式。

79 楼 wenbin151 2008-03-11  

支持，代码生成器，有些事情，当大家做过以后，站在另外一个角度去考虑问题时更好的。。。

78 楼 clock2008 2008-03-11  

贴几张图片上来看看

77 楼 fang9159 2008-03-11  

to jobs:
   不好意思，不是回避，是本来就用不上编译相关的技术，这个工具只是需求的产物，这是各个人的思想不同，也许你做是为了追求复杂性和难度和深度，而我做只是为了满足需求，只要能够满足需求，那么我会选择最简单的方法，但简单并不等于幼稚，
如果目前让你用j2ee来开发一个项目，你框架选择什么？ejb，还是自己做？根据我对你的留言我就了解到，你会选择ejb或者自己开发一个框架，因为你追求的是高深度，高难度， 但如果是我，我就会选择用一个目前已经很成熟的轻量级的框架，比如spring+hibernate。
   在做什么东西之前，我会在满足需求的基础上，找一条最简单的路。高的难度和复杂性只会带来大的开发成本和大的维护成本。
   当然我感觉在技术方面是真的很不错，这一点我甘拜下风，因为编译方面的技术我在工作上是很难用到的，也许我的性格本来就是那种实用性的吧。
   也感谢你对我提的建议。

76 楼 wangdawei 2008-03-10  

[e-mail]麻烦把代码发给我　共同研究一下！