【IT168 独家分析】在过去几年中，开源Web开发框架Ruby on Rails在Web世界中掀起一个小小的热潮。和软件领域中的许多事情一样，它的作用有些被夸大了。

    没有什么东西能和人们对它宣传的一样神奇。但是Rails至少已经接近了这种高度，因此它同样值得我们对其进行研究。 

    不久以前，人们在问Rails是否会获得成功。我现在还保持当时对这个问题的看法。事实上，它已经取得了成功。那么我们现在或许会问：它为什么会取得成功？

源于真实世界的需要 

    Ruby on Rails在2004年发布了它的第一个公众版。现在它已经不是一个蹒跚学步的孩子。在2005年，David Heinemeier Hansson因为这个软件程序获得了“年度非常好的黑客”奖项。在2006年，Rails赢得了2006年度Jolt大奖的非常好的Web开发工具。Ruby on Rails和它的作者何以能获得如此殊荣？ 

    我在这儿要指出的是Ruby和Ruby on Rails不是同一件事物。当然老手们都知道这一点，不过一些新手朋友或许对此还比较模糊。Ruby本身是一种语言，和Perl或Python类似，其早在1993年就开始出现。而Ruby on Rails则是一个使用Ruby语言编写的Web框架，大约在2003年开始出现。 

    Rails所掌握的第一件秘密武器就是，它来源于真实世界中的应用程序。Rails并不是最初的目标产物，当时是为了开发一个叫做Basecamp的Web应用程序。在Hasson和其他人开发这个应用程序的时候，他们多次发现，Web开发是一件令人痛苦的事情，而且耗时、具有反复性和注重细节。这给了Ruby on Rails一个诞生的机会。 

    在编写这个高度浓缩的Ruby编码的过程中，Hansson开始从界面的本质进行提炼，于是就诞生了Ruby on Rails。因此说它源于真实世界的需求，源于使用中的代码，源于开发者的每日体验。 

    Rails还受益于我所说的“二次编写”的原则。在创建一个系统的过程中，尤其是一个大型系统中，开发者学习到一些新的信息，发现了一些未曾预见的问题。每一个有经验的开发者有时候会想，“如果让我再次编写这个系统的代码，我可能会做的更好。”重写的代码往往更清晰、更简洁和更完善。它不仅仅是在技术上的改善，还包括更易维护、更易扩展和更强大，有时候甚至运行的更快。“编写、丢弃、再编写”的手法是一个令人难以置信的强大工具，但是因为时间和成本的考虑，它却很少被人们所使用。但是在Rails上的确应用了这种原则：它首先被作为一个应用程序的“内脏”被编写，然后被重新编写，进行抽象化以使其可以被任何Web应用程序所使用。 

    在Rails的成长过程中，它在代码中也积累了很多不好的地方。和清扫房间一样，软件维护也是一个永无止境的过程。但是由于它实际上是一个二次编写得出的系统，当Rails最终公开发布的时候，它已经比原来显得更简洁更完善了。 

    而且，我已经提到过Rails是开源的。这是一个重要的因素。Ruby on Rails可以被任何使用它或喜欢它的人来进行维护。他们可以根据自己的需要来增加功能，这是一个人人可参与的“草根”产品。

