5個常見的Rails開發(fā)誤區(qū)
我使用Rails已經(jīng)有一段時間了,在這期間我看了大量的Rails項目,下面的這五個常見的誤區(qū),我?guī)缀踉诿恳粋€Rails代碼中都看到過。
1、沒有 schema 規(guī)范的遷移
數(shù)據(jù)模型是應(yīng)用程序的核心。沒有schema的約束,你的數(shù)據(jù)會因為項目代碼上的bugs而慢慢變得糟糕,直到你無法相信庫中的任何字段。這里有一個 Concact Schema:
|
上面哪些需要更改呢?通常一個Contact必須依附于User,并且會有一個name 屬性,這可以使用數(shù)據(jù)庫約束來確保。可以添加“:null => false”,這樣即使驗證代碼存在bugs,我們依然可以確保模型一致性,因為如果違反了null約束,數(shù)據(jù)庫并不會允許模型保存這些數(shù)據(jù)。
|
TIPS:使用“:limit => N”規(guī)范你的string類型字段的大小。Strings 默認(rèn)255個字符,而phone字段應(yīng)該不需要這么長吧!
2、面向?qū)ο缶幊?/strong>
大多數(shù)Rails開發(fā)人員并不寫面向?qū)ο蟮拇a。他們通常會在項目中寫面向MVC的Ruby代碼(把模型和控制器分開寫在合適的位置)。通常是在lib目錄下添加帶有類方法的工具模塊,僅此而已。但開發(fā)人員往往需要花費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)致了槽糕的字符串連接或者糟糕的插值形式。
|
看吧,相當(dāng)糟糕,而且容易導(dǎo)致XSS安全漏洞!讓content_tag來拯救這些代碼吧。
|
TIPS:現(xiàn)在就開始在helper中使用blocks(代碼塊)吧。當(dāng)產(chǎn)生內(nèi)嵌的HTML時,嵌入的blocks更自然、更貼切。
4、Giant Queries(大查詢,比如載入整張表的查詢)會把一切都加載到內(nèi)存
如果你需要修正數(shù)據(jù),你只需要遍歷并且修正它,對嗎?
|
假設(shè)你有個百萬級別客戶的電商網(wǎng)站,假設(shè)每個用戶對象需要500字節(jié),上面的代碼會在運行的時候消耗500M內(nèi)存。
下面是更好的方式:
|
find_each使用 find_in_batches 每次取出1000條記錄,非常有效的降低了對內(nèi)存的需求。
TIPS:使用 update_all 或者原始 SQL 語句執(zhí)行大的更新操作。學(xué)習(xí)SQL可能需要花費點時間,不過帶來的好處是明顯的:你會看到100x的性能改善。
5、代碼審查
我猜你會使用GitHub,并且我進一步猜測你不會去pull requests(GitHub上的申請代碼合并操作)。如果你需要花費一到兩天去構(gòu)建一個新特性,那么到一個分支上去做吧,然后發(fā)送一個 pull request。團隊會審查你的代碼,并且給出一些你沒有考慮到的改進或者最新特性的建議。我保證這樣會提高你的代碼質(zhì)量。我們在TheClymb項目中 90%的改動都是通過這種方式完成的,并且這是100%值得去做的一個經(jīng)驗。
TIPS:不要沒有經(jīng)過任何測試就合并你的pull request。測試對保證應(yīng)用的穩(wěn)定性非常有價值,并且可以讓你踏實地睡一個好覺。