常見的5個Rails開發誤區

這篇文章主要介紹“常見的5個Rails開發誤區”，在日常操作中，相信很多人在常見的5個Rails開發誤區問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”常見的5個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。團隊會審查你的代碼，并且給出一些你沒有考慮到的改進或者***特性的建議。

到此，關于“常見的5個Rails開發誤區”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！