ruby on rails为什么暂时无法成为企业应用开发的主流？

今天上午和庄表伟在msn上交流了一些看法，下午和JavaEye2.0的主力开发人员jerry讨论了关于ruby on rails在企业应用开发和团队协作的问题。通过讨论，有了一些初步的想法和观点，虽然还不是很清晰，但是现在总结和记录下来，留待今后的实践来验证。

ozzzzzz在Java将死？中提出了一个衡量未来主流工业语言的标准，其中有一条很有意思：

ozzzzzz 写道

1. 应该能规范书写，而不是像c那样可以造就多种不同的风格。

Java明显是一个编程风格非常容易统一起来的语言，而ruby则很明显是一个难以统一编程风格的语言。JavaEye论坛里面有人曾经说过：

引用

Java语言，高手和低手写出来的代码都差不多，而ruby则不同，高手和低手的代码，高下立判

Java编程语言的语法非常简单，规范比较严密，这样规范化带来的好处就是，一旦程序员具有比较良好的面向对象编程基础和设计模式的掌握，那么编写出来的代码几乎是大同小异的。

为什么优秀的Java开源框架的源代码我们读起来都比较容易呢？为什么Java那么容易写出来无二义性，相似度那么高的代码风格呢？为什么用Java做同样一件事情，往往只有一种最优的写法呢？为什么Java很难搞出来奇技淫巧呢？为什么Java语言一直被人认为是大巧若拙呢？我们再想想，为什么JDK5.0引入的技巧颇高的泛型编程到现在也有三年，为什么还是没有被广泛采用？再想想Java语言被设计出来是用在什么场合的呢？

想清楚这些问题，那么我们就会发现Java成为企业应用开发主流的一个内在原因(外因也很多，这里不谈)，因为Java语言足够死板！

所以写Java程序没有什么花巧，所以为了弄出来点花巧，逼的Java社区搞出来动态反射，搞出来AOP，抄袭了泛型，其目的都是增加Java语言的灵活性。

那么Java这种死板而简单的语言有什么好处呢？好处就是适合作为工业语言！

那么我们分析一下工业语言在语法上面有着什么样的要求呢？

1、语法足够简单而且强壮
2、语法足够死板、做同样的事情，只有一种最优解
3、足够的语法障碍，抑制你的随意发挥，给我规规矩矩的编码

工业语言为什么有这种内在的要求呢？

1、团队协作的需要
大规模的项目需要几十人以上的协作，甚至是异地协作。这种大规模的团队协作要求程序员的代码风格必须高度一致，并且代码块之间的依赖性降到最低。显然死板而容易解藕的Java非常的合格

2、批量生产的需要
现在的软件外包产业体现的尤为明显！不需要你的创意，不需要你的设计，就需要你的coding，而且coding风格，功能已经规定死了。Java显然又非常合适。


好了，上面分析了从语法特点角度，为什么Java成为了工业语言，那么再分析一下为什么ruby不能成为工业语言：

1、ruby的语法过于灵活，发挥的余地太大，导致每个人的代码风格迥异

我刚开始学习ruby的时候非常不适应，被ruby五花八门的语法糖衣搞晕了，同样的一件事情，你有无数种做法，笨拙的，普通的，聪明的，天才的，各式各样，甚至有本《ruby quiz》的书专门讲解ruby编程的各种奇技淫巧。ruby这种内在语法特性直接造就了ruby on rails奇迹。在ruby on rails框架里面，有无数的ruby magic，好用之极又让你惊喜万分，没有ruby这么多灵活的语法支持，rails变不出来这么多魔术。

但是ruby的语法灵活性恰恰是成为工业语言的一大障碍！Java绝顶高手和Java普通高手的代码在风格上不会有大的差别(我就不觉得Rod Johnson代码比我高明到哪里去)，但是ruby绝顶高手和ruby普通高手的代码简直判若云泥！高下立判！绝顶高手如DHH把ruby用的出神入化叹服之余，也让你我之辈根本无法写出来符合DHH风格的ruby代码。

在我们JavaEye2.0网站开发中，也出现了这种问题，两个人写的ruby代码，互相之间理解起来存在困难。而由于做一件事情有很多ruby写法，不同性格的人甚至都会选择不同的实现方法，在一个团队中，要统一编码风格，实在难乎其难！而在Java项目中，基本可以杜绝此类问题。

由于代码风格难以统一，因此在大规模的团队中使用ruby编程，会造成合作上面的障碍！


2、ruby on rails会导致你的代码藕合度非常高，不利于团队协作开发

由于rails规定死你的代码框架，不论是横向的功能解藕，还是纵向的分层解藕，都比较困难。

首先来说纵向的分层解藕，这是Java大规模项目常用的办法，但是在ruby on rails中基本不可能。因为ruby on rails各层之间的隐式约定太多了，你不可能分层开发。目前ruby on rails项目都是建议横向功能解藕，不建议纵向分层解藕的。

