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

评论

27 楼 ajoo 2006-09-18  

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

26 楼 uncutstone 2006-09-18  

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

你没有明白我的意思。

25 楼 cookoo 2006-09-18  

mixin不一定代表多重继承啊。一个类可以什么都不继承而被另一个模块mixin从而简单复用，当然你可以说任何类都继承自Object。。。

module只代表namespace罢了，相当于package，为什么要把class退化过去？

24 楼 uncutstone 2006-09-18  

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

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

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

23 楼 buaawhl 2006-09-17  

现在，OO设计里面，继承都是不推荐的。多重继承的设计更加很少出现了。
mixin当然比c++多重继承漂亮，也比java的包含一个接口，然后delegate这个接口的所有方法好的多。
好是好。但是，一旦出现了mixin，就意味着这部分的设计对应C++的多重继承。而多重继承应该是作为反模式尽量避免的，不得已才使用的。
不能说，动态语言多么强悍，只需要考虑hack，根本不用考虑其他语言的任何设计原则。这个和UML无关，UML表达Java也不足够。

另外，这个module = class的想法不错。
我也觉得，如果ruby的module,class的概念统一起来，整个语法结构和概念就会简单一些。
module可以相当于partial class, inner class, local class。

22 楼 uncutstone 2006-09-17  

我个人认为，在目前流行的语言中，Ruby 可能是设计得最好的语言。所以才可能出现 Rails 这样优雅的框架。

要说 Ruby 的障碍，最大的应该是来自日本这个非英语国家。

至于 mixin , 我认为这是非常实用非常漂亮的设计。相对于 C++的多重继承和 java 的接口继承，mixin 机制实在是漂亮。

因为现实世界中的对象具有相当复杂的多面性，而这种多面性出现在语言中往往是通过修饰性的定语或形容词来表示、来限定。这种限定是灵活多变的，而继承，总的来说，是一种死板的分层和分类机制，不适合于用于表示这种灵活的东西。Java 的接口在我看来正是为了解决这种问题， 但它很做作，很不自然。mixin 在我看来是最自然的机制。

我大胆猜想，为了表示作为教师的他，作为学生的他，作为经理的他 这一类的问题。能不能在 Ruby 中提供一种退化机制，把类退化为模块，使得它可以被mixin 到另一个类中。

21 楼 robbin 2006-09-17  

cookoo才是我的知音呀

20 楼 cookoo 2006-09-17  

buaawhl 写道

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

你想证明Ruby的阻碍在于Rails,因为现在Rails的策略专注于web2.0泡沫？呵呵，但是即使没有Rails，90%简单的web需求还是存在的，web2.0照样有人搞。现在有工具能提高效率，何乐而不用？新的需求不断被市场发现，然后被大量公司通过竞争抓住机会，这过程中必然有公司被淘汰。你怎么推理出这会阻碍某种技术呢？以前网络泡沫破灭有没有阻碍php发展呢？如果阻碍的话，那别的web技术如asp,jsp也一样被阻碍，最后还是不会影响php的地位。

19 楼 cookoo 2006-09-17  

对Rails开发方式我也在思考，对动态类型和meta programming已有的一些实践需要调整，也许需要引入一些新的做法。不得不说目前的大部分Rails项目都是少数几个人搞出来，即使那些访问量较大的成功站点不代表其代码量就大到需要很多人编程。所以对大规模的项目如何管理开发没有什么典型的例子。Getting Real涉及一些，不过更多是讲商业上的而不是软工上的实践。

动态语言不使用强制的interface而是用duck type，也就是隐性的接口。这种对象界面间的隐性接口在Rails里被进一步扩大，也就是robbin说的mvc之间的各种约定。显然在这种情况下测试被放在一个更重要的地位上，但是麻烦在于有些约定是不是那么容易测试的（何况Robbin赶时间没写测试。。。）。没有测试就不敢动别人的代码，不小心破坏了某些约定也无知无觉。但是我感觉即使Rails内置了多达三个层次上的测试手段（基本对应MVC三层），面对那些鬼斧神工般的class_eval和monkey patch还是有些力不从心，需要更智能的覆盖测试工具。我一直很喜欢Matz说过的Ruby设计哲学：A sharp knife may cut your fingers, but it's better than a dull one. 想少受伤怎么办呢？长远的办法是磨练使用技术，而直接的就是加强防护带手套咯。至于那些说Ruby过于灵活的就好比说要把刀磨钝点才更安全一样 如何磨练技术和加强防护这是值得长期研究的。

