je专家挺多，想多请教一下

    做开发已经有些年头了，一直做的好像都是写代码的工作。平时也很少上这些论坛，这么多年从来没有在论坛上发过贴。可以这是在最初工作时养成的习惯吧，因为那时候还没有论坛。最多写代码上，碰到问题搜索一下，找到解决方案后就关掉了。
    最近发现也需要宣传一下自己，不然万一找工作，也好有个宣传的东西，就在CSDN上注册了博客。才开始关注这些论坛，以及论坛上面活跃的人。结果发现就技术而言，je上面更加适合于讨论问题。下次有些关于自己工作上碰到的问题，也可以拿到上面来探讨探讨了。
    不过要发起一个题目，确实也想不好，下次就对敢兴趣的帖子发表一下意见好了。我想只有在相互的辩论中才能真正的得到提高。
    我是一直做开发的，主要写的还是java。当然什么C#、Flex、VC、Delphi、PHP什么的，也写过一些。对于程序员来说，很多时候根据环境决定开发语言的，以及你所需要采用的技术。
    很多新的技术，也是稍微看一下。等到大家觉得都没有了问题之后，才敢使用。因为对于公司来说，项目是不允许失败的。所有不能无谓的去增加技术的风险。
    我是一只搞开发平台的研制工作，当然现在做这一块的人很多。是个公司可能都在说快速开发平台什么的。不过我做的还是挺早的，最早从2001年就开始了。所以说我们做东西很少上论坛，因为还根本没人做。我们用eclipse时，SWT才只有1.0，还挺不好用的。
    不过当初选定的技术，到现在也一直都没有什么改变，回头来看看这几年技术的变化，好像感觉自己落伍了一样。因此现在想融合一些新的思想和技术进来。
    我现在对几项技术比较赶兴趣，一个是DSL语言。我看到robbin在一篇帖子中评价普元时，觉得如果普元不是基于XML总线结构，而是有一套DSL语言，然后编辑器来生成这种语言，再加上一个管理完善的运行平台，这样才会理想。
    对于普元我不做评价，但是robbin这种思想和我们做的东西的想法非常接近，或者说我们的目标就是这样，可能技术有限某些指标方面没有达到而已。
    我这里暂时不对我的产品展开了，以后还有机会。我只谈实现这种技术会遇到的困难。
    1、首先一点DSL语言，比较难以选择。按理想来说可以选择python语言，但这样会加重使用者的学习成本。毕竟python掌握的人不多，社会还是java的人多一些，或者学校里就教过java。因此我们最后选择java语言。
    2、语言和编辑器的逆向工作很难。如果按照robbin的想法，用户可以直接编辑dsl，同时可以和编辑器配合做。但是编辑器生成的代码会把手工写的代码替换掉。这种逆向工作不好做。因此我们的做法是两者完全独立的，编辑器配置生成的代码是不能编写的，手工编写的代码可以供编辑器配置使用。
    3、调试和测试不好做。你要做调试，就要做跟踪，这是程序员的常用思路。这样的工程量就很大了，我们的思路是只有测试以及跟踪输出，没有debug。
    先说三点吧，其实还是有挺多问题需要解决的。总之，做一个这种平台很难，当你解决了一个问题之后，会发现还会有新的问题。并且你的功能也是需要不断扩展的。所以普元最初的时候，以为发现了银弹，确实最初的一些项目可能极大的提高了生产力。但是随着项目的复杂，其产品也做的越来越复杂，最终也导致了越来越难用。
    je的规矩挺多，也不知道该在什么地方发布什么贴。慢慢再摸索了。希望有人指点。

评论

26 楼 funnywiser 2009-05-15  

RednaxelaFX 写道

路过，乱入一下 =v=

funnywiser 写道

看groovy介绍的不错。不过我看其可以很好的支持java，不知道将来对C#的支持怎么样？

.NET上有前途不明的Groovy DLR。