再说横向功能解藕：首先每个人必须承担足够大颗粒度的功能模块，不能拆分的太细了。因为rails的一个Controller文件就代表一大块功能了。

例如JavaEye2.0中，整个forum就只有一个controller，整个blog也就只有一个controller。当然你惊叹，整个forum代码就一个文件搞定了啊，代码太少了！但是反过来，你也可以说，论坛这个功能只能交给一个人来做了，没有办法再拆分功能了。这就带来了一个问题，团队协作变的困难了，如果两个人同时做论坛模块，就会出现经常性的该controller文件冲突合并。即使妥协一下，每个人只负责一个大功能块，但是底层的model代码都是互相关联在一起的。又难以避免的并发修改和文件冲突合并。

但是Java不存在这个问题，为什么呢？因为Java把一个Controller分解成为了无数个小Action，把一个Model分解成为了PO，DAO，Service，进行了充分的功能职责的解藕，每个人的工作基本不会互相干扰，那么团队协作的问题就好办了。

在JavaEye2.0开发过程中，就遇到了这个问题，即使是分出来一小部分任务，也经常性导致文件冲突合并，最后只能把大部分的程序任务压到了jerry一个人身上。可敬的jerry同学几乎以一人之力编写了整个JavaEye2.0的绝大多数代码。在惊叹jerry以一个人月的高效率完成整个JavaEye2.0编码工作的同时，我们也不得不反思，为什么ruby on rails这样难以团队协作开发呢？

在我最推崇的《Getting Real》这本书里面建议一个开发团队3个人足够了，一个人设计规划产品功能，一个人设计界面，一个人编写代码。我们现在也是这样的：robbin设计产品功能，ouspec负责界面，jerry编写代码，然后robbin和ouspec负责测试。但并不是所有的项目都可以靠3个人搞定的，大规模应用项目团队协作进行开发，我们目前还没有答案。

jerry有个观点我非常赞同，他认为目前我们没有找到合适的团队协作方法是因为现在的软件开发方法都不适合ruby on rails开发团队。而真正适合ruby on rails的软件开发方法究竟是什么样子，现在还没有出现，恐怕需要人们的探索了。ruby on rails流行必须伴随着适合ruby on rails的软件开发方法一起出现才行。

因此在人们总结出来这种适合ruby on rails的软件开发方法之前，ruby on rails仍然会被局限在web2.0开发领域，在这个领域，ruby on rails的所有优点将发挥的淋漓尽致，而缺点将会被回避开。不过一旦涉及到企业应用开发领域，我们将面临这些问题。

因此，我的结论就是ruby on rails目前尚且不适合企业应用项目的开发。当然如果有适合ruby on rails的软件开发指导方法的出现，或者企业应用本身的定义已经发生了彻底的改变，那么我的结论也就不复存在了。

用一句话来总结就是：

ruby on rails是武林高手的绝世宝剑，却不是两军对垒中士兵使用的常规作战武器(Java却是这种常规武器)。

BTW：我抛出来这个结论，并不代表我的想法已经很成熟了，事实上这也只是我们第一次尝试使用ruby on rails，在不熟悉不了解的情况下做出结论，未免过于草率，但是我之目的在于抛砖引玉，目前我们在开发中遇到了这些团队协作方面的问题，希望我的抛砖能够引出来好玉，解决这些我们还没有想到很好解决办法的问题，多谢啦，哈哈！

评论

47 楼 cracky 2007-03-28  

我的看法是企业应用应该即兼顾开发的规范高效又要能够应对表现的多变,这就要求在开发的时候M和C层是稳定和好维护的,而V层又是灵活易变并且容易追求用户更好的使用感受的,而这分别体现了编译类语言和解释类语言的优势,由此我不认为java跟ruby(或者其它)语言能够很好的实现所有的目的,java在良好的语言继承性和强势的企业推动条件下得到现在的地位,ruby在没有绝对优势的情况下,当然很难撼动java的地位

46 楼 helloworld 2006-12-29  

OK，说说我的看法，多年的开发使我越来越迷惑，也许是一直在国内的原因。现在的开发大体有以下几类
1）Web应用
2）企业应用
3）嵌入系统
4）GAME
5）Tools

先说企业应用，我所知道的最早的是cobol，后面是C/S时期的VB，PB，DELPHI，BC等等，java不知什么时候成了这里边最重要的一个部分。企业应用的游戏规则是数据〉〉报表，系统繁杂不堪忍受，于是有了软件项目生命周期管理之类的东西，不表。企业应用中最重要的是数据和业务规则，这两部分毫无疑问时静态语言的天下。恐怕没有用户会选择动态语言做这么关键的应用。还有就是UI和Report，如果用Web来表示就是脚本语言的特长了，所以Java在这里不死。很多脚本语言在表示层也生存下来，因为具体用什么脚本语言是无足轻重的。

