每年，我們都會被那些宣稱這個框架已死的文章所震撼。 儘管 Ruby on Rails (RoR) 已有 15 年多的歷史，但它離編程世界的傳承還差得遠。
為什麼要使用 Ruby on Rails，您想知道嗎？ 事實上，在許多情境中，RoR 比任何其他工具都更適合。
Ruby on Rails 是一個具有 MIT 憑照的開源服務器端 Web 應用程式框架。 雖然 Ruby on Rails 是用 Ruby 編寫的，Ruby 是一種來自日本的動態通用編程語言； RoR 實際上是一個框架，而不是一種語言。 許多企業家和非開發人員經常混淆這兩者，在聽到 Ruby 時會想到 Rails，但很少反過來。
這可能是因為大多數 Ruby 開發人員使用 Ruby on Rails 框架進行開發。
在 Ruby on Rails 推出之後，Ruby 才真正成為一種編程語言。
Rails 創建於 2004 年，並在 2006 年獲得了 Tiobe 頒發的“年度編程語言獎”；儘管它是在 1995 年編寫的。
還有其他基於 Ruby 的框架，但與 Ruby on Rails 相比，它們在開發人員和積極貢獻者中的受歡迎程度較低。 我們將在本文後面仔細研究。
這並不是說其他 Ruby 框架的質量低於 Rails。 實際上恰恰相反—它們是為非常具體的案例而建構的，並且在這些情況下通常優於 Rails。
然而，Rails 將非常適合大多數需要使用 Ruby 框架的專案。
當 RoR 在 2005 年到來時，它引入了一種全新的方法來建構 Web 應用程式。
Rails 帶來的東西之一是約定優於配置的軟體設計範式，它促進了開發人員在多個層面上的工作—例如，通過消除編寫模板程式碼的需要。
與同年發布的 Python 最受歡迎的 Web 框架 Django 一起，Rails 傳播了 MVC 模式的使用和良好的開發實踐，例如 DRY 原則。
Rails 的 Web 開發方式將開發人員從繁瑣的編碼部分中解放出來，讓他們能夠專注於應用程式的業務功能和邏輯。
它還提高了生產力並幫助開發人員更快地交付 MVP 和啟動應用程式。
這幾乎是一個都市傳說，RoR 消亡的神話是圍繞框架及其所基於的語言產生的許多誤解的產物。
那麼，是時候剖析它們了。
雖然 Rails 的運行速度比 Node.js 或 Golang 慢，但只有在具有大規模流量的大型產品中才會注意到這一點。
如果這不是一個擁有大量用戶和請求的大型應用程式，那麼 Rails 不一定是速度慢的罪魁禍首—還有服務器架構或自料庫需要考慮。
有了經過深思熟慮的架構和基礎設施（所有大型專案的必需品，無論編程語言如何），即使是用 Rails 編寫的大型應用程式或其部分也可以很快。
大型 RoR 應用的範例包括 Basecamp、Airbnb 或 GitHub。
那麼所有這些糟糕的風評是從哪裡來的呢？
因為 Rails 為開發人員做了很多工作，所以沒有經驗的開發人員在編寫程式碼時往往會做出錯誤的決定。 對於糟糕的程式碼，性能下降是顯著的。
當談到 Ruby 和 RoR 的固有性能問題時，他們正在積極地進行研究。 例如：
我將首先解釋說，僅將可伸縮性問題和處理許多用戶請求的缺陷歸咎於框架是錯誤的。
為了讓應用程式快速處理請求，服務器系統架構中的每個元素，不僅是 Web 應用程式的後端，都應該正確配置並具有適當的性能。
當 Twitter 從 Rails 遷移到 Scala 時，Ruby on Rails 被指責難以擴展。 這種轉變可能首先引發了圍繞 RoR 的可擴展性問題的辯論。
不過，請記住，我們在這裡談論的是 Twitter 等級的流量。
因此，在譴責 Rails 之前，請嘗試確定究竟是哪個原因導致了速度下降。
Rails 可用的擴展選項：
每當一個新的框架出現時，尤其是一個帶來創新的框架，它就會像病毒一樣傳播開來，突然間，世界各地湧現出數百名用戶和貢獻者。
然後幾年過去了，炒作平息了，曾經最前沿的東西變得不那麼令人興奮、有趣和具有挑戰性了。
它正在成熟。 但成熟不一定是無聊的。
成熟意味著穩定、精煉的程式碼； 和可維護的 Web 應用程式，即使不再使用流行的框架編寫。
追逐技術趨勢並不總是一個好主意。 對更流行的東西進行更改實際上會產生不利的結果並增加間接成本，而不是改善業務運營。
以下是可能出錯的範例：
您現在的後端使用 Ruby，但 Python 是現在的佼佼者，因此自然而然地感覺 Python 可能會使您的業務受益。
但是是否有必要向您的服務器端堆棧添加另一種語言？ 或者它只會讓程式碼函式庫更加混亂和難以維護？
除非你的應用程式和 Twitter 一樣大，否則添加 Python 帶來的商業利益不足以彌補實施成本。
更好的方法是使用當前設置中可用的內容，並以最少的資源浪費解決問題。
由經驗豐富且精通在 Rails 中建構應用程式的開發人員使用時，RoR 的成熟與出色的工具、函式庫和社區支持相結合，使得解決大多數的緊迫問題變得相當簡單。
讓我們看看 Ruby on Rails 的狀態。
儘管遠遠落後於 PHP 或 Python 等主要競爭者，但 Ruby 仍然在 2022 年的 20 種最受歡迎的編程語言列表中名列前茅。
2022 年版的 Stack Overflow 年度開發者調查也將 RoR 置於類似的位置。
要深入了解 Ruby 的用途，我們必須記住，它是一種動態的、通用的編程語言，用途廣泛且成熟。
您可以使用 Ruby 建構的產品列表很長，因為有大量（並且還在增長）的 gem 和函式庫，它們可以充當不同類型應用程式的建構基石。
以下是使用 Ruby 建構的最常見的應用程式類型。
MVP
Ruby 通常被選擇用於 MVP 的經濟高效和快速開發。 在建構功能齊全的應用程式之前，這種語言還經常用於原型設計、引入更新和測試不同版本的產品。
社交網路應用
由於 Ruby 能夠支持流量大的應用程式，因此它非常適合 Twitter 等社交網路應用程式。
公寓共享和預訂應用程式
它還用於公寓共享和預訂應用程式—Airbnb 和 Couchsurfing—因為它可以快速管理大量日常交易和房產預訂。
電子商務平台
Ruby 是 Spree 或 Shopify 等許多電子商務平台的首選編程語言。 它之所以適合這項工作，是因為 Ruby 的開發速度、靈活性和成本效益，它允許一次管理大量事務。
支持複雜數據庫的平台
此類平台的一些最佳示範包括 GitHub（面向開發人員的最大 Git 儲存庫託管平台）和 Bloomberg（多平台金融新聞和分析中心）。
由於其速度、效率和靈活性，Ruby 還用於：
儘管多年來 Rails 的受歡迎程度可能有所下降，但該框架仍被全球超過 100 萬個網站使用，其中包括 Dribbble 和 Hulu 等許多主要參與者。
按照慣例進行編碼，在 RoR 中建構應用程式既快速又簡單—如果您的預算緊張且期限緊迫，這是一個很好的選擇。
由於龐大的人才庫，找到經驗豐富的 RoR 開發人員應該不會花很長時間。
Ruby on Rails 是成熟的，提供的穩定性直接轉化為多年的成功、無憂維護。 優秀的開發人員將知道如何利用 Rails 的魔力，並利用節省的時間專注於業務功能和應用程式邏輯。
在沒有經驗的開發人員手中，Rails 永遠不會成為高級複雜應用程式的好選擇。
它實際上可能是許多令人頭疼的問題和未來維護、性能、安全性和穩定性問題的根源—所有這些都會產生大量成本，否則這些成本是可以避免的。
對於簡單的 API 或部落格，Rails 是一個很好的選擇，即使對於初學者來說也是如此。
近年來，我們注意到在“僅 API”模式下使用 Ruby on Rails 的程式數量顯著增加。用 RoR 可以快速創建 API 作為 MVP，同時使用任何 JS 框架建構應用程式的前端。
Ruby 3.0 版本比 Ruby 2.0 和 Jakuhiro Matzuomoto 的預測快三倍。 現在，3.1 版朝著更好的性能又邁出了一步。 其中一個步驟是實現所謂的“Fiber Scheduler”，它允許 Ruby 的異步工作，沒有任何副作用或繁瑣的開發人員工作。
這意味著一件事—反對 Ruby 的最有力論據之一正在慢慢失去它的依據！ Ruby 的性能越來越好，這一點毫無疑問！
Ruby 仔細研究了眾所周知的問題，並修改了框架的工作方式，使其也朝著異步方向發展。 2022 年初，發布了新版本的 PG gem，可以向資料庫發出異步請求。 它只是證明了 Ruby 社區的大致發展方向。
並非 Ruby on Rails 中的所有更改都是事先考慮好的。 其中一些讓我想起了一個實驗，該實驗表明 RoR 不怕嘗試新事物。 其中一個功能是 Ractor – 一個 Ruby Actor 模型，它將為 Ruby 應用程序提供並行計算能力。
它像 JavaScript 中的服務工作者一樣工作，允許在進程之間實現正確的線程，由於更少的死鎖和活鎖而確保安全。 它們的溝通基於消息傳遞，與概念線程有很大不同。
© Copyrights 從想像到創造. All Rights Reserved.