非常感谢，我去研究一下看。

25 楼 funnywiser 2009-05-15  

zozoh 写道

funnywiser 写道

swen00 写道

我觉得很多事情讨论过多会让自己犹豫不前，LZ还是尽快制定出详细方案再来讨论，这样有意义的多。
如果自己都没主心骨，讨论过多也是浪费时间。

谢谢你的提醒，不过有时候多讨论一下，梳理一下思路也是有必要的。

我从2001年开始做了一个金融行业的开发平台，采用ejb作为构件，采用delphi来开发流程设计工具，然后直接生成java代码，应该说是一个开发工具。当然我只是管理者，不大开发。

2003年开始自己开发，是兴趣所致吧。采用POJO作为基本的组件，采用Eclipse来进行开发。开发配置器来生成业务逻辑。

做了这么多年，代码也重构了好几遍，回头看，好像也没做什么工作。感觉做的东西也不怎么样。所以想出来讨论一下。

我们先不要假设自己做不出来。我想讨论的是，究竟做出一个什么样功能的东西，才是真正实用的。然后才考虑哪些功能自己能做，那些暂时还不能做。

技术这个东西是这样的，你找不到门路的时候，可能觉得很难。那就暂时放一下。等突然有一天，你看到某个产品或者某篇文章之后，一下子顿悟了，那个功能也就自然而然做出来了。

所以先讨论一下需要实现的功能，还是需要的。

活活， 我现在正在做呢， 基于 Web 的。 我写了个替代 SSH 的东东叫 Nutz， 现在正在它的基础上构建开发界面等东东 

很高兴能认识这么多志同道合的朋友。我们可以交流交流，我想碰到的问题应该都差不多。

实话实说，我没有下载你的东西来研究，我只看你的介绍。

我觉得你这个产品首先定位是给开发人员用的，是属于一个框架。另外你抓住了java项目存在的一个问题，不够简单。SSH不是说不好，但是对于一个对他研究不是很深入的人来说，还是显得太复杂了。至少这么多的配置和文件，对于一个对其不太熟的人，会晕掉。

另外SSH采用分层的技术，本来是为了解决耦合性的问题。是为了业务逻辑可以分离出来，更利于管理。但是这种过多的分层却使得对于结构的变化，无能为力。

比如一个类的属性发生变化，或者类某个方法的参数发生变化，返回发生变化。就会涉及到接口的变化，这样基本上什么地方都要改。而过多的分层导致，改动的面非常广，最终也使得改动工作量很大。

你希望搞一个轻量级的框架，我想你提供轻量级的框架的目的，就是希望使用的时候简单，生成的代码少，并且改动的地方少。这我觉得应该是轻量级框架需要把握的。

就像我们为什么用ruby、php来实现系统，发现非常的敏捷，除了其语法简单之外，关键还是他没有那么多层次，那么多的代码。所有的东西都写在一些，当然容易修改了。

所以我想你的轻量级框架，能抓住这些才是重点。保留SSH分层这样易扩展这样的特性，有具有敏捷语言的这些特质。这是我觉得真正使用的。

不要说我对你品头论足，不当之处请见谅。

24 楼 庄表伟 2009-05-15  

98~99年的时候，我在做一个叫做Info Developer的东西，是用VB写的。也算是一个IDE吧。

生成的代码，跑在同事自己用Java写的一个脚本解释引擎上。（当时还没有JSP）

当时就感觉，最难的，就是代码的生成与解析。还有就是数据库访问的编写。（当时是模仿Foxpro的数据库设计器与查询设计器的风格）。

很多年都没有做这方面的东西了，现在想来，最难的，还是把简单的部分与复杂的部分合理的分开。

简单的东西，客户能填，能操作的，是一类。
复杂的东西，你开发工具做得再好，也是复杂的。

至于DSL，我并不看好，对于客户来说，满屏幕的字符，他就已经晕了。我更建议的是可视化的设计，或者是填表式的东西。

