我從似乎因爲更長的時間才能與軌工作的人有時會看，他們學會了將一個重要的教訓：「不要使用腳手架」。同樣在irc上，我從這個方向讀到了一些常見的提示。 我的問題是爲什麼，它有什麼壞處？並且nifty_scaffolding也不好？爲什麼Ruby on Rails專業人員不使用腳手架？
我的猜測是它是壞的，因爲它默認生成了一個xml版本的控制器動作，它會暴露我們應用程序的字段名稱給任何人，並使它更容易受到攻擊，所以也許是這樣？
你有什麼理由不這樣做腳手架？
我經歷了軌道，我很少用的腳手架，只是因爲我的最終目標是遠非如此簡單CRUD操作。但是，沒有嚴格的規定不使用腳手架。有些程序員它皺眉，因爲它實際上是腳手架，從字面上。這不是一個成品。 腳手架在您構建實際產品時爲您提供支持。搜索谷歌圖片的「腳手架」，你應該明白了。
請記住scaffold只是許多內置的generators in Rails之一。 Rails生成器只是一個輸出一些通用代碼的腳本。發電機是非常有用的節省時間的，你很快就會發現你自己的定製需求writing generators。
腳手架是不是真的意味着生產使用。它意味着快速引導應用程序，然後可以修改或刪除它。
Rails的腳手架3實際上是相當不錯的，但它仍然缺少一些東西喜歡的方式來處理嵌套的資源，它不使用簡單的respond_with（超過respond_to，鼓勵在不需要它的冗長或歡迎）。
默認的腳手架表單不可能未修改地工作 - 您的模型之間可能存在翻譯成數據庫中某列的關係，如user_id。在創建具有關係的模型的腳手架時，此列顯示爲表單中的文本字段，當清楚地顯示它應該從URL推斷或通過另一個更方便用戶的界面選擇時。
有很多的小細節像這樣，使腳手架生產準備出的現成的代碼確實不太可能的候選人。當然，您可以通過生成腳手架來填充應用程序，然後填補空白並清理不需要的區域，我懷疑大多數Rails開發人員會在某種程度上這樣做。
我不使用腳手架，原因有二：
您的xml問題不是人們建議不要使用腳手架的原因。我不打擾我的頁面的XML版本，因爲它使您的應用程序必須生成的路線數量加倍，這反過來又增加了一些開銷...
當您學習導軌時，使用PS腳架搭配腳手架，這很有用，因爲它可以減少您需要知道的材料數量，並幫助您更快速地啓動應用程序。一旦你知道你在做什麼，你自然會停止運行發電機。 – stephenmurdoch
輸出格式在控制器中以小代碼處理。 JSON和XML由Rails本地支持，所以你甚至不需要視圖。你的路由根本不會改變格式（運行'rake routes'，並在每條路由的末尾看到隱含的'（。：format）'。 – coreyward
是的，我只使用nifty_scaffolding，因爲它似乎更精確並留下了很多不必要的代碼，並在我看來提高了安全性。 – tmaximini
我相信大多數專業人士都避免使用腳手架，因爲他們更喜歡測試驅動的開發方法來編寫生產代碼。這意味着他們想要先編寫一個失敗的測試，然後編寫使測試通過的代碼。這是生成強代碼的好方法，但它在最精細的層面上效果最佳。腳手架似乎一次做得太多，所以它會破壞一個編寫特定功能失敗測試的緊密循環，然後編寫使該特定功能通過的代碼。在腳手架的易用性之外，進入這種習慣可能更重要。
這表示腳手架本身可以非常強大。
我認爲腳手架是很好的檢查新的rails版本的新東西（例如現在在rails 4 params允許控制器中的東西）。您可以使用它進行快速原型設計。 往往是簡單的沒有必要產生一個完整的骨架..
人們迄今還表示，有經驗的軌道程序員不使用腳手架，並有很好的理由爲主。我主張初學者不要使用腳手架。
你可能一直在用腳手架開心地工作一段時間，然後你意識到你忘了在你的Post模型中包含published布爾型字段，所以你生成一個遷移以將該屬性添加到表格中（你'已經設法解決這個問題）。然後，你還必須弄清楚如何將其添加到腳手架生成的表單中。 然後對於你的生活你無法弄清楚爲什麼它不會在你提交表單的時候更新，在經過很多衝突和浪費時間之後，你會發現你沒有允許對像腳手架這樣的屬性進行大規模分配其他。原來你並不知道Rails是如何工作的。
如果您正在學習Rails，那麼如果您自己構建了V和C的話，您將會對MVC有更多的瞭解。
「原來你並不知道Rails是如何工作的」，它釘住了它。 – suzumakes
瞭解使用鋼軌生成腳手架並瞭解其侷限性非常重要。腳手架幫助你快速運行並測試假設。但在現實世界中，它不會讓你走得太遠。可以說你用腳手架創建了一個模型
rails generate scaffold Article title:string body:text
太棒了！你現在準備好了一個原型。但現在可以說，你必須添加另一個字段「作者」。
rails generate migration add_to_article_author author:string
rake db:migrate
現在該表的文章有一個新列，但在/ app /視圖/文章的文件都在同老態，即形式不會有作者字段等，如果您再次運行腳手架
rails generate scaffold Article title:string author:string body:text --skip-migration
這次你添加了--skip-migrate，因爲之前已經完成了，而且如果你要再次遷移同一個表，Rails將會真的抱怨。現在腳手架會提示你覆蓋它第一次創建的文件。覆蓋也會破壞您對控制器/app/controllers/article_controller.rb所做的任何更改或查看諸如/app/views/article/show.html.erb或index.html.erb的文件
由於任何有價值的Rails應用程序有自定義代碼（而不是由腳手架創建的樣板代碼）Rails程序員應該只使用腳手架來測試一個想法。使用腳手架爲您的客戶提供一些配合。但是在現實世界中，不使用樣板腳手架代碼。
我已經養育了所有的答案，但是我沒有足夠的理由在決定使用它時提出「不要使用腳手架」幾個建議。 – alex