关于RoR无法成为企业应用开发的主流的讨论

1、Java的风格不是一开始就是这样的，也经历了一个探索、演化、成熟、形成模式，广泛传播的过程。这是java之所以能够大面积推广、工业级强度应用的原因，也可以说是java大面积推广、工业级强度应用后的结果。

2、Web2.0，固然都是从小应用开始，能快速上手的，但是，这并不意味着，Web2.0只能都是简单的，或者说，都会始终是简单的。JavaEye 2.0目前固然还很简单，但是将来如果想加入多种扩展功能，比如Blog的模版支持，更加完善的Forum，会员的管理，数据的统计，以及将来的招聘，开源项目支持等等，一定会越来越复杂的，难道你那时候就不用ruby了？

3、ruby，相比java最大的优势，不是他用法多种多样，开发速度快，而是更加容易快速的修改，而这正式未来企业级开发，所必须的品质。这一点，buaawhl已经说得很透彻了。

4、除了语言之外，设计模式、框架、开发约定、习惯等等，都是减少开发中交流难题的办法。目前能够用到的工具，还有自动化的TestCase，这个TestCase不但可以辅助重构，我以为也可以作为多个模块之间的协作约定的“无歧义表述”。

5、Ruby过于灵活，Rails其实是过于死板了。这两者的特性不该混为一谈。

6、任何时候，小团队的交流效率，都比大团队的更高，并非Ruby语言、Rails框架的特有问题。如果Robbin认为，采用RoR开发，团队人数就不能超过3个人，那就是着相了。

目前想到的就是这些。

评论

37 楼 johnny2008 2007-03-07  

dwangel 写道

花花公子 写道

你可以试试看用ruby和java同时实现一个SOA系统，到底谁更简洁。

37signals就是用互联网的方式解决企业应用。企业应用系统弄这么复杂才能保持它的神秘感。使得人们上网写blog，写wiki很轻松，但是一提到企业应用就皱紧眉头，认为这是一个严肃的话题。

为什么一定要用SOA?
Java的一些特性比较方便地实现了SOA，而且SOA更多的考虑与其他系统地结合。
但ruby现在并没有考虑与其他系统的结合，拿这个比，是不适用的。

关心一些更重要的问题更能节省时间。YAML 和XML相比，YAML更简单些，但是同样能完成很多工作，还不用复杂的解析。

另外，企业应用系统考虑的严密性要求更高。
刚看到一个帖子的观点：强壮性检查，会导致阅读者的注意力分散。

同样地，企业应用的延伸性的要求，往往也会分散开发者的注意力和精力，
同时也会把系统弄复杂。

但是，软件应用本身变化性很强，如果是为了短时间应用，那么开发一套系统，用上很短时间，
然后丢弃，在开发的成本大大降低的条件下，完全有可能。

另外，很早我就认为软件开发是服务性行业了，软件行业的景气与否很大程度上依赖于它所服务的
具体行业。（游戏开发有点特殊，应该归到娱乐业去）

  这是否正表明国内做产品和企业应用比较少呢,大家都忙于做简单的web开发呢,这也许正是与国外差距所在的原因吧:)

36 楼 dwangel 2006-09-20  

花花公子 写道

你可以试试看用ruby和java同时实现一个SOA系统，到底谁更简洁。

37signals就是用互联网的方式解决企业应用。企业应用系统弄这么复杂才能保持它的神秘感。使得人们上网写blog，写wiki很轻松，但是一提到企业应用就皱紧眉头，认为这是一个严肃的话题。

为什么一定要用SOA?
Java的一些特性比较方便地实现了SOA，而且SOA更多的考虑与其他系统地结合。
但ruby现在并没有考虑与其他系统的结合，拿这个比，是不适用的。

关心一些更重要的问题更能节省时间。YAML 和XML相比，YAML更简单些，但是同样能完成很多工作，还不用复杂的解析。

另外，企业应用系统考虑的严密性要求更高。
刚看到一个帖子的观点：强壮性检查，会导致阅读者的注意力分散。

同样地，企业应用的延伸性的要求，往往也会分散开发者的注意力和精力，
同时也会把系统弄复杂。

但是，软件应用本身变化性很强，如果是为了短时间应用，那么开发一套系统，用上很短时间，
然后丢弃，在开发的成本大大降低的条件下，完全有可能。

另外，很早我就认为软件开发是服务性行业了，软件行业的景气与否很大程度上依赖于它所服务的
具体行业。（游戏开发有点特殊，应该归到娱乐业去）

35 楼 gigix 2006-09-19  

ddd 写道

