本文作者是一名Rails開發者，他總結了在Rails開發過程中的一些常見誤區。
文章內容如下：
我使用Rails已經有一段時間了，在這期間我看了大量的Rails項目，下面的這五個常見的誤區，我幾乎在每一個Rails代碼中都看到過。
1、沒有 schema 規范的遷移
數據模型是應用程序的核心。沒有schema的約束，你的數據會因為項目代碼上的bugs而慢慢變得糟糕，直到你無法相信庫中的任何字段。這里有一個 Concact Schema：
- create_table "contacts" do |t|
- t.integer "user_id"
- t.string "name"
- t.string "phone"
- t.string "email"
- end
|
上面哪些需要更改呢？通常一個Contact必須依附于User，并且會有一個name 屬性，這可以使用數據庫約束來確保。可以添加“:null => false”，這樣即使驗證代碼存在bugs，我們依然可以確保模型一致性，因為如果違反了null約束，數據庫并不會允許模型保存這些數據。
- create_table "contacts" do |t|
- t.integer "user_id", :null => false
- t.string "name", :null => false
- t.string "phone"
- t.string "email"
- end
|
TIPS：使用“:limit => N”規范你的string類型字段的大小。Strings 默認255個字符，而phone字段應該不需要這么長吧！
2、面向對象編程
大多數Rails開發人員并不寫面向對象的代碼。他們通常會在項目中寫面向MVC的Ruby代碼（把模型和控制器分開寫在合適的位置）。通常是在lib目錄下添加帶有類方法的工具模塊，僅此而已。但開發人員往往需要花費2-3年才能認識到“Rails就是Ruby。我完全可以創建一些簡單的對象，并且不一定按照Rails建議的方式去封裝它們。”
TIPS：對你調用的第三方服務使用facade（外觀模式）。通過在測試中提供mock facade，你就不用在你的測試集中真的去調用這些第三方服務了。
3、在 helpers中連接HTML
如果你正在創建helper，恭喜，至少說明你正在試圖讓你的視圖層更整潔。但是開發人員經常不知道一些使用helpers創建標簽的常見方式，這就導致了槽糕的字符串連接或者糟糕的插值形式。
- str = "<li class='vehicle_list'> "
- str += link_to("#{vehicle.title.upcase} Sale", show_all_styles_path(vehicle.id, vehicle.url_title))
- str += " </li>"
- str.html_safe
|
看吧，相當糟糕，而且容易導致XSS安全漏洞！讓content_tag來拯救這些代碼吧。
- content_tag :li, :class => 'vehicle_list' do
- link_to("#{vehicle.title.upcase} Sale", show_all_styles_path(vehicle.id, vehicle.url_title))
- end
|
TIPS：現在就開始在helper中使用blocks（代碼塊）吧。當產生內嵌的HTML時，嵌入的blocks更自然、更貼切。
4、Giant Queries（大查詢，比如載入整張表的查詢）會把一切都加載到內存
如果你需要修正數據，你只需要遍歷并且修正它，對嗎？
- User.has_purchased(true).each do |customer|
- customer.grant_role(:customer)
- end
|
假設你有個百萬級別客戶的電商網站，假設每個用戶對象需要500字節，上面的代碼會在運行的時候消耗500M內存。
下面是更好的方式：
- User.has_purchased(true).find_each do |customer|
- customer.grant_role(:customer)
- end
|
find_each使用 find_in_batches 每次取出1000條記錄，非常有效的降低了對內存的需求。
TIPS：使用 update_all 或者原始 SQL 語句執行大的更新操作。學習SQL可能需要花費點時間，不過帶來的好處是明顯的：你會看到100x的性能改善。
5、代碼審查
我猜你會使用GitHub，并且我進一步猜測你不會去pull requests（GitHub上的申請代碼合并操作）。如果你需要花費一到兩天去構建一個新特性，那么到一個分支上去做吧，然后發送一個 pull request。團隊會審查你的代碼，并且給出一些你沒有考慮到的改進或者最新特性的建議。我保證這樣會提高你的代碼質量。我們在TheClymb項目中 90%的改動都是通過這種方式完成的，并且這是100%值得去做的一個經驗。
TIPS：不要沒有經過任何測試就合并你的pull request。測試對保證應用的穩定性非常有價值，并且可以讓你踏實地睡一個好覺。