包罗万象的哲学体系

    Rails的下一个成功之处在于它使用了正确的工具来完成任务。对一个Web开发者来说，一个Web框架本身就是一个工具；but I'm talking about one step higher up the food chain.对于创建一个新的Web框架的人来说，这个框架是一个应用程序，他本身必须从头做起来编写。我们应该使用什么语言：Perl、Java、C++，还是其他的什么呢？Ruby是一个选择。

    Hansson希望让Web开发更简单一些，少一点痛苦，少犯些错误和更快速一些。他选择了Ruby作为他的开发语言。Ruby是一个非常高级的语言，可以节约开发者的时间和精力；它是一个解释性语言，可以将编译和创建大型系统中出现的问题降到最低；它是一门动态语言，可以在运行的时候调整和配置自身；在一个熟练的用户手中它极具扩展性。尽管Ruby有自己的缺点，主要是在性能和速度方面，它仍然不失为用来创建一个软件系统的强大平台。Rails使得Ruby更加普及，而Ruby则使得Rails成为可能。

    Hansson做对的第二件事是选择了一个包罗万象的体系结构，这是他一直坚持的东西，他精心选择了一系列设计原则，并且坚定的去遵守它。这些思想已经存在了很长时间，但是从来没有人去如此好的运用它们。

   这些设计规则中的一个就是来自于Dave Thomas的Pragmatic Programmer一书中的“DRY重用原则（Don't Repeat Yourself）”DRY原则意味着创建到应用程序中的信息和逻辑应该被局部化或隔离。它应该尽可能少的存储在更少地方，副本应该保持在绝对最低限度。这种原则有助于组织开发者的思路和保持好的开发速度，而且使得的代码可以被更轻松修改。这种更轻松的修改所带来的好处不仅仅体现着维护模式中，在最初的开发中同样也会体现出来。Ruby通过使编程更轻松，而鼓励这种行为。

    Hansson还一依靠另一个设计原则，他将其称为“惯例优先原则（convention over configuration.）”。这意味着这个框架的用户不用去做太多的设置工作，或者不用花费太多的时间来处理一些个别的组件。举个例子来说，Rails假定在代码中的类名称和数据库中的表名称之间存在关联。如果你坚持这个标准约定，你代码将显得更具有逻辑性和更平稳；否则，你将不得不做一些额外的工作。

    这个特点使得有些人将Rails称作“固执的软件”，这意味着它有自己的处理事务方式，程序员必须按照这个方式来编写一致的代码，否则就要编写更多的代码。在某些情况下，这使得Rails在与已有的数据库和表（以及一些外部应用程序）进行整合的时候存在一些困难。但是这些问题中的很多最近已经被解决，我们希望这种情况会继续改进。

    另一个Hansson做对的事情就是自己来开发它。和Ruby本身一样，Ruby on Rails最初是由Hansson一个人设计。当然，Rails是开源的，有很多开发者帮助对其扩展，这也是其强大的一部分原因。从一定程度上可以说，是Hasson一人创建二楼Ruby on Rails，我将此称为“一人负责”原则。

技术上的优势是不够的

    如果不提到市场，这篇文章将是不完整的。从历史中我们可以看到，一些技术领先的产品同样被市场所淘汰。技术、语言、产品都需要被在市场中进行良好的宣传，才能引起并保持用户对其的关注度。在这一方面，Hansson至少做了三件正确的事情。

    首先，他用虔诚的心去实现他的任务。他满怀热情的与销售人员打成一片。一个好的产品加上一个好的销售人员才是一个强大的组合；我们都知道，有时候一个好的销售员甚至可以卖出一个比较差的产品。

    其次，他选择了合适的用户群。他直接走向了开发者。他没有写文章，或者召开高层管理的研讨会。他实现了自己的想法，然后将他的成果直接介绍给在做相同工作的人。Rails采取了一个自下而上的方式，而不是通常所使用的自上而下的方式，这一定程度上保证它的普及性。

    第三点，Hansson采取了创新的市场策略。他使用视频来介绍Ruby on Rails，据特特别多好的效果。Hansson把视频不仅仅作为一个市场工具，而且成了一个教学工具。

    那么，我们从Rails的成功能学到什么呢？记住市场中那句老话“发现一个需要并且去满足它，”，而且要记住，单靠技术优势是很难推动一个技术或产品走向成功的。

    从Rails的成功中，我们可以学到很多东西。例如，不要总是重复自己，不要给用户施加负担，不要有太多人来进行设计
。对你的工作充满热情，在市场中要有创意。如果你把这些原则应用到你的项目中，那它们至少可以非常平稳的发展，甚至也会取得成功，当然成功还需要一点点运气。