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的规矩挺多，也不知道该在什么地方发布什么贴。慢慢再摸索了。希望有人指点。

评论

46 楼 bonny 2010-01-15  

LucasLee 写道

要让用户去改DSL语言？这个只怕不合适。
任何语言都难以让用户去改，不是语言的问题， 而是逻辑完整性的问题。这就牵涉到必须有DEBUG等工具的配合才能达到较高的开发效率。
所以，我并不看好DSL给用户修改这样的特性。
我认为大多数时候，语言这个层面的东西不能过多的暴露给用户。这个特性只对少部分高级用户有用，不会是很重要的特性。

没错，以前我也做和楼主类似的工作，得出和你一样的结论.

45 楼 魔力猫咪 2010-01-15  

对所谓的通用开发平台，我来谈一些我的看法。我个人来说对通用开发平台持否定态度。
1.对于应用程序员来说，看不到使用这个平台对我日后的职业发展有什么好处。更有可能因为平台用多了，造成离开平台不会干活，丢失本身的编码能力。而且因为平台入门门槛比较低（很多吹嘘不会编程也可以开发MIS），造成相关开发人员薪水低下，企业也不怕这些人跳槽。跳了更好，招个新毕业的，2星期就可以干点简单的，还便宜（什么，新手干活慢？不怕，加班就是）。
2.说是开发平台，但是实际上能做的东西就是MIS、OA。开发更加复杂系统的话，那么带来的复杂度比直接编代码还麻烦。
3.运行速度慢。基本上使用平台开发的应用系统很多都是以慢为特点的。平台封装了太多的东西，造成运行效率低下。
4.平台开发速度实际上并不比RoR、Grails这些快速开发框架更快。简单模块上Ror号称10分钟一个博客。这个速度恐怕很多通用平台也无法达到。复杂业务开发上平台速度可能更低。不过平台因为其上手容易，更容易搞人海战术。
5.这些通用平台提供的技术支持有限。在文档、技术问题反馈等方面是比较差的。无法和开发语言相比。

44 楼 funnywiser 2009-05-19  

由于没有太多的时间，没有看明白大牛的文章，可能要过些时日，才能慢慢消化吸收。

根据我自己的体验，我对上面提到的一些疑问，提出自己的见解：

引用

1。平台到底是什么？

平台本身应该是一个非常功能完备的系统，除了要有专门的框架、还要有自己的工具以及管理系统。另外还有有很多的标准和规范需要遵循。

但是我们平台在实现时，却不可能做一个功能完善的平台，因此只能根据自己的实力，来实现自己觉得必要的部分功能。然后通过其他的框架等来补充平台缺失的功能。

每个平台其实有自己的重点，就目前来说，我个人认为平台应该最关注的是简单、易用。以及通过开放性，来解决平台的功能全面问题。

认真的来说，目前宣称的平台，都还不能说是完整的平台。很多时候，还是一套框架以及一些工具，还不是一个自成体系的系统。

引用

2. 平台必须要提供full stack方案吗？

我一直都是根据项目的实际需要来开发一些使得开发简便的工具，以及通过框架来进行约束和限定。老实我，还还不是很理解full stack方案的意思，因此不好说。

引用

3. 平台必须带IDE吗？有什么是普通GUI程序做不到的？

平台必须要有自己的IDE，不然就很难实现自己特色的功能。
目前来说，普通的GUI程序来做IDE时，易用性和可扩展性是比较难处理的部分。OSGI是比较好的实现结构。

引用

4. DSL在平台中的位置和价值

DSL在我的理解中，是希望采用语义更加丰富的语言来描述逻辑。更多的是将语言像本地自然语言靠拢，加强可读性。

引用

5. 平台在具体业务场景下的价值

在具体的业务场景下，真正有价值的还是包含了业务数据和逻辑的构件。应该说是非常粗粒度的复用，才是真正有价值的。

平台很多时候是相对细粒度的，平台的作用是可以加快粗粒度业务构件的可变性。

引用

6. 探讨平台功能模块的独立性及其意义

平台在我的理解中，就是将高手的经验，融合到平台中。让初级的人员，可以更加方便的复用这些经验。
让水平不高的人员，在短时间内，开发出优秀的系统。当然优秀与否要看开发平台人员的水平。

引用

7  分别探讨平台捆绑性、排他性在商业上和技术上的必要性以及价值

一个系统如果采用平台来进行开发，就势必对平台有了很大的依赖性。
这也是为什么快速开发平台，对于软件公司来说，是没有什么市场的。因为软件公司不能依赖于其他的公司。要依赖也要是 微软、IBM、Oracle、SAP这些大公司。

43 楼 funnywiser 2009-05-18  

你挺谦虚的，理解也很深入。我想讨论的目的，不是为了说服对方，而是为了说服自己。觉得自己的分析是有道理的，这样才对自己有用，才能真正达到讨论和学习的目的。

