ruby on rails最大優勢是什麼

標籤：程式設計語言   朋友   日本   開發   技能   

Ruby程式設計語言是由日本人松本行弘開發，是一種簡單快捷的物件導向程式設計語言，今天主要跟大家聊聊ruby架構——ruby on rails（http://www.maiziedu.com/course/ruby/），可能有些朋友不喜歡ruby，但是作為一門語言，我覺得 Ruby 還是很值得掌握和學習的。

先說說學好 Ruby 有什麼好處吧。

Ruby on Rails 的最大優勢我覺得有四個：

1. 語言靈巧輕便，適合快速開發和部署。

2. 各種本身內建的 “magic” 以及可以通過 gem 或者 vendor code 載入的 magic。讓代碼美觀簡潔。

3. 很容易與各種前端 JS 框架組成（包括Backbone，Ember，React等等）

4. 有一個 Rails console 可以讓 test 和 debug 變得異常輕鬆。

如果你不相信我說的話，可以去各個中小公司走走看看，很大一部分最原始的第一個程式碼程式庫都是基於 Ruby on Rails 的。儘管後期會有各種拆分和重寫，對原來的 Ruby 代碼能夠很好的把握也是一項極為重要的技能。我早年是寫 C++ 和 Python 的，最近三年多，卻是有百分之六七十的時間寫的是 Ruby，偶爾寫寫 Java 和 Scala，但是 Ruby 依然是我寫的最順手的語言，沒有之一。因為 Square 和 Airbnb 兩家公司 Ruby 都用的很多，所以對 Ruby 熟練也成為我在工作上的一個小小的優勢。

雖然很喜歡 Ruby，但是卻除了上面四點不想寫太多廢話來解釋 Ruby 為什麼好。不如說點有用的，瞭解並如何儘可能的避免 Ruby on Rails 裡面的坑。

Ruby on Rails 最大的問題可能就是這個語言寫代碼開發起來快，維護起來卻很困難。什麼原因呢？怎麼避免呢？

首先，Ruby 是動態類型的。什麼意思大家都懂，就是一個變數沒有型別宣告，run time 的時候給它什麼值它就是什麼類型。語言的官方說法叫做 duck typing：

“ 如果一個對象和鴨子一樣走路一樣說話，那麼Ruby就很欣然地認為這就是一隻鴨子。”

沒有類型申明的代碼寫起來簡潔方便，尤其是不同對象間有可繼承重用的關係的時候，如果換了 Java 這樣的強型別語言就必須使用 interface 或者 abstracted class 來嚴格按照 design pattern 來處理。而在 Ruby 裡面，你只要心中想要給一個變數什麼值，那麼只要後面賦值正確，這個變數就可以有什麼值。這就必然引來兩個麻煩：

1. 不小心賦錯值，Ruby 依然將計就計，也不抱怨。只不過在實際運行中讓你找不著北，得到一個完全出乎意料的結果。

2. 需要 refactor 代碼，也就是代碼重構的時候。這幾乎可以說是一場災難。試想下你有一百把鑰匙一百把鎖，有類型申明的語言可能對於不同型號的鑰匙和鎖有所區分，而無類型申 明的語言所有的鑰匙和鎖幾乎都長的一樣。代碼重構就好像把所有配對打亂，又要以新的形式組合。最後結果就是看著重構後利索無比的新代碼，一不小心就給你 exception 了。

一個很有效解決辦法是，對一些重要的，尤其是 API 的參數類型進行強制類型檢查和斷言。比如在 Airbnb，我們會用一個 validation gem 對所有需要的變數去用代碼來檢測其類型，類似於 “validate count is_a Integer” 這樣的斷言。

第二，很多人對 Ruby on Rails 的 ActiveRecord 一知半解。ActiveRecord 可能是 Rails 裡最強大的 magic 之一（或者沒有之一）了。ActiveRecord 是對代碼中資料庫訪問和商務邏輯訪問的一個混合體。如果寫的好，可以事半功倍，寫出 DB 訪問效率高且乾淨利落的資料庫訪問相關的代碼，比如它的 scope 和 association 的運用。然而，如果對於 ActiveRecord 怎麼實現似懂非懂，加上對 MySQL 的 execution plan 一知半解，很可能寫出的代碼一到 production 就會各種崩潰。舉三個常見的例子：

