问为什么Ruby on Rails专业人员不使用脚手架？

EN

我相信大多数专业人士会避免脚手架，因为他们更喜欢测试驱动的开发方法，而不是编写生产代码。这意味着他们想要先编写一个失败的测试，然后再编写使测试通过的代码。这是生成强大代码的一种很好的方法，但它在非常细粒度的级别上效果最好。脚手架似乎一次做了太多的事情，因此它打乱了一个紧凑的循环，即为特定功能编写失败的测试，然后编写使该特定功能通过的代码。比起脚手架的易用性，养成这种习惯可能更重要。

也就是说，脚手架本身可能非常强大。

理解rails的使用、生成scaffold并意识到它的局限性是很重要的。脚手架可以帮助你快速运行一些东西并测试一个假设。但在现实世界中，它不会让你走得太远。假设您创建了一个带有脚手架的模型

rails generate scaffold Article title:string body:text

太棒了！现在您已经准备好了一个原型。但是现在假设您必须添加另一个字段"author“。

rails generate migration add_to_article_author author:string
rake db:migrate

现在，表文章有了一个新列，但是/app/views/ If中的文件处于相同的旧状态，即表单将不会有author字段，等等。

rails generate scaffold Article title:string author:string body:text --skip-migration

这一次您添加了--skip-migrate，因为以前已经这样做过了，如果您再次迁移同一个表，Rails将会发出真正的错误。现在scaffold将提示您覆盖它第一次创建的文件。覆盖还将销毁您对控制器/app/controllers/article_CONTROLER.rb或视图文件所做的任何更改，如/app/ views /article/show.html.erb或index.html.erb

由于任何有价值的Rails应用程序都有自定义代码(而不是由scaffold创建的样板代码)，所以Rails程序员应该只使用scaffold来测试某个想法。使用scaffold给你的客户一些玩耍的东西。但在现实世界中，样板脚手架代码是不使用的。

脚手架并不是真正用于生产的。它的目的是让应用程序快速启动，然后可以对其进行修改或删除。

Rails3搭建实际上相当不错，但它仍然缺乏一些东西，比如处理嵌套资源的方法，并且它没有使用更简单的respond_with (通过respond_to，这鼓励在不需要或不受欢迎的地方进行冗长)。

默认的脚手架表单不太可能在不修改的情况下工作，因为- you可能在模型之间存在关系，这些关系会转换为数据库中的列，比如user_id。当创建具有关系的模型的支架时，该列在表单中显示为文本字段，而它显然应该从URL中推断出来，或者通过另一个更用户友好的界面选择。

有许多这样的小细节使得脚手架不太可能成为开箱即用的生产代码的候选。当然，您可以通过生成scaffold，然后填充空白并清理不需要的区域来构建应用程序，我怀疑大多数Rails开发人员在某种程度上都是这样做的。