再说Web应用，这个说起来就很伤心了，在95年我开始为它疯狂学习，到99年我开始赔钱，多年的工资贴进去啦，不说了。Web应用让很多人觉得过了30岁要失业，变化太快，门槛越来越低，已经成为一个大众化的东西，所以我法律专业的弟弟也能够自己动手建一个网站。ROR的出现是符合其发展特征的。WEB应用是一个真正的平民应用，拥有广大的用户。但大部分都是不挣钱的，因此，能够活下来的是像PERL一样不收钱，又有数量众多的用户的东西。

嵌入系统可能是仅次于WEB应用的一个东西，它有个好处，能盈利，而且还不错。这就是J2ME赚钱的原因。JAVA最开始就是为它设计的，错误的跑到WEB应用中去淘金，结果惹了一身的不是，还拼命的想待在里边。还好，阴差阳错的变成企业应用的平台。这里边目前没有动态语言的天下。但是，嵌入系统也在发展，在其人机界面和多机协作中动态语言有一展身手的空间。

后面两项不说了。
像Robbin这样资深的IT关注ROR，这本身引起我的兴趣，但我认为它就是提供最简单的方法，做最简单的东西，让人人可以做WEB应用，有些人的点子就可能不再有技术上和人力资源的障碍就可以实现。这和PHP把大量中专学员送到WEB应用开发前线一样。ROR可能做得更好一些。

看了“java将死”，很好，可惜不能回复了。
T1是有灵气的，很多技术折腾来折腾去，实际上就那么点东西，但那点东西又不止那点东西。只有领悟了的人知道，怎么变化都只是其形，离不开其质。
什么东西是真正重要的，ROR是一个很热的东西，而且可能也会流行下去。但是不是重要的，Java出不出6也不重要，Javaeye这个网站的发展比这些都要重要，因为有很多IT业智者在这里言论。行业的发展往往不是大众化的东西导向的。

45 楼 whisper 2006-12-16  

感觉这就是java在垂死挣扎
没有任何用java的人会去批评perl的解决问题不止一种方法的理念，因为二者不在一个利益范畴之内
python也并非转为web而存在
反倒是ruby摸到了java的痛处
java应当退到他的最佳实践中去，而不是在ruby占有明显优势的地方负隅顽抗，就像当年C++做的那样

44 楼 johnyq 2006-12-15  

虽然自己很喜欢ROR 但是却对其应用前景不乐观
先天上，前面大家说了很多了；后天上，很多既得利益方对其发展制造些障碍，但是话说回来，“无人妒忌是庸才” 呵呵~

43 楼 stonelu 2006-12-13  

偶是刚刚学习ruby,才不到一个月,偶的感觉ror是一辆赛车,也许还是辆ferrari,但是不适合在大马路上跑.相反中规中矩的QQ(java),倒是蛮适合马路上乱蹦的.
ruby要是想挺进企业应用,我想没有4-5年的光景,连门槛都进不了,除非有更多的rails出现
哈,偶有点坐井观天了哈

42 楼 梁利锋 2006-12-12  

引用

例如JavaEye2.0中，整个forum就只有一个controller，整个blog也就只有一个controller。当然你惊叹，整个forum代码就一个文件搞定了啊，代码太少了！但是反过来，你也可以说，论坛这个功能只能交给一个人来做了，没有办法再拆分功能了。这就带来了一个问题，团队协作变的困难了，如果两个人同时做论坛模块，就会出现经常性的该controller文件冲突合并。即使妥协一下，每个人只负责一个大功能块，但是底层的model代码都是互相关联在一起的。又难以避免的并发修改和文件冲突合并。

　　我听说，ROR就是设计为敏捷开发服务的，也可以说用ROR就必须用敏捷开发。

　　敏捷开发我只了解一些XP，XP中有一些原则，比如测试驱动开发、结对编程、迭代开发等等。

　　从文中介绍的情况来看，至少你们没有使用结对编程。

　　假设有4个程序员ABCD，结对的情况是怎么样呢？

　　可能是第一天上午AB结对开发函数X、CD结对开发函数Y，下午AC结对开发函数Z、BD结对开发函数X；第二天上午AD结对开发函数Y、BC结对开发函数Z，下午又是CD结对开发函数Z、AB结对开发函数Y。

　　这就是说，结对的两个人不是固定的，所开发的模块也是变化的，所以，一个 Controller 即不是一个人开发的，也不是结对的两个人开发的，而是所有开发人员共同开发的。事实上，连一个函数也非常可能是由多个人完成的。这样，在项目结束时，所有人对项目的所有部分都有接触，所有的开发人员都可以进行项目维护，离开一个人，或者加入一个新人，对于开发团队不会造成大的不利影响。

