5個常見的Rails開發(fā)誤區(qū)
本文作者是一名Rails開發(fā)者，他總結了在Rails開發(fā)過程中的一些常見誤區(qū)。文章內(nèi)容如下：
我使用Rails已經(jīng)有一段時間了，在這期間我看了大量的Rails項目，下面的這五個常見的誤區(qū)，我?guī)缀踉诿恳粋€Rails代碼中都看到過。
1. 沒有 schema 規(guī)范的遷移
數(shù)據(jù)模型是應用程序的核心。沒有schema的約束，你的數(shù)據(jù)會因為項目代碼上的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 屬性，這可以使用數(shù)據(jù)庫約束來確保?？梢蕴砑?ldquo;:null => false”，這樣即使驗證代碼存在bugs，我們依然可以確保模型一致性，因為如果違反了null約束，數(shù)據(jù)庫并不會允許模型保存這些數(shù)據(jù)。
- 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”規(guī)范你的string類型字段的大小。Strings 默認255個字符，而phone字段應該不需要這么長吧！
2. 面向對象編程
大多數(shù)Rails開發(fā)人員并不寫面向對象的代碼。他們通常會在項目中寫面向MVC的Ruby代碼（把模型和控制器分開寫在合適的位置）。通常是在lib目錄下添加帶有類方法的工具模塊，僅此而已。但開發(fā)人員往往需要花費2-3年才能認識到“Rails就是Ruby。我完全可以創(chuàng)建一些簡單的對象，并且不一定按照Rails建議的方式去封裝它們。”
TIPS：對你調(diào)用的第三方服務使用facade（外觀模式）。通過在測試中提供mock facade，你就不用在你的測試集中真的去調(diào)用這些第三方服務了。
3. 在 helpers中連接HTML
如果你正在創(chuàng)建helper，恭喜，至少說明你正在試圖讓你的視圖層更整潔。但是開發(fā)人員經(jīng)常不知道一些使用helpers創(chuàng)建標簽的常見方式，這就導致了槽糕的字符串連接或者糟糕的插值形式。
- 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：現(xiàn)在就開始在helper中使用blocks（代碼塊）吧。當產(chǎn)生內(nèi)嵌的HTML時，嵌入的blocks更自然、更貼切。
4. Giant Queries（大查詢，比如載入整張表的查詢）會把一切都加載到內(nèi)存
如果你需要修正數(shù)據(jù)，你只需要遍歷并且修正它，對嗎？
- User.has_purchased(true).each do |customer|
- customer.grant_role(:customer)
- end
假設你有個***別客戶的電商網(wǎng)站，假設每個用戶對象需要500字節(jié)，上面的代碼會在運行的時候消耗500M內(nèi)存。
下面是更好的方式：
- User.has_purchased(true).find_each do |customer|
- customer.grant_role(:customer)
- end
find_each使用 find_in_batches 每次取出1000條記錄，非常有效的降低了對內(nèi)存的需求。
TIPS：使用 update_all 或者原始 SQL 語句執(zhí)行大的更新操作。學習SQL可能需要花費點時間，不過帶來的好處是明顯的：你會看到100x的性能改善。
5. 代碼審查
我猜你會使用GitHub，并且我進一步猜測你不會去pull requests（GitHub上的申請代碼合并操作）。如果你需要花費一到兩天去構建一個新特性，那么到一個分支上去做吧，然后發(fā)送一個 pull request。團隊會審查你的代碼，并且給出一些你沒有考慮到的改進或者***特性的建議。我保證這樣會提高你的代碼質量。我們在TheClymb項目中90%的改動都是通過這種方式完成的，并且這是100%值得去做的一個經(jīng)驗。
TIPS：不要沒有經(jīng)過任何測試就合并你的pull request。測試對保證應用的穩(wěn)定性非常有價值，并且可以讓你踏實地睡一個好覺。
英文原文：Five Common Rails Mistakes
原文鏈接：http://www.iteye.com/news/25074
【編輯推薦】