>>（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
引用
这话一下子就让我想起那些叫兽和博士（满嘴的“理念”，也不知道自己理解没有），他们既然是搞研究就本不应该满嘴这些东西，就应该踏实一点。
言归正传，你说“复杂”时候不知道考虑没考虑歧义问题，你说的复杂是指it系统的哪个方面复杂？
还有，你表达东西本来可以很直接很朴素，不知道为什么非得用一种间接方法。比如这两点，完全没必要用反问，你自己人为增加着交流的难度，可能也是故意的吧（恶意推导一下：不能让别人真正了解自己的想法，否则别人思考方式也这样就显示不出自己了）

这些问题，我自己没有想清楚，只是有一些模糊的感觉。我也不打算要教导别人，我想做的只是让某些感兴趣的人开始思考——说得不好听，我凭什么要教导你？你交学费给我？
我说过好几次了，这些东西大家都没有想清楚，我只是抓紧时间把我想到的模糊的感觉写出来而已。我说的对你有启发则好，要是没有启发便罢，我不打算说服谁说什么，更看不出在这里装个高深对我有什么好处。

34 楼 losing_fox 2006-09-19  

如果以后中小企业成为整个社会的主流，支助的时候

gigix的说法还是有道理的

大量中小型系统的信息集成，分享，搜索才会是重点

33 楼 levinfox 2006-09-19  

花花公子 写道

你可以试试看用ruby和java同时实现一个SOA系统，到底谁更简洁。

37signals就是用互联网的方式解决企业应用。企业应用系统弄这么复杂才能保持它的神秘感。使得人们上网写blog，写wiki很轻松，但是一提到企业应用就皱紧眉头，认为这是一个严肃的话题。

企业应用的复杂性来源，从技术的角度来说是异构系统的集成，包括数据、流程和界面上的集成，需要专门的工具和方法来干这件事情，比如用到DB2 II, MQ和Portal等等，动态语言这块，别的不说，要想干这些脏活，必须有对这些庞杂工具的接口(这些工具绝大部分不是java写的)，现在好像基本上都不具备，也就是开始完善数据库的接口而已。SOA的出现可以缓解这个问题，但不是解决，也许要等到大家都用webservice那一天........
另一个复杂性来源于系统运行的稳定性，这个决定了只能采用成熟技术，关键业务肯定不会构建在目前rails这个状态的项目下。上次rails第一次发布安全升级警告的时候一票企业用户在DHH的blog造反，实际上是不成熟的表现，既然选择了rails这类处于快速成长期的项目，就要有足够的心理准备和应急措施.
其他的，就是业务上本身的复杂性和易变性，基本上一个项目坚持6个月以上，必然会出现业务的不同程度上的变化。这一点，感觉是快速开发的动态语言的用武之地。不过动态语言的代码的可维护性有没有静态的好，现在还是个问号

32 楼 levinfox 2006-09-19  

cookoo 写道

你后面分析的独立情况，我完全同意，这也是正确的教师和人的普遍关系。但是，一开始is-a的继承关系判断明显是错误的：人是种动物，教师不是种动物也不是某个物种，高一层的继承关系检验失败。教师是个职能（teach），一个role，不是人的子类。

从实践的角度来说，将教师抽象为人的子类型的一个前提是所有的教师都是人，就比如工人/农民/程序员都是人那样，如此，则从DRY的角度来说并没有必要独立于人的单独的这类角色类型序列来。接口和抽象是在需要的时候出现和细分的，因为每一层细分都带来新的复杂性.从里氏代换的角度来说，将教师作为人的子类型的时候，所有用人这个实例的地方用上教师实例，并不会产生语义上的矛盾。
另一个则是玄学的角度，人是一种动物是从生物学的角度的划分，但在建模当中，特别是在这个例子的场景下，设计者是不会从生物学角度来定义人这个接口的，而更多的倾向于社会学的角度。不过，这个是玄学问题，缺乏可讨论性。

31 楼 ddd 2006-09-18  

>>（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
引用
这话一下子就让我想起那些叫兽和博士（满嘴的“理念”，也不知道自己理解没有），他们既然是搞研究就本不应该满嘴这些东西，就应该踏实一点。
言归正传，你说“复杂”时候不知道考虑没考虑歧义问题，你说的复杂是指it系统的哪个方面复杂？
还有，你表达东西本来可以很直接很朴素，不知道为什么非得用一种间接方法。比如这两点，完全没必要用反问，你自己人为增加着交流的难度，可能也是故意的吧（恶意推导一下：不能让别人真正了解自己的想法，否则别人思考方式也这样就显示不出自己了）

30 楼 cookoo 2006-09-18  

levinfox 写道

在这个例子中，从抽象/类型的角度来说，教师应当只是人的子接口，而不应当被设计为与人并行的独立接口，这里符合is-a的关系。所以这个例子并不好
从接口表达的角度来说，如果确实需要教师和人的相互独立，比如说动物或者录音机/录像机也能够称为教师，那么，在java中本身也可以从人/动物/物体和教师两个接口派生出一个人教师/动物教师/物体教师的子接口，接口是支持多重继承的. 这样一来，对于使用者而言，如果需要是知道自己在调用的是哪一类教师，那么就传入这些个子接口类型，如果不需要，那就直接传入教师接口类型. 这是非常明确的依赖处理方式