如果一个二次开发任务，用可视化设计 and  填表都不能解决，那么这个任务也根本不可能交给客户去完成，还是自己编程快一些。

23 楼 RednaxelaFX 2009-05-15  

路过，乱入一下 =v=

funnywiser 写道

看groovy介绍的不错。不过我看其可以很好的支持java，不知道将来对C#的支持怎么样？

.NET上有前途不明的Groovy DLR。

22 楼 zozoh 2009-05-15  

funnywiser 写道

swen00 写道

我觉得很多事情讨论过多会让自己犹豫不前，LZ还是尽快制定出详细方案再来讨论，这样有意义的多。
如果自己都没主心骨，讨论过多也是浪费时间。

谢谢你的提醒，不过有时候多讨论一下，梳理一下思路也是有必要的。

我从2001年开始做了一个金融行业的开发平台，采用ejb作为构件，采用delphi来开发流程设计工具，然后直接生成java代码，应该说是一个开发工具。当然我只是管理者，不大开发。

2003年开始自己开发，是兴趣所致吧。采用POJO作为基本的组件，采用Eclipse来进行开发。开发配置器来生成业务逻辑。

做了这么多年，代码也重构了好几遍，回头看，好像也没做什么工作。感觉做的东西也不怎么样。所以想出来讨论一下。

我们先不要假设自己做不出来。我想讨论的是，究竟做出一个什么样功能的东西，才是真正实用的。然后才考虑哪些功能自己能做，那些暂时还不能做。

技术这个东西是这样的，你找不到门路的时候，可能觉得很难。那就暂时放一下。等突然有一天，你看到某个产品或者某篇文章之后，一下子顿悟了，那个功能也就自然而然做出来了。

所以先讨论一下需要实现的功能，还是需要的。

活活， 我现在正在做呢， 基于 Web 的。 我写了个替代 SSH 的东东叫 Nutz， 现在正在它的基础上构建开发界面等东东 

21 楼 zozoh 2009-05-15  

幸存者 写道

对excel, powerpoint之类需求最大的肯定是总监，经理和主管之类的人，但是有几个经理和主管用excel和powerpoint？大部分都是秘书之类的文职人员。

因此指望业务人员用这个平台有点不现实

经理主管也用的多，不过 Read 比较多而已， 秘书文员当然是 Write 比较多了

20 楼 funnywiser 2009-05-15  

lordhong 写道

幸存者 写道

这帖怎么会有人投灌水？

真是混蛋, 偶投了15票良好对冲一下... 

谢谢捧场。je上都是技术人员，说话也率直，我喜欢。

不过我还不懂怎么投票，下次有机会慢慢摸索了。

我做技术其实都是凭兴趣在做，做这种开发工具也主要想着是自己用，而不是说拿去卖。当然中国目前还不适合培养这种市场。

不过闭门造车，我发现并不是一个好注意，je上虽然说语气都比较冲一些，但毕竟大家都只是探讨技术，无所谓。最怕有些公司的人，以为自己的产品才天下第一，带有刻意的感情色彩。

我也要把我以前做的一些东西，整理一下，慢慢拿出来探讨。不过发现当真的要拿出来的时候，总感觉有点像丑媳妇不敢见公婆一样，好像还欠缺什么，只能慢慢来了。

再做好一些，不要显得太落伍了，被大家笑话。

19 楼 lordhong 2009-05-15  

幸存者 写道

这帖怎么会有人投灌水？

真是混蛋, 偶投了15票良好对冲一下... 

18 楼 funnywiser 2009-05-15  

swen00 写道

我觉得很多事情讨论过多会让自己犹豫不前，LZ还是尽快制定出详细方案再来讨论，这样有意义的多。
如果自己都没主心骨，讨论过多也是浪费时间。

谢谢你的提醒，不过有时候多讨论一下，梳理一下思路也是有必要的。