我想我们的目的，是为了明白平台到底有没有用。当然我们都看到这样的现象，做过平台的人，觉得平台是有价值的。而用平台的人（没有开发过平台，或者没有开发完平台），觉得平台是没有什么价值的。

感谢你给我介绍大牛，我先去拜读一下他们的文章，再来和你讨论吧。不然就会显得基础太差了。

42 楼 liusong1111 2009-05-18  

我们在思路上没有大的分歧，在结论上差距很大，我不想说服你什么，只是有几个疑问想提出来。

关于平台

我理解平台是在库和框架之上封装的顶级框架，附送IDE，还可能带app server，啥啥中间件一整套东西。既有顶层软件设施，也包括开发环境甚至运行环境。

引用

通用性框架是为了屏蔽真实的框架。我们目前做一个开发平台以及的框架，可能是.net，或者是java的 SSH框架。其实我们已经将这些具体的实现屏蔽了。也就是说，我们将来是可以基于新的框架重新实现的，或者说可以做到跨框架。这些功能的话，IBM和MS 是不会来做的。

通用性框架就在软件栈的顶层。要做到在java和.net间移植，还得保证二次开发的代码也具有移植性。同时，平台所要收纳的组件库也需要谨慎选择，平台向开发者开放的接口也必须能移植。这些都不是容易事。不经大脑的想：选个在jvm和clr上都成熟的语言，比如python，无论平台还是扩展代码都必须使用python，选择的库也必须两个平台都兼容。代价大了些。。。扯远了。。。

引用

ruby其实也可以说是一种快速开发平台。

这个不赞同，ruby是编程语言，在软件栈中处于最低层，是最基础的组件。这里说的平台在软件栈中处于最上层的位置。
尽量由最低层的编程语言可以搭建出整个系统，或者说整个系统运行中都必须受平台这个最上层组件的管理，但两者的位置是不同的，导致大的方向不同。
如同说jvm也是平台，跟我们现在讨论的这个“平台”也不是一回事，一个在地上，一个在天上。

引用

首先我想说的是，如果我们这个开发平台面向程序员的同时，又面向最终用户。也就是说，我们在同一个框架基础上，针对不同的用户推出不同的功能。面向最终用户的简单一些，面向程序员的功能复杂。面向最终用户的是为了解决维护时候的问题，而面向程序员的是为了解决开发时候的问题。你觉得这样有没有价值呢，另外 Visual Studio或者Eclipse会往这方面发展吗？

Visual Studio、Eclipse，如果把它们称为平台，是跟楼主和canonical的平台意义是不一样的，它们是通用型平台，ecllipse绑定了SSH才跟现在的话题更象。


关于代码生成

引用

代码生成只是一种手段，是为了让平台定义的内容，可以以最快的速度运行的一种技术手段。因为你如果解析执行的话，速度会非常的慢。
生成代码不是为了得到所生成的代码，而是为了执行所定义的配置。对用户来说，就当生成的代码是不可见的。

开发流程是这样的(？)： 程序员在平台上开发(1) -> 客户的业务人员进行使用可视化工具进行配置(2) -> 运行(3)
1、2两步如果不重复迭代，问题就简单了，否则需要仔细研究研究。

最简单的方式，写个常规应用，带配置文件，再带一个方便业务人员查看、修改配置文件的GUI程序就够了。
这里既省了平台的“通用性框架”。也省了IDE，取而代之的是专有的GUI（比如写个swing程序）。


你说的没错，代码生成只是一种手段。只是为了让配置文件生效。我认为，不论生成代码，还是解析执行，都完全没必要把这部分功能放到“通用性框架”里，把它做成一个独立的程序库就行了。最简单的实现方式，就是GUI存盘的时候，按模板批量生成java文件，调javac编译，打成jar丢到工程里。同时它依赖另外一个库，这个库定义了它的实现接口以及加载方式（比如通过反射加Interface执行）。工程启动时，加载这两个库。我见有的工作流引擎就是这么干的。我估计通过osgi、classloader上做手脚，运行期间也能达到同样效果。“配置即代码”的效果

关于IDE和DSL

引用

DSL是为了增加业务逻辑实现的可读性，比如读别的实现，或者管理人员、业务人员也能阅读。

既然业务人员使用平台的IDE(或我说的gui)进行配置，那么这个界面就可以做到足够人性化，比如表格、流程图、关系图，根本没必要让他看到DSL。而DSL的本质，是用文本描述业务，不论这段文本是一段可以执行的代码，还是自己创立的语法规则，都不如在GUI界面上看起来直观，操作起来简单。如果是internal DSL（用编程语言表达的DSL），相比GUI有个优势是可以让开发者利用编程语言的灵活性书写复杂的逻辑，但你又说是只读的。最终DSL在什么位置？什么时候以什么方式展现给什么人？允许哪些操作？有什么意义？我看不到。