Robbin说的纵向分割困难我也有体会，比如validation和权限系统几乎要贯穿mvc三层，有些情况下MVC要清晰切分确实不如理论上那么容易。从实践角度讲无需追求那种纯洁性，但是软工角度上确实不容易分工。至于横向分割还好吧，对复杂的逻辑我也见过用命名域分割的，虽然这种做法会需要调整route和一些helper，甚至一些plugin。至于一个controller的action太多我认为是设计问题，scaffold给人的一个不好的错觉是误以为一个controller得对应一个model。其实一个controller对应的是一个function,它可以对应一个model或几个model， 一个model也可以被几个controller对应。如果一个controller太臃肿，function可以重新划分一下。

最后Java界积累的那些模式和工具（AOP, IoC之类）哪些能套用哪些不能或哪些需要修改才能适用到Rails上不是简单能分析出来的，估计需要比较长的时间才能融合。这个过程可能非常慢，因为大部分用Rails的人主要关心get job done并且符合自然和美感，大家喜欢谈论是那些美妙的hack而不是书本上的UML。C++/Java的设计模式其实很早在Python和Ruby社团都有人研究，但是始终很少有人刻意强调。Why? 我们不要忘记设计模式是怎么出来的，是人们经过长年累月的使用OO语言（主要是C++）总结出来的那些反复出现的好的设计思路。所以对那些非C++类的语言，一是需要时间积累，二是出现的新模式可能和现在的不同, 三是需要足够大的项目才会促使人思考这些问题，否则就不值得花这个力气。

18 楼 buaawhl 2006-09-17  

ajoo 写道

buaawhl 写道

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

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

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

我怎么觉得这是oo牛角尖思想？
active record负责一个model的persistence，为什么不是一件事？
接口宽窄，要看要描述的东西，如果就有那么多方法，宽些又怎么？
更何况，这些东西又不是硬写进去，而是通过mixin, meta-programming进去的，根据java这种什么都得自己硬写的语言的一些法则就不见的适用。
一般一个模块的设计要从两个方面考虑：
1。从最终用户的角度，一个active record的接口只要自然好用就好，谁关心内部怎么写的？
2。从实现角度，只要不是把所有的代码都堆在一个类里面，通过delegate, meta-program, mixin而产生的东西并不会因为类的方法过多造成问题。

mxin，我是觉得不错的冬冬。不至于是没办法采用。（觉得比继承还要好呢）

我说的是，rails plugin。不是active record本身。active record本身，我不是说了吗，非常OO。
rails plugin是给这一个Object增加各种act as的功能。这就涉及到mixin好还是坏了。
先不管module的重用作用。如果用module mixin把一个类的功能代码分开，就相当于把一个类，拆成几个文件来写，作用类似于partial class。如果不是非常必要，这有什么好处呢？同一个scope，要考虑命名冲突，做一个module，还要想着其他module，各种麻烦。
mixin和delegate是相对的。mixin是横向，delegate是纵向的。mixin是同一个class scope，delegate是多个class scope。而且只有delegate才能更好的使用IoC。
module mixin当然有用处，我们都知道有些情况下，多重继承的好处，不用delegate很多methond。但应该限制使用，不应该成为主要开发方法。

robbin给的学习笔记不错。比我找到的那个目录强多了。虽然主要是管理和市场方面。
关于robbin的“缺乏知音”的悲叹。我对rails有些偏见，这个我承认。
我主要的观点是认为，robbin对ruby语法的批评，有点把rails的问题怪在ruby头上的意思。Ruby语法并没有大的毛病，可以胜任企业开发。RoR当然不胜任，这个不用说了，DHH自己都说了。

17 楼 ajoo 2006-09-17  

