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