你后面分析的独立情况，我完全同意，这也是正确的教师和人的普遍关系。但是，一开始is-a的继承关系判断明显是错误的：人是种动物，教师不是种动物也不是某个物种，高一层的继承关系检验失败。教师是个职能（teach），一个role，不是人的子类。

关于duck typing的优劣恐怕很难在短时间内有明确结论，一方面它方便了那些动态特性的实现，一方面也容易被搞得接口分散和不清晰。

29 楼 dada 2006-09-18  

花花公子 写道

你可以试试看用ruby和java同时实现一个SOA系统，到底谁更简洁。

37signals就是用互联网的方式解决企业应用。企业应用系统弄这么复杂才能保持它的神秘感。使得人们上网写blog，写wiki很轻松，但是一提到企业应用就皱紧眉头，认为这是一个严肃的话题。

原来企业应用是故意弄得复杂，让广大兄弟们可以借着他的神秘感混饭吃啊。

28 楼 gigix 2006-09-18  

fyol 写道

gigix 写道

答案很简单，不接受。DHH在RailsCon已经说得很明确了，Rails不打算迁就这些“企业级超复杂”。如果一定有这样的需求，那么就不要用Rails。
我说过很多次，Rails的兴起并不仅仅是一个语言、一个框架那么简单的事，它背后暗含着一种商业模式、企业运营模式、IT专业服务模式的变迁，所以它才受到那么多人的关注，甚至非IT的经济类媒体都来关注它。但似乎很多人仍然没有认真想想这到底是什么意思。譬如说我给你两个问题去思考：（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？

不接受就无法成为企业应用的主流，所以rails只能用来搞web2.0。

（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？
只会更复杂。
http://www.csdn.net/subject/SAP%20Netweaver/SAP%20Netweaver_index.html
并且看来会慢慢超脱于产品层面。
虽然web service可以使跨系统开发模糊语言的差别，但java在这块市场里已经获得了更深层次的支持。

另外，是不是接受业务主键更像是哲学问题，不见得所有产品都会兼容两者。
（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
rails应该是引爆了下一次革命，但在企业开发方面，这一次革命java应该更容易从中受益

第一，Rails!=Ruby。这个Martin Fowler已经说得很清楚了。
真正有趣的是，这调调听着很耳熟。五年前听到的版本是“如果Java采用虚拟机就无法成为高性能应用的主流”，结果呢？
From Ruby to Java里面另一句话很有味道：Productivity is the King。而IT最有趣的一点，就是可以眼看着生产力如何驱动历史。

27 楼 花花公子 2006-09-18  

fyol 写道

gigix 写道

答案很简单，不接受。DHH在RailsCon已经说得很明确了，Rails不打算迁就这些“企业级超复杂”。如果一定有这样的需求，那么就不要用Rails。
我说过很多次，Rails的兴起并不仅仅是一个语言、一个框架那么简单的事，它背后暗含着一种商业模式、企业运营模式、IT专业服务模式的变迁，所以它才受到那么多人的关注，甚至非IT的经济类媒体都来关注它。但似乎很多人仍然没有认真想想这到底是什么意思。譬如说我给你两个问题去思考：（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？

不接受就无法成为企业应用的主流，所以rails只能用来搞web2.0。

（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？
只会更复杂。
http://www.csdn.net/subject/SAP%20Netweaver/SAP%20Netweaver_index.html
并且看来会慢慢超脱于产品层面。
虽然web service可以使跨系统开发模糊语言的差别，但java在这块市场里已经获得了更深层次的支持。

另外，是不是接受业务主键更像是哲学问题，不见得所有产品都会兼容两者。
（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
rails应该是引爆了下一次革命，但在企业开发方面，这一次革命java应该更容易从中受益

你可以试试看用ruby和java同时实现一个SOA系统，到底谁更简洁。

37signals就是用互联网的方式解决企业应用。企业应用系统弄这么复杂才能保持它的神秘感。使得人们上网写blog，写wiki很轻松，但是一提到企业应用就皱紧眉头，认为这是一个严肃的话题。

26 楼 fyol 2006-09-18  

gigix 写道

答案很简单，不接受。DHH在RailsCon已经说得很明确了，Rails不打算迁就这些“企业级超复杂”。如果一定有这样的需求，那么就不要用Rails。
我说过很多次，Rails的兴起并不仅仅是一个语言、一个框架那么简单的事，它背后暗含着一种商业模式、企业运营模式、IT专业服务模式的变迁，所以它才受到那么多人的关注，甚至非IT的经济类媒体都来关注它。但似乎很多人仍然没有认真想想这到底是什么意思。譬如说我给你两个问题去思考：（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？