1. 老實說，我覺得不知道 N+1 Query 是啥的程式員都應該好好去瞭解下。N+1 Query 幾乎是我見過的引發 production 問題的最常見的錯誤之一（也許沒有之一）了。

2. Rails 的association。最便利的 wrap 對象間 1對1、1對多、多對多等關聯的 magic。很多別的語言應該都沒有這個概念。Rails 的官方文檔上有，強烈推薦深入瞭解。這也是平常見到的被錯用最多的 magic 之一了。

3. Rails 中的一些 job 需要在資料庫中找到滿足某些條件的 records 並進行處理。Rails 常用的有 find、find each、find in batch 等等，雖然不一樣的查詢語句都能給你一樣的結果，但是因著他們對應的 SQL 語句的轉化不一樣，很多的時候效率天差地別。這也是 Ruby 代碼中可以看出一個程式員對 Rails 的瞭解的一個常見的點。

例子還很多，坐下來可以慢慢寫，這裡也只是順手寫幾個最先想到的。所以我們也不用一邊寫著低效的 Ruby 代碼一邊罵 Ruby 這不好那不好了。我琢磨 Ruby 可能覺得更怨。

第三，因著 Rails 中這樣那樣的 magic，寫好 Ruby 的 RSpec 測試例可能是一件比寫好 Ruby 代碼還難的事了。寫好 RSpec 其實有很多的技巧，最常用的：

1. 各種 stubbing，包括對 FactoryGirl 和 Fixture 等的應用，好的 Rspec 其實可以協助避免很多 Rails 裡面的坑。怎麼寫好 Rspec，這個也不是一篇能說清的，有興趣的可以留言，以後我如果有好的資料可以分享給大家。

2. 這一條也適用於所有的程式語言的測試例的編寫。是自上而下還是自下而上，怎麼保證覆蓋率，先寫代碼還是先寫 test，很多好書。別的語言的寫 test 的思想到這裡也是適用的。

老實說我學寫 RSpec 可能當初花的時間和寫 Rails 代碼本身花的時間一樣多。即使是現在，我也不敢說我能把 RSpec 寫到很好，只能說我願意花時間精力努力把 spec 寫好罷了。

第四，Rails 本身已經是一門文法極其精鍊的語言了，沒有必要為了把代碼變得更緊湊而使用一些很炫的偏僻的文法。記得我剛開始寫 Ruby 的時候，喜歡乾的一件事就是把整個函數我用一行 Ruby 各種技巧就寫出來了。然後呢？不僅可讀性差，有的時候時間長了，自己都忘了是怎麼玩的了。後來越寫越老實，怎麼容易懂就怎麼寫。有一個寫程式的原則我覺得 實用所有的語言：好的程式是不應該需要太多注釋的。這包括結構的清晰和最合適的命名。這個原則對 Ruby 尤其重要，因為 Rails 本身已經各種 magic，很容易把代碼寫的出神入化，然後可讀性極差。尤其是即使如 RubyMine 這樣的 IDE 在跳轉到函數定義或函數應用的這一功能上也不可能做到準確，因此可讀性差的代碼幾乎註定早晚就成了個坑。所以當你寫了一段 Ruby 代碼你覺得有必要加一段注釋來說明你想幹什麼的時候，可能應該先想想是不是應該重寫這一段代碼了。

其實還有第五第六第七……， 因為一門語言可以聊的東西太多了。記得以前 Square 的時候每周都有 Rails 的專門的研討班，每周聊都聊不完，何況一篇文章？Square 兩年於我最大的收穫也是學會寫 Ruby，記得我還曾半開玩笑的和朋友說過：“工作做的越久，越是什麼技能都不敢往簡曆上寫了，因為不斷見到真的牛人。以後我找工作，簡曆上唯寫我會寫一 點 Ruby 代碼吧。” 因為很喜歡 Ruby，我的號都取了在 Mac 上寫 Ruby 代碼的含義。當然，Java 和 Scala 我也很喜歡。

ruby on rails最大優勢是什麼