model和持久化绑定却是有点问题。

不过，问题主要还是在view直接用po把？

controller是直接也好，绕八道弯也好，总归要调用po的。


而rails里面view用po可能并不象java里面那么严重。
rails是动态类型的。view自己并没有强制要求用po，使用者（或者rails框架）要是高兴，完全可以把po复制成vo再传递给view。反正view层只要你给它提供了那些field就行了。

这就像面相接口编程，view只要这个IForum接口，至于你controller是把PersistenceForum直接给传过来，或者通过一个adapter传过来，或者弄个vo，先把po拷贝到vo再传过来，view层都无所谓。

rails只是缺省没有做这个po->vo的copy过程。我觉得只要没有直接耦合，不做这个copy一般来说挺好的。

16 楼 ajoo 2006-09-17  

robbin 写道

ajoo 写道

稍微看了一下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进来不成么？

1、rails的ActiveReord是把持久化操作和domain logic都放在model里面，而一般来说持久化操作往往要分离出去。

2、我说的纵向分解的意思是说，用rails开发，你让一个人写Controller，另外一个人写Model，第三个人写View，这三个人的开发效率都会降低到可怜的程度，因为这三层之间互相之间的隐式约定太多了。但是在Java开发中，你让一个人负责持久层，一个人负责业务层，一个人负责web层，通常合作起来还是高效的。

3、按照你那样做似乎也是可以的，但是我直觉上感觉这样做会把整个项目代码搞的很复杂的。

1。我没有看ActiveRecord的实现代码。也许它的实现确实不oo，但是从使用者的角度我倒看不出来哪里不OO，无非就是一些个库函数。有什么oo不oo的？
2。嗯。如果model, controller都比较简单的话，却是分开的代价要大于收益。不过此时也本来就没必要分开吧？我说的是如果有一些比较复杂的商业逻辑，比如搞个规则引擎什么的，纵向分解应该没什么不可能吧？
3。恩。没实践过也不好说。我的感觉倒是没觉得这会造成复杂性。反正是一个想法，robbin可以考虑有没有可能性。

15 楼 ajoo 2006-09-17  

buaawhl 写道

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

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

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

我怎么觉得这是oo牛角尖思想？
active record负责一个model的persistence，为什么不是一件事？
接口宽窄，要看要描述的东西，如果就有那么多方法，宽些又怎么？
更何况，这些东西又不是硬写进去，而是通过mixin, meta-programming进去的，根据java这种什么都得自己硬写的语言的一些法则就不见的适用。
一般一个模块的设计要从两个方面考虑：
1。从最终用户的角度，一个active record的接口只要自然好用就好，谁关心内部怎么写的？
2。从实现角度，只要不是把所有的代码都堆在一个类里面，通过delegate, meta-program, mixin而产生的东西并不会因为类的方法过多造成问题。

mxin，我是觉得不错的冬冬。不至于是没办法才用。（觉得比继承还要好呢）

14 楼 robbin 2006-09-17  

ajoo 写道

稍微看了一下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进来不成么？

1、rails的ActiveReord是把持久化操作和domain logic都放在model里面，而一般来说持久化操作往往要分离出去。

2、我说的纵向分解的意思是说，用rails开发，你让一个人写Controller，另外一个人写Model，第三个人写View，这三个人的开发效率都会降低到可怜的程度，因为这三层之间互相之间的隐式约定太多了。但是在Java开发中，你让一个人负责持久层，一个人负责业务层，一个人负责web层，通常合作起来还是高效的。

3、按照你那样做似乎也是可以的，但是我直觉上感觉这样做会把整个项目代码搞的很复杂的。

13 楼 robbin 2006-09-17  

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

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

12 楼 buaawhl 2006-09-17  

ajoo 写道

稍微看了一下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进来不成么？

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的因素。

11 楼 buaawhl 2006-09-17  

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

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

引用

1、少做点，做精些
    更少的功能 －－ 专注于解决简单的问题，将其他复杂、头痛、难解的留给对手
    更少的选择和选响
    更少的人和公司结构
    更少的会议
    更少的承诺