关于平台封闭性障碍和讨论中业务场景的需要

引用

写开发平台当前一般有三个目的：
1、提高产品的技术含量。在销售过程中，更有竞争力。
2、可以减低对项目实施人员的技术要求。
3、加快项目的实施进度。

既然要做平台，让使用者绑定顶层的“通用性框架”、IDE，开发者再想扩展，就只能在有限的空间里进行了。
平台位于软件栈的顶端，既是平台控制力的体现，也是约束的象征。就像天上给遮个保护伞，既感到安全，又不能逃出它的阴影。
如果面向通用领域，这种从上到下一体化的软件布局既不容易招人待见，也不是小公司做得来的。程序库可以随意接入到其它产品中（调用就行），平台，这个一体化的大东西，怎么与其它系统整合，尤其需要部分整合或子功能使用呢？
功能模块分离（解耦）是技术方向，功能捆绑只是商业策略，平台是将功能捆绑销售的光明正大的理由。如果平台内部模块也没有道理的耦合那可就麻烦了。

平台整体走的是一体化、封闭化路线。

所以，这个约束，必须有足够的好处才能交换。比如在业务支撑上做文章，在概念一致性上做文章，在开发模式上做文章，还有canonical说的。
如果没有特征性的业务场景，没有除了平台就不可能有其它途径做好同一件事的理由，就只能泛泛而谈，最终大家谈论的话题变成了：对业务普适，对技术约束。如果我把springside定制一下，绑个IDE(springside连工程文件都生成好了),写个简单的配置插件，好象也算个平台了呢？

庄表伟老大和canonical老大的发言，都提到一点，是怎么定位出平台里哪部分是内置的，哪部分是扩展的，哪部分是对外开放的接口，哪部分是允许用户直接配置的。这个看起来容易（如果目标足够明确且简单就真的容易），不过，需求变更常常是不可预期的。面对这种不可预期，平台作为一块板子，就要经常在上面敲敲凿凿，而对程序库而言则更象往一块泥球上刷一层新泥。糟糕的平台比糟糕的程序库更容易将这种不可预期性放大化、扩散出去。

没有足够的业务背景，看不到充分的理由和价值。

总结一下，我的疑问：
1。平台到底是什么？
2. 平台必须要提供full stack方案吗？
3. 平台必须带IDE吗？有什么是普通GUI程序做不到的？
4. DSL在平台中的位置和价值
5. 平台在具体业务场景下的价值
6. 探讨平台功能模块的独立性及其意义
7  分别探讨平台捆绑性、排他性在商业上和技术上的必要性以及价值


记得canonical很久之前就做过平台，是这里的大牛，楼主也是资深人士，我主要是长期以前有这样的疑惑，今天借着这个机会发了出来，下一阶段主要是坐下来学习了。

41 楼 canonical 2009-05-17  

从我们研发平台的经验看，平台对生产力的提升主要在于催生新的软件结构方式，新的思考问题的方法，新的技术手段，而不是在现有技术框架上的一种代码的封装。

微内核+插件不是问题的核心，所谓的插件如何能以任意的方式与主框架的代码结合才重要。

代码的生成与解析只是一种技术性的困难，但是解决了代码生成和解析问题，仍然需要面对整体代码结构的控制问题。

40 楼 funnywiser 2009-05-17  

你写了很多内容，我们一点一点探讨。

liusong1111 写道

我对通用的快速开发平台不感冒，如同我对ruby的active_scaffold不感冒一样。
可视化流程可能是个亮点，拥有IDE的平台可以充分利用IDE的可视化优势。这方面还有潜力可挖，但还没看到突破。
有业务背景的快速开发平台还有点意义，通过配置定制，生成同一领域的多个产品。我把它当作更粗粒度的框架，或者称业务框架。

如果你觉得有业务背景的快速开发平台是有价值的，说明你觉得采用更加简便的方式来实现系统这种方式还是认可的。但是你可能觉得，有业务背景的快速开发平台其面向的对象更多的最终用户，提供这个开发平台的功能，相当于为自己的软件增加了一个功能。

而通用的快速开发平台，其面向的是程序员。但是程序员由于日常采用的开发工具已经非常的强大，或者说也已经很易用了。你不管做的怎样，总不可能有实力比Visual Studio或者Eclipse还要强吧。

另外你可能觉得业务框架，作为自己的企业可以提炼出来。但是通用性的框架，如果能做的话，那么IBM、MS早就做了。也轮不到我们来做的，总不能说我们比IBM还强吧。

