RoR在扩建复杂系统中的问题

多年来Ruby社区一直以来都承受一个压力，那就是runtime performance scalability。现在很多人也用同样的眼光看待RoR，然而在Cal Henderson的书 中指出网站运行时性能的扩展性可以通过增加服务器来解决。这在RoR里面实现是很简单的。

RoR在现实中遇到的更多的问题是面对复杂性表现出来的可伸缩性(scalability in terms of complexity)。当系统变得越来越复杂的时候，我们发现可伸缩性越来越小，或者说我们需要花费更多的精力到系统维护中。那么这种成本怎么会产生的呢?

我们先来看看人们为什么会采用RoR开发项目。首先Ruby是一种high level programming language。它区别于C/C++这些low level programming language在于指针不暴露给编程人员，这样就避免了编程人员整天浸泡因为指针而犯的错误中。在这个层面上我觉得Ruby和Java、C#不存在什么区别。其次RoR是full stack solution， 在这一点上，也有人认为Ruby社区没有提供足够的lib供开发人员选择。我不知道当RoR提供了Seaside的实现后，这种优势是否存在。

下面我们讨论RoR在构建复杂系统可伸缩性减小的原因:

http://jack.lifegoo.com/?p=134

评论

3 楼 robbin 2007-04-29  

引用

1. Ruby 动态解释和mixin的继承方式使得寻找bug的过程变得异常艰难。而有时候通过长时间的寻找发现造成bug的原因是变量的笔误或者是参数顺序的问题。Ruby不象Java和C可以在编译阶段把一些低级的错误定位出来。这也使得Behavior Test显得更加重要。如果没有测试辅助，这方面的成本将会随着系统的复杂而增加。

以我们已经写了超过一万行ruby代码，超过二万行rhtml代码的实践经验来看，拼写错误的定位可以说是非常容易的。我差不多平均每天都会出现2-3次拼写错误，但是每次拼写错误的定位平均不超过10秒钟。所以下结论不要总是想当然。

要说bug，其实最难寻找的bug是不小心覆盖了系统或者库已经使用的命名。ruby和rails里面有大量已经被使用掉的命名方式，有时候你按照英文习惯命名的类/方法可能就重名了，这种错误极难排查。

引用

2. Ruby(或者说动态语言)的重构问题。Martin Flower对重构的定义是: “Each transformation (called a ‘refactoring’) does little, but a sequence of transformations can produce a significant restructuring.” 虽然每次重构都是很小的变化，但是这种变化的传播范围在一个复杂系统中可能变得很大。比如在核心模块中rename一个函数，其影响可能遍及其他所有模块。而这个恰恰是目前动态语言欠缺的。它也没有强大的IDE来支持各种重构操作。所以现实情况就是我们利用文本的查找替换来完成重构操作。另外一方面，我们可以认识到一个好的框架(无论是建立在Ruby还是RoR上)来应对系统的复杂性还是有一定的必要性的。如果框架好，可以做到削弱依赖关系或者化整为零，那么重构带来的成本也会减少。

如果你写的代码有那么复杂，以致于不能很好的支持重构，你要首先考虑你的代码写的是否有问题了。在RoR框架下面，基本写不出来依赖关系复杂的代码。

引用

3. 代码在膨胀！系统代码不断的变得臃肿，里面充斥着有用的代码和无用的代码。当然这可以看作是前面两者综合的结果 — 因为是动态解释的，而在重构结束的时候，有时候很难判定某个方法是否还存在引用。在大多数情况下不会追究下去，所以系统代码不断地在扩大，这种性质的扩大也增加了系统的额外复杂性。

你不觉得Java代码膨胀的更严重吗？即使有IDE的跟踪功能，难到你能很好的管理所有有用无用的代码？你可以肯定某些代码一定是无用的？

2 楼 yananay 2007-04-29  

引用

很重要的一点是，使用RoR你需要写的代码更少。

少是相对的，但是当某一个复杂的逻辑达到千行，就很痛苦了。。。

不过这不是ruby的问题，就算java，也一样痛苦。

1 楼 gigix 2007-04-29  

根据我的经验，你列举的三个点都是不成立的。很重要的一点是，使用RoR你需要写的代码更少。

引用

1. Ruby 动态解释和mixin的继承方式使得寻找bug的过程变得异常艰难。

convention over configuration让你知道应该去什么地方去寻找什么东西。单元测试、功能测试和集成测试让你迅速定位到bug所在的位置。并且在更少的代码中寻找bug总是更加容易。

引用

2. Ruby(或者说动态语言)的重构问题。

缺乏IDE支持是事实。另一方面的事实是，代码越少重构越容易。

引用

3. 代码在膨胀

同样，越少的代码越容易维护。

我认为你的几个点都有一个共同的出发点，即缺乏编译期检查。但程序的可靠性本来就应该由测试（而非编译期检查）来确保。