2、闭门造车
    相似性 －大家都是类似的，所以你遇到的问题别人也会遇到
    热情 －只有为你自己解决问题，你才能有热情真正的使用和关心它

3、花自己的钱
    只有花自己的钱才能干“小事”，干”快事”
    “限制”产生创意，再各种条件的限制下才能激发创意去解决问题

4、灵活的Scope
    如果不能准时和按照预算完成项目，那就将减少scope. 总有时间增加其他的东西.
    发布一个更少scope的产品总好过发布一个满是漏洞的要好。
    保持scope灵活的方法
    a. 定义优先级
    b.实际的期望值
    c.灵活性
   
5、找个敌人
    驱动力因素
    不同的定位或者“故事”

6、享受过程
    保持产品可管理和控制性，并且享受其中的过程和乐趣！

我想起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

引用

  下一代（大众）语言霸主应该具备的条件
关键字: 企业应用      

这是BJUG里面讨论Java前途，Ruby前景的时候，我写的一篇回复。贴在这里。

下一代（大众）语言霸主应该具备的条件
语法的延续性？
静态类型安全？

-----

有一本书叫做 beyond java。
介绍了java的主要竞争对手。Ruby (Rail), Python, .net ( C Omega)
次要对手，php, lisp, smalltalk (seaside), perl, FP.

那篇Java不适合SOA的文章，主要讲了Java的跨平台的虚拟机在SOA方面没有优势，因为代码不需要移动。（我感觉很奇怪，B/S结构不也是这样）。然后下了一堆结论，不论从任何一个方面看，Java就是不适合SOA。可能是摘要。具体参数例子，没有看到。
最感兴趣的部分就没有看到。

liusong说的Web Service Client，我也有同感。
Web Service Client 绝对是Script的天下。编译语言丑陋的WSDL binding令人难以容忍。
我看了Java, C# 的generated stub，就下定了决心，除非有很多钱赚，不然拒绝采用编译语言作web service client。:D

Web B/S 方面（主要是server side开发），script实现Bean Utils, OGNL之类更容易，还有continuation，这是一点优势，但毕竟是server side，还有大量的数据处理部分，我认为，这些优势还不够保证Server Side的天下。且观望着。

--- 下面回顾一下Java的历史和现状，看看下一代语言霸主应该符合怎样的条件
Java的开发效率从来就没有达到过最高。只是比C++高。而C++是上一代霸主。
Lisp, Smalltalk就一直号称比Java开发效率高。

首先来定义一下，什么样的语言，才能称为霸主。
1. 程序员数目最多。
Web内容管理方面的开源项目，PHP项目的数量和质量都远远超过Java。但是，却和人数不成正比。可见脚本语言的开发效率有多高。
为什么开发效率相对不高，Java为什么还能够保持这么大的程序员数目？
我猜想，可能和静态类型安全有关。也可能和语言的延续有关。
回顾一下语言简短的历史。C语言是 C++之前的语言霸主。
c, c++, java的语法基本一脉相承。
比如，= , ==, 这样的语法。我的个人观点，看上去就是不如 :=, =好看。但是保持了一种延续性。

2. 其他语言都把它作为比较标准。

几乎所有的语言都把Java作为开发效率和运行效率的比较标准。
比Java开发快多少。比Java运行快多少。从以前到现在，从来就没有间断过。
从这点看，Java确实是当之无愧的霸主。

Gosling ：如果你看看它们的程序，你就会发现，它们看起来就像Java程序一样。

殊不知，这正是关键所在。
Ruby, Python, C# 之所以被称为Java的主要竞争对手。是因为他们保持了语言的延续性，就是说，它们看起来像Java。正如Java看起来像C++。
PHP也认识到了这种傍大款的好处，PHP5也开始看起来像Java。只是有些晚。并且对PHP从前的用户并不是很友好。有点 c 到 c++的意味。不过，我还是很看好PHP的，毕竟原有的程序员基数巨大。

----- 静态类型安全的魔咒