但是我要说的是，不同的立场是会带来不同的结果的。首先我想说的是，如果我们这个开发平台面向程序员的同时，又面向最终用户。也就是说，我们在同一个框架基础上，针对不同的用户推出不同的功能。面向最终用户的简单一些，面向程序员的功能复杂。面向最终用户的是为了解决维护时候的问题，而面向程序员的是为了解决开发时候的问题。你觉得这样有没有价值呢，另外Visual Studio或者Eclipse会往这方面发展吗？

通用性框架是为了屏蔽真实的框架。我们目前做一个开发平台以及的框架，可能是.net，或者是java的 SSH框架。其实我们已经将这些具体的实现屏蔽了。也就是说，我们将来是可以基于新的框架重新实现的，或者说可以做到跨框架。这些功能的话，IBM和MS是不会来做的。

liusong1111 写道

说说我对框架和函数库的理解。如果把软件比喻成一块完整的板子，框架就是挖了很多窟窿的石灰板，需要我们拌泥巴（写代码）填这些窟窿。
函数库就是一个个大大小小的泥球，我们可以把它们直接填到窟窿里，也可以和泥巴掺起来填窟窿。甚至填进去的是我们用自己的泥巴弄的小泥板，上面留了些小窟窿。。。

板子是死的，窟窿是活的，从灵活性看，函数库 > 框架 > 平台。

你说的有道理的，平台的适用面是有限的。

liusong1111 写道

以前ruby讨论中，提到过java编程语言不足，只能用函数库来顶的现象。平台和框架的插件机制，是“微内核”的思想，即提炼出核心功能，将外围功能“函数库化”。插件的概念，不限于表现层。
如果这些东西不包含业务，长期看，平台的部分功能向框架转移，框架部分功能向函数库转移，函数库部分功能向编程语言转移。
类比以前有些是石灰的，现在要打掉变成泥板，一些泥板要变成泥球，一些泥球变成最基本的砂石。一方面，某些共性内容成为更低一层的设施，利于知识积淀和共享;另一方面，打破不合理的约束，让更多竞争者进入。这是软件向更高抽像度发展的趋势决定的。
(我以前发贴说过类似的观点)

ruby其实也可以说是一种快速开发平台。只是他应该为了能解决所有的问题，所以最后是一门语言。他用更加简洁的语法，来对应面向对象语言的实现。普通的快速开发平台是采用XML作为语言，并且通过开发工具对这个XML的实现做更多的限定。
这就是软件向更高抽像度发展的趋势决定的，只是两者适用面不一致，所以复杂程度也不一致。这就是普通的开发平台可以以更加简便的操作界面来实现的原因。

liusong1111 写道

写函数库、写框架在国内不好赚钱，写平台就显得大气，有技术含量，还能绑住客户，最重要的是能赚到钱。两个方向：
1. 努力做特别好的技术方案，采用开放的标准，可被直接替换成别的方案，不要绑定，平台只当成销售用的标签
2. 做业务平台，学SAP。

写开发平台当前一般有三个目的：
1、提高产品的技术含量。在销售过程中，更有竞争力。
2、可以减低对项目实施人员的技术要求。
3、加快项目的实施进度。

liusong1111 写道

代码生成是万恶的：不能逆向工作，一锤子买卖，每次覆盖。这个固有问题决定了它在工业化的开发流程中只能当个可有可无的小角色。
利用编程语言、函数库提供的能力，依照对问题域的理解，进行抽象封装，把精力重点放在这个方向更好。因为做好这些，就算合理使用代码生成，也能让生成的那一次代码更可读更可维护。
代码生成对于ruby这类编程语言来说没必要，这里还有编程语言能力强不强的问题。

代码生成只是一种手段，是为了让平台定义的内容，可以以最快的速度运行的一种技术手段。因为你如果解析执行的话，速度会非常的慢。
生成代码不是为了得到所生成的代码，而是为了执行所定义的配置。对用户来说，就当生成的代码是不可见的。

liusong1111 写道

如果把流程图、表格和文档当成配置的输入，那就更明朗了。比方用户用word文档写了一段需求，传到服务器，服务器把它存起来，同时解析出用户意图，生成只读的jar。下一次用户想改，就把这个word文档再展现给他。这时候，word文档就是一个DSL。ruby的cucumber不是干这个的，它是写测试用例的DSL，但都属于external DSL，有可比性。

流程图是可以作为快速开发的表现形式的，这个看现在工作流的实现就知道。表格是可以通过约定的结构，也是可以做到的，特别是决策表类表格，或者参数类表格。文档是需要约定语法的，一个文档加上一个DSL语言与程序语言的对照是可以做到作为输入方式的。开发平台要做的事情是，怎么让用户按照约定来用这些格式实现业务逻辑。

liusong1111 写道

DSL(Domain Specific Language)，含Domain，让领域人员用？含Language，让开发者用？
楼主没拿出例子，只能跟着空想了。
我们不管是开发者还是业务人员，不管是internal还是external DSL，之所以用DSL，因为它能帮助人们用接近人类语言的方式表达问题域，是用来方便让人写，让人读，让人改的。如果用代码生成DSL，还不允许人改，那其实这里的DSL是面向机器的，有背常理。