我从2001年开始做了一个金融行业的开发平台，采用ejb作为构件，采用delphi来开发流程设计工具，然后直接生成java代码，应该说是一个开发工具。当然我只是管理者，不大开发。

2003年开始自己开发，是兴趣所致吧。采用POJO作为基本的组件，采用Eclipse来进行开发。开发配置器来生成业务逻辑。

做了这么多年，代码也重构了好几遍，回头看，好像也没做什么工作。感觉做的东西也不怎么样。所以想出来讨论一下。

我们先不要假设自己做不出来。我想讨论的是，究竟做出一个什么样功能的东西，才是真正实用的。然后才考虑哪些功能自己能做，那些暂时还不能做。

技术这个东西是这样的，你找不到门路的时候，可能觉得很难。那就暂时放一下。等突然有一天，你看到某个产品或者某篇文章之后，一下子顿悟了，那个功能也就自然而然做出来了。

所以先讨论一下需要实现的功能，还是需要的。

17 楼 swen00 2009-05-15  

我觉得很多事情讨论过多会让自己犹豫不前，LZ还是尽快制定出详细方案再来讨论，这样有意义的多。
如果自己都没主心骨，讨论过多也是浪费时间。

16 楼 funnywiser 2009-05-15  

幸存者 写道

对excel, powerpoint之类需求最大的肯定是总监，经理和主管之类的人，但是有几个经理和主管用excel和powerpoint？大部分都是秘书之类的文职人员。

因此指望业务人员用这个平台有点不现实

管理人员是不会去做任何东西的，工作都是手下的人来做的，比如一个文员或者担当。

我们的目标不是说完全交给业务人员来做，我们的目前是让业务人员可以直接参与进来。不让软件项目的开发像一个黑盒一样提供给业务人员。

而是他可以来完成一些和他相关的工作的。

当然实际工作中，可能业务人员字都懒得写，话都懒得说，这也是很多的。这就需要你的实现是其能够理解的，我们不需要它来动手，只要他告诉我们这样错了，我们改了之后问他对不对就行。

这就有个前提，你的实现他是不是能够看懂，另外就是你的改动是不是足够快。只要做到这两点，那么业务人员就完全可以参与进来，并且对业务的实现负责。

15 楼 funnywiser 2009-05-15  

rtdb 写道

funnywiser 写道

确实目前做这类问题有个矛盾，就是如果你太简单了，就很难满足各式各样的需求。但如果你的功能很强，却会使易用性得到很大的限制。最终搞得又像一门新的语言。

YES。

也考虑过研发这类平台的问题，正是基于上述原因，后来就放弃了。
现如今开发工具越来越灵活好用， 自主开发平台的日子应该越来越难过了。

面向开发人员的工具是越来越多，而且越来越好用。但是能同时面向最终用户的工具却很少，功能如果能够做到技术人员和业务人员，分工协作，能让业务人员也能参与进来。

这将会是一个新的局面。软件的需求变动问题，可维护性问题的局面会发生根本的变化。

在国内，很多人都在做这类工具的工作，不管是自己的兴趣还是公司的需要。但是个人做的话，不用考虑全，只要合用就行。就像木匠一样，凭着兴趣搞些小玩意，在自己日常的工作中提供帮助。

所以说，如果你有想法，就去实现他，当然不要想他会有多大市场，就当是自己的小玩意而已。

14 楼 幸存者 2009-05-15  

对excel, powerpoint之类需求最大的肯定是总监，经理和主管之类的人，但是有几个经理和主管用excel和powerpoint？大部分都是秘书之类的文职人员。

因此指望业务人员用这个平台有点不现实

13 楼 funnywiser 2009-05-15  

幸存者 写道

楼主这个平台究竟是打算给普通用户用还是给开发人员用？