　　而在结对编程中，那些“奇技淫巧”可以通过结对的两个人的讨论，得以传播、或者放弃。结果是统一思想、统一编程风格等等，也就使得开发出来的软件的可维护性增强。

　　事实上，就我的理解，使用XP开发，就算只有2个人进行开发，也应该结对编程。

　　不知道这算不算解答了文中的问题？

41 楼 taowen 2006-09-22  

+1 交流成本。

40 楼 badqiu 2006-09-18  

引用

Ruby 的语法太复杂？ 我还没见过比 Ruby 的语法更自然，更简洁的。

正如robbin如说的,ruby就是由于有一些奇淫技巧,导致程序员之间编写的代码风格等可能差异很大.

你所说的简洁是因为与JAVA相比的代码量可以减到很少,而我注重的是程序员之间的交互成本

39 楼 uncutstone 2006-09-18  

njmzhang 写道

uncutstone 写道

Ruby 的语法太复杂？ 我还没见过比 Ruby 的语法更自然，更简洁的。

SmallTalk...

搞笑。

38 楼 njmzhang 2006-09-18  

uncutstone 写道

Ruby 的语法太复杂？ 我还没见过比 Ruby 的语法更自然，更简洁的。

SmallTalk...

37 楼 uncutstone 2006-09-18  

Ruby 的语法太复杂？ 我还没见过比 Ruby 的语法更自然，更简洁的。

36 楼 badqiu 2006-09-18  

大家为什么不讨论一下ruby的语法呢,我觉得这个才是主要的问题.太复杂,协作困难

35 楼 uncutstone 2006-09-18  

更加 make sense 的代码应该是这样的：

class Person
end

class Manager
end

degrade_to_module Manager # imaginary

class Man < Person
end

m = Man.new
m.extend(Manager)

34 楼 uncutstone 2006-09-18  

请看我对前贴的改动。

33 楼 gigix 2006-09-18  

uncutstone 写道

我没有看过  Ruby 的源代码，不过可以猜想 模块和 类的主要差别：

类可以生成实例对象，实例对象有单独的对象 id,实例对象有单独的存储区。

我进一步想象，呵呵：把类退化成模块，就需要去除对象 id 。允许原来单独存储的实例对象数据被合并到其他类的实例对象中。

你说的这个我没有看明白。在我看来没有那么些复杂的事，所谓的对象，无非就是一组函数加上一个暗含的self；所谓的模块，无非就是假设了一个self但自己没有提供；所谓的mixin，无非就是把一个函数塞进另一个self的环境里面。
你要是习惯了JavaScript，就不会有那么多条条框框的想法了。什么“正统面向对象”，面向对象还有一支叫prototype-based oo呢。

32 楼 uncutstone 2006-09-18  

gigix 写道

uncutstone 写道

类无法被 mixin, 把类退化为模块，是为了能够被 mixin.

你没有明白我的意思。

你说的是Ruby么？

对啊。 是我对 Ruby 发展的一种猜想。mixin 一个退化的类意思是： 在一个类已经从另一个类继承的情况下，需要引入又一个类的功能。 举例来说， 男人从人继承，同时又想扮演 manager 的角色， 这里涉及到三个类。

按照传统的做法，manager 通常作为一个实例变量放到 man  类中。 man 类成为manager 的delegator.但是这样需要很多的 delegate 方法，很不方便。

我的想法是让manager 类可以通过某种语言机制退化为模块，从而可以

class Person
end

class Manager
end

module_degrade Manager  # imaginary

class Man < Person
   include Manager
end

31 楼 gigix 2006-09-18  

uncutstone 写道

类无法被 mixin, 把类退化为模块，是为了能够被 mixin.

你没有明白我的意思。

你说的是Ruby么？

30 楼 gigix 2006-09-18  

ajoo 写道

一个关于rails的初级问题：
rails的魔板和jsp很像。不知道能否做到freemarker的macro功能？觉得不能重用显示逻辑还是不太爽的。

partial template?

29 楼 jkit 2006-09-18  

这就是为什么ruby在日本市场并不火的原因！

28 楼 buaawhl 2006-09-18  

potian 写道

在Ruby中，Object、Class和Module是三个特殊的类。它们的创建过程被分为两个步骤，而不是象其它类一样一步到位。首先，Ruby建立这3个类的继承关系，但是并没有创建它们的metaclass，形成下图的情形，这个时候还没有符合类的关系，以及它们的metaclass必须符合的规则：

这首先解决了一个问题，就是说Class是一个Module，而Module是一个Object，所以说Class是一个Object，因此，所有的数据都是Object。

------------------

rails template 应该可以用 helper 类达到taglib这样的重用的效果。
helper类的写法，可能不如freemarker macro简单。也许可以自己创造个Ruby DSL as Macro.