DSL是为了增加业务逻辑实现的可读性，比如读别的实现，或者管理人员、业务人员也能阅读。

liusong1111 写道

如果用internal DSL，显然java没那么“高档”，还是在设计api上多下些功夫实际。

我没有快速开发平台的任何经验，说话粗鲁，见谅

我也在学习和研究当中，并不是权威。大家探讨吗，有不同意见会好些！

39 楼 liusong1111 2009-05-17  

我对通用的快速开发平台不感冒，如同我对ruby的active_scaffold不感冒一样。
可视化流程可能是个亮点，拥有IDE的平台可以充分利用IDE的可视化优势。这方面还有潜力可挖，但还没看到突破。
有业务背景的快速开发平台还有点意义，通过配置定制，生成同一领域的多个产品。我把它当作更粗粒度的框架，或者称业务框架。

说说我对框架和函数库的理解。如果把软件比喻成一块完整的板子，框架就是挖了很多窟窿的石灰板，需要我们拌泥巴（写代码）填这些窟窿。
函数库就是一个个大大小小的泥球，我们可以把它们直接填到窟窿里，也可以和泥巴掺起来填窟窿。甚至填进去的是我们用自己的泥巴弄的小泥板，上面留了些小窟窿。。。

板子是死的，窟窿是活的，从灵活性看，函数库 > 框架 > 平台。
以前ruby讨论中，提到过java编程语言不足，只能用函数库来顶的现象。平台和框架的插件机制，是“微内核”的思想，即提炼出核心功能，将外围功能“函数库化”。插件的概念，不限于表现层。
如果这些东西不包含业务，长期看，平台的部分功能向框架转移，框架部分功能向函数库转移，函数库部分功能向编程语言转移。
类比以前有些是石灰的，现在要打掉变成泥板，一些泥板要变成泥球，一些泥球变成最基本的砂石。一方面，某些共性内容成为更低一层的设施，利于知识积淀和共享;另一方面，打破不合理的约束，让更多竞争者进入。这是软件向更高抽像度发展的趋势决定的。
(我以前发贴说过类似的观点)

业务多样性（不确定性、开放性）与平台约束（确定性、封闭性）会有冲突。

提到平台，总让我想起ejb的早期版本，它给我的印象是：把没有必然联系的东西非要纠扯到一块，不搞个app server你就没法玩，改行代码都得重新打包布署，说实在的我一直怀疑是这些公司的阴谋，不就想让用户买你捆绑了好多零件的app server吗？把开发者折腾惨了。现在终于轻生点了，本来嘛，如果我只需要ORM工具，干嘛还要买个app server，一点关系都没有啊。

写函数库、写框架在国内不好赚钱，写平台就显得大气，有技术含量，还能绑住客户，最重要的是能赚到钱。两个方向：
1. 努力做特别好的技术方案，采用开放的标准，可被直接替换成别的方案，不要绑定，平台只当成销售用的标签
2. 做业务平台，学SAP。


楼主说

引用

    2、语言和编辑器的逆向工作很难。如果按照robbin的想法，用户可以直接编辑dsl，同时可以和编辑器配合做。但是编辑器生成的代码会把手工写的代码替换掉。这种逆向工作不好做。因此我们的做法是两者完全独立的，编辑器配置生成的代码是不能编写的，手工编写的代码可以供编辑器配置使用。

引用

因此我们要将这些简单的工作，从一开始就不是基于代码，而是基于开发平台配置的。那样将来修改的时候，也就不用去改动代码，仍然是改动配置，这样才能真正的做到敏捷性。

引用

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

代码生成是万恶的：不能逆向工作，一锤子买卖，每次覆盖。这个固有问题决定了它在工业化的开发流程中只能当个可有可无的小角色。
利用编程语言、函数库提供的能力，依照对问题域的理解，进行抽象封装，把精力重点放在这个方向更好。因为做好这些，就算合理使用代码生成，也能让生成的那一次代码更可读更可维护。
代码生成对于ruby这类编程语言来说没必要，这里还有编程语言能力强不强的问题。

如果能够确定要生成的文件哪些是不允许开发者修改的，就可以用ant把源码生成到临时目录，同时编译成jar，让开发者直接拿着jar用就行了。如果想看源码，就把源码也打到jar里。后面想重新配置的话，重新生成就是了，反正开发者不会修改jar的内容。IDE的方法提示、编译期检查也没丢；把IDE的lib和source目录指向过去，调试跟踪就没问题了。

开发者利用继承和组合的方式对它们进行扩展。前提是设计搞的好。