在我看来两者都不适合，最适合的用户应该是系统管理员之类的人，既然如此，一开始就不要考虑针对不同的用户提供不同的工具，那样只会无端增加工作量。

你说的这个问题很好，这就是产品定位问题，做这类工具的定位很难。因为这类工具的用户首先是开发人员，因为项目实现是开发人员的职责范围。但是要实现好一个项目，却不是只靠开发人员才能解决的。

首先业务逻辑是掌握在业务人员手里的，你不管怎么做需求分析，哪怕让业务人员签字画押。最终等开发人员实现之后，他是说翻脸就翻脸的。因此业务逻辑的实现，最好交给业务人员，或者和业务人员一起来做。

流程是掌握在管理人员手中的，当然管理人员可能会交代一个业务人员来实施。但也是业务人员说了算的。

开发人员只是关注实现的对不对，性能好不好。

所以要为这几类人员都能提供功能。当然还是侧重业务人员多一些。因为技术实现的手段太多了，作为平台你不可能做到最好的技术实现。因此我们要做的是把和业务相关的提出来，采用简单化的方式来实现。而和性能相关的，或者和网络环境或者软件环境相关的，留给技术人员，让其用传统的编码方式来做。

12 楼 funnywiser 2009-05-15  

幸存者 写道

这帖怎么会有人投灌水？

你不说，我还真不注意。是不是我动了谁的奶酪？

看我说的帖子内容，好像对普元不是很有礼貌，但是我也没有做评价啊。

11 楼 rtdb 2009-05-15  

funnywiser 写道

确实目前做这类问题有个矛盾，就是如果你太简单了，就很难满足各式各样的需求。但如果你的功能很强，却会使易用性得到很大的限制。最终搞得又像一门新的语言。

YES。

也考虑过研发这类平台的问题，正是基于上述原因，后来就放弃了。
现如今开发工具越来越灵活好用， 自主开发平台的日子应该越来越难过了。

10 楼 幸存者 2009-05-15  

楼主这个平台究竟是打算给普通用户用还是给开发人员用？

在我看来两者都不适合，最适合的用户应该是系统管理员之类的人，既然如此，一开始就不要考虑针对不同的用户提供不同的工具，那样只会无端增加工作量。

9 楼 funnywiser 2009-05-15  

LucasLee可能你在做类似的开发配置工具的工作。

确实目前做这类问题有个矛盾，就是如果你太简单了，就很难满足各式各样的需求。但如果你的功能很强，却会使易用性得到很大的限制。最终搞得又像一门新的语言。

怎么来权衡这个东西，就要看针对不同的用户。

对于一些管理人员或者维护人员，最容易让人理解的是图形、表格和文档。因此我们可以用流程图、用表格、用中文说明来实现。这样这类人员就适合可以用这些工具来进行开发。

对于程序员，最容易理解的是结构图和代码。如果是流程，那就是流程图的表现形式最直观，如果是逻辑，那对于程序员来说，代码比文本更加容易读通。

对于这两类人，是要有不同的工具来提供的。当然这两类角色的职责也不一样。管理人员只关注业务逻辑、操作界面、数据。程序员只关注技术实现上对不对，性能是不是最优的。

所以说，除了配置器能提供实现以外，还需要提供DSL语言的编辑功能。

但是这会设计一个debug的问题。其实这个问题，就是看你能提供给程序员的手段到底有多少。

debug目前在编码方面也是值得争议的问题，很多人开始提倡不要debug。因此你可以提供给他们更加方便的测试工具。

比如单元测试、轨迹跟踪、调试输出等。通过看日志，看数据变化的轨迹，可以非常清晰的看到出现错误的地方。

这些功能比debug，可以花更少的时间来发现问题。

8 楼 幸存者 2009-05-15  

这帖怎么会有人投灌水？

7 楼 下一站，火星 2009-05-15  

用ruby ---代码生成器 + DSL
http://www.artima.com/rubycs/articles/ruby_as_dsl3.html