我在Ruby on Rails上发生了什么（如果有的话）技术债务？

Question

我是ruby on rails的忠实粉丝，它似乎融入了许多Web应用程序编程技术的“最佳点击”。特别是关于配置的约定对我来说是一个很大的胜利。

但是我也觉得我所获得的一些便利是以牺牲technical debt为代价而需要在路上偿还的。并不是我认为ROR是快速而肮脏的，因为我认为它在许多情况下包含了许多最佳实践和良好的默认选项。但是，在我看来，它还没有涵盖一些东西（特别是在框架中几乎没有对安全性的直接支持，而且我看到的插件质量也各不相同）。

我不是在这里寻找宗教观点或火焰战争，但我有兴趣了解社区对Rails需要改进的领域的看法，和/或Rails用户需要注意的事项。拥有，因为框架不会牵着他们的手，引导他们做正确的事。

Answer 1

无论框架如何，程序员都需要知道她在做什么。我要说使用像Ruby on Rails这样成熟，设计良好且广泛适应的东西来构建一个安全的Web应用程序要容易得多，而不是没有框架支持。

小心使用插件并了解它们的工作原理（再次知道你做了什么）。

Answer 2

我也喜欢Rails，但对我们理解我们使用的框架的缺点非常重要。虽然解决这些问题可能是一个广泛的主题，但不会伤害任何人。

除安全问题外，另一个重要问题是共享主机上的部署。 PHP在共享托管环境中蓬勃发展，但Rails仍然落后。

当然，大多数专业的Rails开发人员都知道他们的应用程序需要经过精心调整的服务器才能进行生产，而且他们显然会部署在特定于Rails的主机上。

为了让Rails继续成功，核心团队应该解决这个问题，尤其是Rails 3.0（Merb + Rails）即将来临......

这方面的一个例子很简单：我有一个bluehost帐户，我注意到我的cpanel中的Rails图标。我谈到了bluehost支持，他们说它或多或少是一个虚拟图标，并且它无法正常运行。

说过任何想要部署Rails App的专业人士都不会使用bluehost。但它确实伤害了Rails，当主机说他们支持它然后用户遇到他们的支持一无所知的问题..

Answer 3

您所指的文章将技术债务定义为

  

最终的后果   slapdash软件架构和   仓促的软件开发

对于rails，任何非测试驱动的开发都会产生技术债务。但任何平台都是如此。

在架构级别，Rails提供了一些部署挑战。繁忙的站点必须使用大量硬件进行扩展或使用智能缓存策略。

我对任何适应Rails的人的建议是：

• 使用TDD进行所有开发
• 验证任何插件的质量 你通过阅读它的测试来使用。如果 它们不清晰完整， 避免使用插件
• 读“Rails 食谱“和”高级Rails 食谱“（高级Rails食谱有 添加的好方法 以RESTful方式进行身份验证）
• 准备支付硬件以扩展您的网站（硬件比开发时间便宜）

Answer 4

根据我的经验，到目前为止，你最终用RoR支付的最大收费是：

• 非常大的默认堆栈（不包括您可能正在使用的插件）
• 至少在生产服务器中，更新模型往往是一种痛苦。
• 更新Rails或Ruby本身比它应该更复杂，但这取决于您的服务器设置。
• 正如ewalshe所提到的那样，部署有时是一种拖累，如果你需要它，你可以进一步扩展，扩展会有所不同，就像大多数开发框架一样。

话虽如此，对于某些项目，我是RoR的狂热用户，并且考虑到硬件的实际状态，即使你最终支付了一些技术债务来使用它，它几乎可以忽略不计。人们可以希望最终能够对这些问题进行审查并解决。

Answer 5

任何级别的抽象都会让你付出一点代价 - 泛化方法并不像专门为你的目的而构建的方法那么快。幸运的是，它可以让你改变。不喜欢动态查找方法出来的查询计划吗？写自己的，好好去。

上面的人说得好 - 硬件比开发者便宜。我会添加“足够少的硬件”

Answer 6

我正在阅读Deploying Rails Applications并高度推荐，以回答您的疑虑。

本书充满了让生活更轻松的建议，从头开始对Rails开发采用部署感知方法，而不是将其留待以后使用。

我不认为RoR的选择意味着技术债务，但只是阅读前几章提醒我应该遵循的做法，特别是在共享主机上，例如冻结核心轨道宝石所以你不能被主机上的升级打乱。

共享主机的30页章节包括内存引用提示，例如使用多个帐户（如果可能），每个帐户使用一个Rails应用程序。它还警告像RMagick这样的流行库可能会将你的内存大小推到你的进程被杀死的程度（例如100MB限制，这表明一些主机会定期应用）。