如果把配置存到xml里，通过解析xml生成代码、在IDE显示，就会解决逆向工作问题。允许开发者修改生成的java文件会怎样：解析java文件，还原成编辑器理解的模型？如果开发者添了大量代码，甚至改成了一个编译正确、逻辑也正确但就是不能匹配-还原出配置模型呢？

如果把流程图、表格和文档当成配置的输入，那就更明朗了。比方用户用word文档写了一段需求，传到服务器，服务器把它存起来，同时解析出用户意图，生成只读的jar。下一次用户想改，就把这个word文档再展现给他。这时候，word文档就是一个DSL。ruby的cucumber不是干这个的，它是写测试用例的DSL，但都属于external DSL，有可比性。

DSL(Domain Specific Language)，含Domain，让领域人员用？含Language，让开发者用？
楼主没拿出例子，只能跟着空想了。
我们不管是开发者还是业务人员，不管是internal还是external DSL，之所以用DSL，因为它能帮助人们用接近人类语言的方式表达问题域，是用来方便让人写，让人读，让人改的。如果用代码生成DSL，还不允许人改，那其实这里的DSL是面向机器的，有背常理。

如果用internal DSL，显然java没那么“高档”，还是在设计api上多下些功夫实际。

我没有快速开发平台的任何经验，说话粗鲁，见谅

--
投个良好，防止沉了

38 楼 bcccs 2009-05-17  

funnywiser 写道

weakfi 写道

在不该发帖的地方发帖，版主一般会帮我们放到合适的位置吧。除非是人身攻击才会被删掉。

谢谢指点，后来又发了贴，就被马上移了地方了，还好没有删掉。

现在csdn推出的cto俱乐部，还是有一定影响力的。我们也看到了好多人，当然现在还是软件公司以及互联网公司的cto为主。

je如果真的想竞争，对一些高技术人人员，还是要有捷径，也不能一味的去和一些有些知名度的人唱反调。当然该评论的还是得评论，不过不能只有一种声音。

任何事情都有两面的，每个人、每个产品、每个观点就看你从哪方面看。不能只有一种声音，也不能只有一种论断。

迎合吧，迎合迎合，就把婊子这个职业进行到底了。

37 楼 funnywiser 2009-05-17  

weakfi 写道

在不该发帖的地方发帖，版主一般会帮我们放到合适的位置吧。除非是人身攻击才会被删掉。

谢谢指点，后来又发了贴，就被马上移了地方了，还好没有删掉。

现在csdn推出的cto俱乐部，还是有一定影响力的。我们也看到了好多人，当然现在还是软件公司以及互联网公司的cto为主。

je如果真的想竞争，对一些高技术人人员，还是要有捷径，也不能一味的去和一些有些知名度的人唱反调。当然该评论的还是得评论，不过不能只有一种声音。

任何事情都有两面的，每个人、每个产品、每个观点就看你从哪方面看。不能只有一种声音，也不能只有一种论断。

36 楼 funnywiser 2009-05-17  

JavaInActoin 写道

对于单据管理、数据交换、流程、报表这些应用场合应该不需要DSL，做成图形化的设计器比较好，DSL比较适合用于定义业务逻辑。

这样的平台很抽象，很通用，很难做，和应用级开发不是一个级别，如果做不到最起码在国内是前几位，是没有前途的。

不同的应用和需求，确实其侧重会不一样。有些侧重界面的配置，有些侧重流程的配置，有些侧重逻辑的配置，有些只要数据结构配置一下就行了。

因此不是一种表现形式能满足所有的需求。但是像你说的DSL比较适于定义业务逻辑，那我们就去解决业务逻辑的定义问题。而不是说要去拿他解决所有问题。

平台有没有价值和有没有市场，其实不是等同的。市场需要培育的，很多时候不是一家公司所能解决的。一般情况下，我们只做觉得有价值的，然后再把产品改造成一个成熟市场产品的替代者，去参与竞争。这是产品推广的思路。

不过对于技术人员来说，能坚持自己，并且持之以恒的做一件自己觉得需要的产品，很多时候也不能太功利性的去考虑到底有没有市场。

看那些开源软件，真正做好的，当初都是根据兴趣再走。因为市场都已经有了领导者，至于后来为什么推广开来，有些时候是他自己都没有想到的。当让更多的开源还是在默默无闻。

一个产品只要你用心，不管你有没有时间，有没有其他人的帮助。你总能做好你自己都觉得满意的地方。如果到时再拿出来和大家分享，其实是一件非常快乐的事情。在自己衣食无忧的情况下。

35 楼 weakfi 2009-05-17  

在不该发帖的地方发帖，版主一般会帮我们放到合适的位置吧。除非是人身攻击才会被删掉。

34 楼 JavaInActoin 2009-05-16  

对于单据管理、数据交换、流程、报表这些应用场合应该不需要DSL，做成图形化的设计器比较好，DSL比较适合用于定义业务逻辑。

