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

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

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



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



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，在不熟悉不了解的情况下做出结论，未免过于草率，但是我之目的在于抛砖引玉，目前我们在开发中遇到了这些团队协作方面的问题，希望我的抛砖能够引出来好玉，解决这些我们还没有想到很好解决办法的问题，多谢啦，哈哈！

同意Java下大家的代码都差不多。
但如果大家都只是老老实实的用rails的api写基本应用代码时，是不是也能差不多？

标题打得好高啊。

rails 现在的主要目标是成为 web开发的主流 就已经很不错了。

等这个目标拿下了，再考虑成为企业应用的主流吧。


另，从你的描述的情况来看，似乎你的设计违背了一些OO的基本原则（比如职责过多..)

这些OO的原则和具体的OO语言无关，既然Rails是一个OO的框架，我想这些原则的遵循还是可以被遵循的。

对rails没有使用经验，仅仅从OO的角度来看待问题。

其实，从我的个人经验来看，如果平时不注重代码重构的，在更灵活的环境里面，更加容易犯这个错误。
从java 到 rails，灵活程度上升了一个台阶，原来在用java开发的时候所存在的问题 在 rails或许加了一个放大倍数也不一定呢？ 赫赫  

rails框架已经约定要求你这样做了，这个没有什么变通的余地，除非你愿意很别扭的使用rails，或者放弃rails。

rails的ActiveRecord模型也本来就不是符合OO原则的，这已经是尽人皆知的事情了。

一个URL，对应一个Action (Controller)，Java MVC里面也是这样的。Spring MVC就是很多Controller。
只是Rails的URL分为两级，forum/index, forum/show。大家喜欢把index, show变成method而已。
完全可以像topic那样拆分出来，forumIndex, forumShow。
关于model, Rails没有限定一个controller只能使用一个model吧？
只看过RoR book的相关部分，强烈期待各路Rails好手的意见。

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

Rails的设计，相当于大量使用 code generation，这只是ruby语法的少数特性而已（mixin, etc），还有很大可以提高的余地。只不过Ruby MVC 领域目前还处于一种山中无老虎，猴子称霸王的状态。等到Ruby足够红火，引得一批Java MVC高手过来，这个局面立刻改观。
我做MVC不怎么样，看到RoR都觉得技痒，感觉用Ruby可以很容易做出不错的MVC，想怎么整，就怎么整。只是还是对Ruby性能有些过虑，对自己能力信心也不足，不敢这么快跳进来，精力暂时放在别处。
一旦这个语法潜力爆发出来，Ruby的各个领域，都会百花齐放，欣欣向荣。在Java里面辛辛苦苦整出来的各种特性（AOP，Dynamic Deployment，Runtime Monitor，Law of Demeter... etc），在Ruby里面轻而易举。
Ruby这类动态语言，非常适合做容器和动态组件，而这是企业应用的一个关键特性之一。未来的Web Service Client更是动态语言的天下。

Ruby的问题在于基础设施太薄弱，而且意志很薄弱，还很自满，号称只做必要的，不做重复的。宁可嵌入C, 宁可包装半天引用C Lib，也不愿意直接向这些领域进军。后劲儿严重缺乏，最终，可能只是进行了动态语言的普及教育，给其他语言作了嫁衣。
搞到后来，可不就是只做必要的，就做Web/MVC/ORM这块最有前途、最简单重复的领域吧。就在Web2.0这个小潭子里面可劲儿折腾吧。

不过我相信，有识之士已经在偷摸鼓捣了。搜索了一下Sourceforge，Ruby Project 400多个，Corba, Map Reduce之类的，也都有了，还是一个可喜的进步。
（Python 3000多个。可能是Ruby宣传工具很厉害，大家有个感觉，Python败给Ruby了。殊不知，Python的用户量正在直追Perl，而Ruby短期内翻了14倍，也才是Python的1/3。当然，如果Ruby的增幅可以这么持续下去，很快连头牌Java都可以超过）

--------------------------
Ruby的Code Style Check应该比Java容易做，至少不用antlr, javaCC等Parser Generator了，动态语言自个儿就偷摸搞定了。

搜索了一下，只发现了一个工具。市场还不繁荣。
http://www.cs.umd.edu/~nspring/software/style-check-readme.html

