Rails案例研究

　　业务问题

　　不论是 Ruby on Rails 框架还是任何 Java 框架都不能解决所有问题。为了提高成功的几率，需要长期、细致地考察业务问题，理解周围的各种假定情况，以及了解您的团队。只有这样才能选出正确的语言来进行开发。

　　去年，Arvato Systems 聘请我带领团队构建 ChangingThePresent.org，它是一种新平台，用于将非赢利性团体和捐赠人组织在一起。与很多 Internet 公司一样，我们向客户展示了可购买的实际产品。与其他公司不同的是，这些 “产品” 指的是提供机会，比如：一名癌症研究员一小时服务收费 50 美元、帮助盲人收费 30 美元，或者保护一英亩雨林一个月收费 20 美元。我们面临两大挑战：一份很紧凑的时间表和长期的复杂性。

　　开发工作从九月份开始，要求必须在十一月份之前建立起一个站点，以便有机会赶上圣诞节期间的通信量高峰。（最终我们超出了十一月份这个期限两星期。）在其他开发语言中，基于 Java 的解决方案可能要花费 6 到 18 个月才能完成这一任务。因此生产力是一个很重要的考虑因素，这与 Java 部署思想相悖。

　　通过对竞争对手和项目的考察，我们了解到：我们希望能够每天给站点带来几百万次点击的通信量。而我们需要每天有几十万次成功的点击，因此可伸缩性也是一个考虑因素。这与 Java 部署思想相符。

　　最后，我们了解到：发布初始站点只是一个开始。我们只实现了总体规划的百分之三。因此我们所选的技术需要根据复杂性和负载作出一些调整。我认为 Ruby 语言在复杂性方面会更易于调整，因为它提供了对更高级语言和特性（如开放类）的支持，以及具有更少配置需求和更简单、集成化编程模型的 Rails 框架。

　　虽然我们面临着时间和可伸缩性方面的挑战，但是也拥有一些其他的有利因素。我们拥有一张完全空白的候选名单：可以选择想要的任何技术、任何团队。可以定义项目、培训和全部的技术。我们可完全自由地作出选择。