这样的平台很抽象，很通用，很难做，和应用级开发不是一个级别，如果做不到最起码在国内是前几位，是没有前途的。

33 楼 eclipse2008 2009-05-16  

用户比较喜欢saas，因为只要花钱就可以了，其他啥也不用做。

32 楼 seraphim871211 2009-05-16  

rtdb 写道

funnywiser 写道

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

YES。

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

同感，其实LZ说的和MDA的终极目标类似，我觉得做这种东西是没多大意义，机器很难理解人类语言，难度太大，只能简化，难以替代。LZ做出来估计唯一的好处就是简化部分开发，还不如创造一门新的语言，比如ruby？

31 楼 funnywiser 2009-05-15  

lobbychmd 写道

funnywiser 写道

lobbychmd 写道

你可以把框架抽象一下形成几种模式, 例如 rails 的MVC, 你必须按它的规则, 它的结构写代码, 这个结构就类似填表的东西.

但它模式归纳的好,虽然为规则所限, 也能实现所有的需求.

至于这个: funnywiser 写道

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

不妨考虑一个插件的模式, 例如你有很丰富的插件实现界面, 就可以用配置生成

  grid :dataset => dataset 就可以生成表格

如果有满足不了的界面需求, 就必须开发新的插件

这样就把开发的层次给划分了, 有配置式的, 有二次开发性质的, 最终的目的是以最简化的配置实现通用需求,  但也能够优雅的扩展,实现未知需求

你说的这种rails的MVC模式是基于编码方式来说的，对于一个快速开发的工具来说，对于大部分需求是不鼓励编码的。只有少部分复杂的需求，采用编码的方式来解决。然后才通过约定的接口来融合。因此我觉得你提的采用插件的方式来实现，复杂的编码实现和简单的配置实现融合是一个很好的想法。

但你知道，现在软件都是分前端和后端的。前端Ajax、后端java，这两种的实现特点是完全不一样的。前端侧重展现，后端侧重逻辑和存储。

因此你的说的这个插件模式，可能主要适合于前端展现。就是制作一些公共组件，然后通过标记等形式来实现插入。

不知道我理解的是否正确。其实我觉得我们可以探讨一下，在当前我们见过的工具中，什么工具，其前端的灵活配置做的是最好的。还有那些不足。这样可能更具体些。

代码和配置有时候没有明白的一条界线.
XML 从名字它还是一门语言呢,  虽然一般作为配置
假设代码足够符合规则, 很容易由表格式的配置生成, 也可以看作配置

而如果配置里面可以用正则表达式,你说它是不是代码?

你说的挺有道理，你从这些表面看的话，看不出编码和配置的区别。可能我们本身描述上就有些问题。

我要说的是区分开发阶段的代码以及维护阶段的配置。

举个例子，如果这个工作是需要在开发阶段做的。那么就是代码。如果是在维护阶段做的，而且作为提供给最终客户的一个功能，那么我把它成为配置。暂且不管这种称谓是否正确。

比如我们给用户提供了一个参数表，用户可以配。那就是配置。如果我们写在一个属性文件中，那就是编码。但如果这个属性文件，直接允许用户改。那就又叫他配置。

好像太学究了。我要说的是，这两种方式，关注点是不一样的。

我是想简单的实现，将来是可以直接提供给用户的。也就说就想现在流行的SAAS这种模式一样，用户是可以增加修改功能。当然功能上会有些限制。直接给客户提供的东西，就是简单易用，只有设置，以及一些公式。因此不考虑MVC等问题，或者在他眼里但不到这些东西。只给他提供几个东西让他设置。

当然我们肯定在底层使用MVC来实现的，只是对他不可见的。

对于复杂的方式，就需要编码以附之，这就需要有一个扩展性很好的结构，或者就像Ruby这种约定的架构来实现。或者采用插件形式。这些都可以探讨。

不过我倾向于，用插件这种方式。就是要考虑插在哪里，我想还是前端界面展现合适些。

30 楼 lobbychmd 2009-05-15  

funnywiser 写道

lobbychmd 写道

你可以把框架抽象一下形成几种模式, 例如 rails 的MVC, 你必须按它的规则, 它的结构写代码, 这个结构就类似填表的东西.

但它模式归纳的好,虽然为规则所限, 也能实现所有的需求.

至于这个: funnywiser 写道

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

不妨考虑一个插件的模式, 例如你有很丰富的插件实现界面, 就可以用配置生成

  grid :dataset => dataset 就可以生成表格

如果有满足不了的界面需求, 就必须开发新的插件

这样就把开发的层次给划分了, 有配置式的, 有二次开发性质的, 最终的目的是以最简化的配置实现通用需求,  但也能够优雅的扩展,实现未知需求