不过，可以想见，一旦这方面的需求有了，各种code style checker会雨后春笋般冒出来。

这样就向java退化了一步，rails带来的收益也立马减少了很多。


据我观察，从java迁移到ruby的主力是以前有很深smalltalk背景的以及咨询/图书业者，真正直接从java开源社区过去的干将，太少了，好像除了testng的Cedric还真没看到别的(即便是他，也仍然还抱着java)。
这两个社区的文化差异太大，尤其是rails社区，如果不改一改风格，要想进一步吸引开发者而不是使用者，是很难的.
不过，从perl转向ruby的倒是有不少，但是多数还在等待perl6


从开源项目开发者的平均水平来说，python的可能还要略高于java，ruby现在缺乏资深人士的介入


robbin的意思好像不是指style方面的，而是都符合style的情形下的多样性

稍微看了一下rails的tutorial（否则robbin的话都看不懂）

针对robbin的说法有几个问题：
1。为什么说active record不OO？具体指什么？

2。关于纵向分解。什么妨碍了纵向分解？view和controller就是可以分开的吧？如果存在active record不缺省支持的复杂的business logic，难道不可以单独独立出来么？ioc注射我是没有看见怎么解决，因为似乎model对象的创建都是framework自己封闭搞定的。但是service locator没问题呀。或者聪明些，弄一个统一的类似"dependency :service1, :service2, :service3"的这种东西来，和一个外部ioc容器连接起来都没有问题。

3。关于横向分解。ruby应该是有mixin的吧？那么，不同的人分管一个controller的不同action，写成module，最后mixin进来不成么？

首先，感谢楼上的详细解答和丰富信息。

另外，看了《getting real》，一家伟大的公司──37signals，及他们的 Ruby on Rails。还找了一个读书笔记。
http://blog.donews.com/dengyu/archive/2006/03/20/777440.aspx



我想起Potian给出的一个Link，叫做beating the average。是讲Lisp的。
我基本同意其中的观点 —— 语法决定论。一门语言最强大的就是语法了。
Ruby的语法不是成为企业应用的障碍，正相反，Ruby的语法是占领企业应用市场的法宝。
从前的script（js,perl,php）的问题在于模块化管理很差，这些是动态语言难以管理的主要障碍。
而对于ruby, python来说，模块化已经做的非常好，package, module, class，完全具备了大规模代码管理的潜力。
当然，缺乏编译期类型检查可能是一个问题。但是，可以采用TDD，Code Analzyer等辅助手段来缓解。

Ruby的阻碍在于什么呢？
我的个人看法，成也萧何，败也萧何。成也Rails，败也Rails。
“专注于解决简单的问题，将其他复杂、头痛、难解的留给对手”
看看这个口号。谁也不是傻瓜。谁不知道做简单赚大钱的事情。
Signal37成功了，但是这种模式是无法简单复制的。大家都争着去做简单的事情得了。
确实，人类还有相当多的随便实现一下就可以满足的简单需求可以挖掘，但是肯定远远少于Web2.0公司的数目。

关于Ruby, Python的潜力。

http://buaawhl.iteye.com/blog/21333

active record 推荐继承，而继承override可能是其他语法没有、OO语法唯一独有的特色了。
从这点来看，active record 非常 OO。

说active record 不够OO，可能主要是说rails plugin给 active record 里面 mixin 更多的method。造成一个Object 的方法非常多，接口非常宽。
OO极端思想，一个类只做一件事情。从这个观点来看，确实不够OO。

mixin不是什么好东西。没办法的时候才用的。一般只应该用在框架中，正如cglib这些东西只能用在框架中，正经的项目开发中怎么能使用呢？

一般的小网站项目中可能没有那么多的service，都是curd，query和functional代码。service locator的帮助有限。

这里面的问题主要在于Rails的神话。简单就是美。
我觉得，rails虽然确实比PHP, Perl美。但还是不够美。
带有一定的鼓励quick and dirty的因素。

我不得不说，和一帮子没有ruby on rails实践经验的人讨论ruby on rails的话题实在是无趣呀！看你们牛唇不对马嘴的回贴我就一阵阵难过呀，难道就没有知音了？

《Getting Real》中文读书笔记请看这里：
http://indigos.cn/?cat=13