不接受就无法成为企业应用的主流，所以rails只能用来搞web2.0。


（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？
只会更复杂。
http://www.csdn.net/subject/SAP%20Netweaver/SAP%20Netweaver_index.html
并且看来会慢慢超脱于产品层面。
虽然web service可以使跨系统开发模糊语言的差别，但java在这块市场里已经获得了更深层次的支持。

另外，是不是接受业务主键更像是哲学问题，不见得所有产品都会兼容两者。
（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
rails应该是引爆了下一次革命，但在企业开发方面，这一次革命java应该更容易从中受益

25 楼 gigix 2006-09-18  

fyol 写道

我觉得没有了rails的ruby没什么价值，就像没有delphi的pascal一样（虽然一个是因为框架兴起，一个是因为IDE而兴起）。
linux上用来写角本倒是不错，我也这样想过，但普及起来有难度

ROR企业应用：
有一个问题就很难解决：跨系统的数据交换
企业开发里面很多内容都与ERP等各种管理软件的WEB扩展有关系，而这些管理系统大部分是业务主键的(如客户编码做客户表主键，员工编码做员工表主键)，ROR如何接受？

答案很简单，不接受。DHH在RailsCon已经说得很明确了，Rails不打算迁就这些“企业级超复杂”。如果一定有这样的需求，那么就不要用Rails。
我说过很多次，Rails的兴起并不仅仅是一个语言、一个框架那么简单的事，它背后暗含着一种商业模式、企业运营模式、IT专业服务模式的变迁，所以它才受到那么多人的关注，甚至非IT的经济类媒体都来关注它。但似乎很多人仍然没有认真想想这到底是什么意思。譬如说我给你两个问题去思考：（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？

引用

linux上用来写角本倒是不错

那曾经是人们使用计算机的最普遍的方式。

24 楼 fyol 2006-09-18  

我觉得没有了rails的ruby没什么价值，就像没有delphi的pascal一样（虽然一个是因为框架兴起，一个是因为IDE而兴起）。
linux上用来写角本倒是不错，我也这样想过，但普及起来有难度

ROR企业应用：
有一个问题就很难解决：跨系统的数据交换
企业开发里面很多内容都与ERP等各种管理软件的WEB扩展有关系，而这些管理系统大部分是业务主键的(如客户编码做客户表主键，员工编码做员工表主键)，ROR如何接受？

23 楼 capitain 2006-09-18  

mongrel 性能不错, 我在公司单独用他做server, 但是似乎不能如同fastcgi那样搞多个数据库链接

22 楼 Suninny 2006-09-18  

buaawhl 写道

对了，说到这个webrick。

现在Ruby自己的Ruby native Web Server有哪些？
Rails除了和apache, lighttpd, fastcgi 组合，还有那些web组合方式？

还有Mongrel啊。比Webrick的性能要好些。

21 楼 buaawhl 2006-09-18  

另外开贴，不是更要被投臭鸡蛋？
对于没有太多研究的领域，回帖比新贴还是显得低调的。

20 楼 robbin 2006-09-18  

buaawhl 同学，你要讨论这个问题还是另外开贴吧，否则我要投你臭鸡蛋了。

19 楼 buaawhl 2006-09-18  

对了，说到这个webrick。

现在Ruby自己的Ruby native Web Server有哪些？
Rails除了和apache, lighttpd, fastcgi 组合，还有那些web组合方式？

18 楼 gigix 2006-09-18  

buaawhl 写道

这个思路很简单啊。
大多数ruby都是rails用户，如果都满足于rails，rails说不做的事情，大家都不做。这语言怎么发展？
rails是ruby top killer，众望所归，DHH的理念几乎就是所有rails用户的理念。
你看，这么多人抱怨rails的问题，很少有考虑自己从头去解决的，都是打算怎么绕开，或者等待rails的下一步发展。以至于现在Ruby MVC领域一支独秀。
signal37是一个伟大的公司，一个伟大的商业传奇，但是，rails还不足以是一个伟大的技术。
ruby可以称得上是伟大的语言。

有killer当然好。只是如果这个killer的基础很脆弱的话，语言本身的基础也很脆弱。那么更多领域地发掘killers,不是更好？
我确实觉得web2.0很脆弱，我只是一个凡人，看不出来隐藏的巨大商业变革。如果看出来了，我早就飞黄腾达了。

这个，事实并非如此。我现在的情况大概一半一半，一半是写Rails有关的，另一半是Rails无关的。那些更老的linux玩家，用上Ruby以后更少依赖Rails。即便要host web content，我们也不会一上来就用Rails，很多时候都是直接webrick的。
前两周为了一个功能用不用Rails还争执起来，最后我费了很大力气才说服他们用Rails。