你说的这种rails的MVC模式是基于编码方式来说的，对于一个快速开发的工具来说，对于大部分需求是不鼓励编码的。只有少部分复杂的需求，采用编码的方式来解决。然后才通过约定的接口来融合。因此我觉得你提的采用插件的方式来实现，复杂的编码实现和简单的配置实现融合是一个很好的想法。

但你知道，现在软件都是分前端和后端的。前端Ajax、后端java，这两种的实现特点是完全不一样的。前端侧重展现，后端侧重逻辑和存储。

因此你的说的这个插件模式，可能主要适合于前端展现。就是制作一些公共组件，然后通过标记等形式来实现插入。

不知道我理解的是否正确。其实我觉得我们可以探讨一下，在当前我们见过的工具中，什么工具，其前端的灵活配置做的是最好的。还有那些不足。这样可能更具体些。

代码和配置有时候没有明白的一条界线.
XML 从名字它还是一门语言呢,  虽然一般作为配置
假设代码足够符合规则, 很容易由表格式的配置生成, 也可以看作配置

而如果配置里面可以用正则表达式,你说它是不是代码?

29 楼 funnywiser 2009-05-15  

lobbychmd 写道

你可以把框架抽象一下形成几种模式, 例如 rails 的MVC, 你必须按它的规则, 它的结构写代码, 这个结构就类似填表的东西.

但它模式归纳的好,虽然为规则所限, 也能实现所有的需求.

至于这个: funnywiser 写道

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

不妨考虑一个插件的模式, 例如你有很丰富的插件实现界面, 就可以用配置生成

  grid :dataset => dataset 就可以生成表格

如果有满足不了的界面需求, 就必须开发新的插件

这样就把开发的层次给划分了, 有配置式的, 有二次开发性质的, 最终的目的是以最简化的配置实现通用需求,  但也能够优雅的扩展,实现未知需求

你说的这种rails的MVC模式是基于编码方式来说的，对于一个快速开发的工具来说，对于大部分需求是不鼓励编码的。只有少部分复杂的需求，采用编码的方式来解决。然后才通过约定的接口来融合。因此我觉得你提的采用插件的方式来实现，复杂的编码实现和简单的配置实现融合是一个很好的想法。

但你知道，现在软件都是分前端和后端的。前端Ajax、后端java，这两种的实现特点是完全不一样的。前端侧重展现，后端侧重逻辑和存储。

因此你的说的这个插件模式，可能主要适合于前端展现。就是制作一些公共组件，然后通过标记等形式来实现插入。

不知道我理解的是否正确。其实我觉得我们可以探讨一下，在当前我们见过的工具中，什么工具，其前端的灵活配置做的是最好的。还有那些不足。这样可能更具体些。

28 楼 funnywiser 2009-05-15  

庄表伟 写道

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

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

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

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

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

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

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

98年就开始做了，高手啊。

不过当时做的时候，还有很多限制。比如那是java还不够完善，另外能够参考和学习的东西也太少。而现在却好很多，有很多的开源代码可以参考，有很多的成品也可以参考，还有就是碰到问题直接可以google到。书籍也很多。

制作开发平台是我们这些开发人员的兴趣所在，我想每个追求技术的人，都会去做一些小工具，来提高自己的工作效率。这些工具如果能做的全面，融合在一起，就是一套软件工具了。我很喜欢这些工作，当然现实的环境，可能造成我们没有那么顺利。工作压力，生活压力、以及对社会的无奈等等，会使我们没有时间，也会让我们对很多东西失去兴趣，也就失去了激情。因此我们也就没有精力去做自己喜欢的事情了。

你说的将简单和复杂的分开，我觉得你说到了做这类产品的重点。就是说这类产品本来就是想把问题简单化，简便化。但是有些需求的复杂，却造成你简单的实现很难去满足。

这就会产生一个矛盾，是增强本身工具的功能来满足这些功能，还是通过其他的方式来解决。

我还是倾向于后一种，就工具来说，我就只能做这些简单的工作，并且这些简单工作我是可以做到最好的。其他复杂的，就做这种接口等来进行融合了。

说这么多，让人会感觉在纸上谈兵。现在确实是在纸上谈兵，要具体的话，就只能就某个点的实现展开才行。

27 楼 lobbychmd 2009-05-15  

你可以把框架抽象一下形成几种模式, 例如 rails 的MVC, 你必须按它的规则, 它的结构写代码, 这个结构就类似填表的东西.

但它模式归纳的好,虽然为规则所限, 也能实现所有的需求.

至于这个: funnywiser 写道

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

不妨考虑一个插件的模式, 例如你有很丰富的插件实现界面, 就可以用配置生成

  grid :dataset => dataset 就可以生成表格

如果有满足不了的界面需求, 就必须开发新的插件

这样就把开发的层次给划分了, 有配置式的, 有二次开发性质的, 最终的目的是以最简化的配置实现通用需求,  但也能够优雅的扩展,实现未知需求