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

楼主说了这么多，是骡子是马改牵出来溜溜了

to bybas:
   不好意思，我在第一天就想牵出来，但我说了我想上传图片这些上传不了，而且也给不了外网访问！！！

这个问题可以这样考虑，要有开放的精神，第一年你招了10个刚毕业的新人，能留住5-7人，第二年年底留住3-5人，第三年年底留住这些人中的2-3人，对公司的成本来说都还是合算的，不管把这些人培养成什么方向，公司方面首先要大度，不要幻想员工不跳槽，那是不现实的。我就经常和新人说的一句话，将来你去其他大公司面时会很有用的。

 

即使这些人离开公司，从成本上来考虑仍然是合算的，如果留住2-3个骨干，忠诚度和技术认可度是非常高的，绝对比招来的牛人要好得多的多，这些人的加薪程度可以大一点，太多也没用，留住人不是靠加薪能留得住的。而且离开公司的那些人也不会对公司有恶评，会吸引更多的人来公司或者一些老员工再回公司，整体上来讲还是合算的。这是观念上的问题，国外很多小企业也是这么做的。

 

人的需求有很多种的，不单单是薪水的问题，每个新人或者是工作2-3年的程序员，也不要指望他们能有多高的职业素养。我们可以站在他们的角度，想想他们需要的是什么，除了不算太差的收入以外，希望有更多的公司层面的关怀，技术上有不低的上升空间，使用的技术以后跳槽也很好找工作，有非常好的氛围（有些公司的老员工或者技术牛人对新人非常的不耐心，出于私心或者自己项目紧张，或者认为教新人技术是浪费自己时间），让自己快速提高技术能力和管理能力等等。

to icewubin:
    你好，感谢你给了我这么多的建议，非常感谢你能让我在不同角度去看待一些问题，让我的眼界开阔许多，当然我的理想也是向这方面努力。
     我先想和你讨论下前台方面的问题，我们公司也是有你说的这种情况，浪费开发人员时间恰恰就是前台这一块，他们主要在以下方面浪费时间：
1.js技术不扎实，新人一般是刚刚才接触，导致不好的代码风格而带来难维护性
2.他们不遵从界面标准，标准是有，但是他们不遵从，评审也做，但是执行效果不好，这又提到一个执行力的话题去了。
3.兴趣方面的问题，据我的了解，10个程序员大概只有2个人对前台技术感兴趣的。
这些原因造就了前台成为项目开发过程中的一个绊脚石。我呢，在这方面做了以下办法。不知道可不可以对你碰到的情况有一些帮助。当然有些办法是失败的，但我也提出来，也许开发环境和公司文化的不同，方法的效果就不同。
1.对前台技术做培训，虽然目前ext，jquery，包括锐道都是很不错的webui框架，但是也需要程序员对js，css，都有一定的基础。目前这一块没持续做下来。
2.前后台分层开发，这样做也有如下问题：(1):对设计师要求非常高，要求他们能够做比较好的任务分层和模块分层。(2):公司的资源也不够。
3.既然开发人员不遵从标准，那我们就给他生成这种标准。我们把他们感觉很烦也不想动手做的东西都生成出来（比如一些宽度，字体大小，一些验证，日期，非空，整数，一些控件的用法，combobox，datagrid等等这些用法).那么这个其实才是我做生成工具的初衷。
另外我们公司没有选择ext2.0。ext2.0的确做的不错。而且dwr与ext也是不错的结合，这些技术在公司推广还有一段时间，但目前公司的项目在启动。这中间有个时间矛盾。我们倒是开发了一些常用的webui控件，datagrid，日期控件，tree，menu，动态下拉框等等，这些也能够满足我们的需求。
    第二个和你说说培训的事情，做很多事情是要有个基础的，比如公司本身的文化，我们也是很低的成本招聘一些刚毕业的新人，也是花了心血去培养他们，他们也非常忠诚于我们，但是他们不会忠诚公司。但我个人的想法和公司的想法其实不同的，我觉得只有员工在进步，整个公司才会进步，而且公司应该考虑适当的换一下新鲜血液。
    第三个开源，我很想将这一套能够开源，但是目前不成熟，对个人也好，对公司也好，对项目也好，我都没有很多精力来维护和交流，这个我是计划这个项目能完成后，再拿出来开源。我也明白开源对我自己本身都好是会为我带来什么！而且目前这个工具和开源还是有很大距离的，因为毕竟做的不是eclipes插件。
    好的，一下子说了这么多，如果你觉得我们的共同语言比较多，那可以加我qq或者msn。 qq是： 19805849 。 msn是： fang9159@live.cn
   

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

贴几张图片上来看看

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

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

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

我们公司的新人也碰到类似的问题，基本上和你说的比较接近，但是因为一些非技术的原因，使得结果不太一样。因为各种原因，比如我资历比较深，毫无保留甚至是不惜血本的培训精神，技术上和理念上的先进性（相对的），新人们对我说的话比较认同，基本认为我说的都是对的。也就是说，从一开始我就对他们详细分析前台展现的重要性，和选择EXT2.0的各种原因，使得大家对我说的都比较认同，另一方面就是EXT2.0的效果也确实吸引了不少人的强烈兴趣，当然最后能成为独当一面的前台牛人人数还是不会多的，我也只是希望，将来能做到每个项目有个前台强人就可以了。

接下来分析你提到的情况：

1.我们这里包括我自己也有类似的问题，但是我们基本会参照EXT2.0的源代码和我们事先写的最佳实践的例子来做，没有出现非常迥异的代码风格问题，这可能和我这里的执行力比较好有关。
2.我之前也说过要得到公司支持的问题，这是很重要的的事，公司支持你做这个工具还不是最重要的，而是公司的制度上得要求程序员的代码规范要向你的工具生成的代码靠拢。
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。

培训是个大问题，我个人性格的原因导致我很愿意给别人上课，我的理念是：
1.教别人的同时我对这个东西的理解能更深刻（当然如果发现某些东西每次讲的都一模一样没有变化，就考虑成文了）。
2.只有更多的人熟悉我的想法，认同我的理念，才能更好的推广我的框架，更好的帮我推广框架，更好的帮助别人学习框架和规范。

3.让新人感觉有很强的学习气氛，新人也会变老人，他们也会部分参照我的做法来对将来的新人。不要小看自己的个人力量和个人魅力，你是能够影响公司文化的。
4.时间成本要得到上层认可，要让上层知道培训的投入是值得的，回报大于付出。

我说开源其实有点反话的味道，我知道你只用了三周离开源还是有不少距离的，只是提醒你可以从开源的角度去考虑你的工具的生命周期的问题，因为你不一定永远呆在同一个公司，后面不用我说了吧。

 

我是懒人，还是你联系我吧：msn:icewubin@hotmail.com。