动态语言是否能够打破静态类型安全的魔咒, 成为语言霸主?
下一代语言霸主是否还是静态类型语言？
我们来看看，虽然是静态类型，c的类型其实不太安全，c++，Java的类型就比较安全，所以更加流行。以至于很多人依赖于静态类型安全。
复杂系统中，如果没有一个静态类型系统作为保障，很容易迷失方向。
静态类型安全是否必要？
TDD的经验，令很多人改变了看法，不再像以前一样依赖于静态类型安全。尤其是开发经验相当丰富的开发高手。
这里就有一个问题。
静态类型安全目前是适合大众的需求，所以，静态类型安全语言，才能成为大众语言。
高手的摆脱静态类型安全的开发经验（TDD等），能否普及到大众？
大众能否同样摆脱静态类型安全的依赖？这是一个很关键的问题。
如果大众摆脱不了对静态类型安全的依赖，那么动态语言就无法成为大众语言，无法成为语言霸主。（如果是这样，唯一的挑战Java霸主地位的只有C#了）。
我想，时代总是进步的。大众早晚都会摆脱对静态类型安全的依赖。只是早晚的问题。但这个早晚非常重要。比如, Non Static Type的 Smalltalk历史更加久远，更加OO，更加优雅，开发效率更高，但是一直没有成为主流，直到c++ like, static type safe的Java崛起之后抢尽了所有风头，从此smalltalk一蹶不振，错失良机，人数缩水。

这里的时间点问题，就在于，高手的摆脱静态类型依赖的开发经验，能否普及到大众，以便助动态类型语言登上大众语言的霸主宝座。

------ 静态类型确实影响重用

有时候，为了一些通用算法的重用，不得不统一interface，引入类型强制转换，放弃类型安全（我还是反对大量使用目前的Reflection API，因为那套API实在是麻烦）。
(Static Type FP 如 Haskell, OCaml是如何解决这个问题的，由于不熟悉语法，我还没有参透。好像他们的Type相当于Meta Class，Super Type，而Class相当于Data)

放弃了类型安全，还有些不甘心，于是引入运行时类型检查。
Class 之间利用 isAssignable 进行前后代的距离检查，instanceof 进行最后一关检查。以至于引入了一个复杂的Class检查体系。后来我发现，虽然没有使用reflection，但是做的这套工作和Script做的工作也差不多。JavaScript不也是采用 if (o.method) 来进行类型安全检查吗？而在编译里面做运行时类型检查比动态语言费劲多了。
这违反了我的原则 —— 用一门语言应该尽量发挥它的长处，而不是总想着避免它的短处。于是我放弃了这套工作。

静态类型负面效应，最臭名昭著的例子，就是完整的Visitor Pattern里面的 Visited Interface ( Visitable Interface )。里面的双重Type Dispatch。accept( visitor) { visitor.visit(this);}
这就是把静态类型用到极致的后果 （引起的类型循环依赖密集和广泛程度和难以想象，所有的不相关的visited type全都通过visitor interface相互网状交织依赖）

通常这种情况下，我宁可放弃类型安全。采用类型强制转换，也不愿意引入visited interface。

10 楼 ajoo 2006-09-17  

稍微看了一下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进来不成么？

9 楼 levinfox 2006-09-17  

buaawhl 写道

一个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好手的意见。

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

引用

Rails的设计，相当于大量使用 code generation，这只是ruby语法的少数特性而已（mixin, etc），还有很大可以提高的余地。只不过Ruby MVC 领域目前还处于一种山中无老虎，猴子称霸王的状态。等到Ruby足够红火，引得一批Java MVC高手过来，这个局面立刻改观。

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

引用

Python 3000多个。可能是Ruby宣传工具很厉害，大家有个感觉，Python败给Ruby了。殊不知，Python的用户量正在直追Perl，而Ruby短期内翻了14倍，也才是Python的1/3。当然，如果Ruby的增幅可以这么持续下去，很快连头牌Java都可以超过

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

引用

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

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

8 楼 levinfox 2006-09-17  

ajoo 写道

对rails没有经验，就敢这么说了？强啊。看来xp,tdd给人的信心真的不是一点半点。

没吃过猪肉，难道还没见过猪跑？