.NET程式員學習Ruby on Rails的理由

你是一位資深的.NET程式員，而且已經用ASP.NET構建過許多Web應用。

無數個不眠之夜，為了讓ASP.NET控制項生命週期中的事件驅動模型按你想要的方式執行，你費盡心血，深入細節。

你精通於使用諸如Presentation Model、Model View Presenter這類設計模式對你的應用進行分層，以使其更易測試和維護。

你認為Ruby on Rails只不過是眾多被吹噓的技術中的一員。在它還沒有獲得可觀的市場份額之前，你不會給予它過多的關注。

歡迎來到我的世界。如果你還在讀這篇文章，我向你致敬。對於我下面的說法，你可能會充滿了好奇。為什麼我——一名資深的.NET程式員，在經曆了一個月的Ruby on Rails學習後會認為：只有在我瞭解了Ruby on Rails之後，才能以較少的時間和編碼完成以前開發過的許多應用？

老實說，我仍然認為.NET很棒。它為我提供了一個平台，能讓我向客戶源源不斷地提供巨大的商業價值。但我時刻提醒自己：一個簡單的問題，有大量不同的方法和技術可以解決它，並且總有一些比其它更好。衷情於某種技術，必然會產生一些無意識的偏見，這最終會阻礙我為客戶供應商業價值的能力。例如，對像Ruby這樣的動態指令碼語言的瞭解，使我以為：與使用編譯型的語言相比，我可以花費更少的時間去編寫簡單的自動處理的Batch/Shell指令碼。

為什麼不呢？

下面這幾件事，是我（一個.NET程式員）學習Ruby時，發現的一些典型的不同。希望你能喜歡。

不需要編譯Ruby中沒有編譯的概念。一切都在運行時發生作用。有人認為代碼編譯可以防止編碼時的粗心。那麼，你可能應該去看一下測試驅動開發是怎麼工作的，連續的代碼整合（當然了，不是每天都要構建），單元測試（不涉及資料庫和web服務的測試）和依賴注入可以協助你產生品質良好的代碼，使你能夠充滿自信的靈活的改變你的代碼。編譯的保障作用一下子變的不那麼重要了。

動態增加類的行為——不使用Decorator模式在靜態類型語言中，要想動態增加類的行為，我們可以使用Decorator模式或者模板方法。而在Ruby中，有更多的方法可以在不複雜化對象設計結構的情況下，很簡單地做到這一點。這隻是因為語言本身對它的支援，例如：將模組作為minxin使用，使用class_eval, instance_eval方法等。事實上，甚至可以通過編程方式在運行時定義類的方法。在靜態類型語言中，也可以通過代碼產生來完成它。但瞭解更多的方法，可以讓你向一個優秀的問題解決者邁進一步。

（譯者註：mixin在物件導向程式設計語言中是一種提供某些功能給子類繼承的類，但mixin並不能執行個體化。從某個mixin繼承並不是什麼特殊的形式，而它更適於收集功能。某個子類甚至可以通過繼承一個或者多個mixin選擇繼承它的全部或者多數功能。一個mixin能延期到運行時定義和Binder 方法，而屬性和執行個體參數也可在編譯時間才被定義。這不同於我們常見的方式，比如先定義所有的屬性、方法，並在編譯時間進行初始化等。）