從Rails到Clojure再到Java,最後回到Rails

banq發表於2018-03-22
在過去的6年中,我開發Web應用程式先後使用了Rails、Clojure和Java,最好又回到了Rails,上。以下是我總結過去幾年使用這些不同的技術棧的好處和缺點。

Rails 2.3
做過一個Rails 2.3的大專案。它是典型的混合大單體,已經失控。它擁有+ 1K的端點並使用了大量的gems。由於依賴關係,升級實際上是不可能的。在某種程度上,它的可維護性和效能問題正是我們期望快速推向市場導致。

但是後來團隊開始專注於重構。開始遵循清潔架構的指導方針。使用了表現層,互動層和儲存層。在某些時候,我相信程式碼庫的一部分實際上是令人愉快的,並且是正確構建的。錯誤和效能問題的數量大幅下降,我們為此感到自豪。但是我們只修改了40%的應用程式。

此時我開始尋找其他工具。我去尋找更適合我想要的東西:生產力、程式碼質量和效能。

Clojure
我有機會啟動一款新產品,並有幸使用Clojure中做了這個產品。這是一個巨大的轉變,轉向一種新的程式設計正規化,而且使用的是一種外來語法。毫無疑問,Clojure是我最喜歡的程式語言。我學到了很多東西,即使在今天,我也會關注這個社群,因為這裡有大量的創新。

我們實現了一個帶有幾個有界上下文服務的web api。我們使用非同步HTTP和資料庫的非同步通訊,使伺服器完全非同步端到端。一切都很快,我們非常有成效,並不斷學習。

並非一切都很好。招聘人員是有個問題。我們發現瞭解Clojure或者甚至願意學習的人是比較難的。從其他程式語言中吸引人們卻有一定難度。

但是我對這個產品的主要問題是,業務不具備規模擴充套件性。雖然我們有了我們認為是一個很好的架構和良好的實施,但沒有透過測試。

所以我開始環顧四周。這次我想要一個大型專案,能夠處理大量資料,無論使用哪種語言。

Java
我發現一家擁有龐大規模專案的公司,他們使用Java。那時我並不在意,我假設我將使用Java entreprise-ish工具,並且這將是來自兩種動態語言的巨大沖擊。但我願意學習,公司相信我能做到。

幸運的是,Java專案不是entreprise-ish。他們非常精簡,在架構上與我以前的工作非常相似。他們有一層僅用於HTTP處理“控制器”和JSON序列化器。他們有一個專門用於業務邏輯的層,等等。使用Java 8實際上很好,因為我可以使用從Clojure學到的一些構造。

事實上,一切都更加嚴格。不得不為所有概念定義POJO是很麻煩的。但實際上,我並沒有在Rails和Clojure社群聽到過抱怨Java的生產力緩慢。實際上,我的速度很快,而且工作效率很高,而且我喜歡用Java 8進行程式設計。它的確更加冗長,但一個好的IDE在這方面有很多幫助。

有時候我認為Rails社群實際上可以從Java社群學到很多東西。反之亦然。例如,在Java中,您花時間定義模型並記錄它們。Java開發人員會為此感到自豪,並對我說:“你在動態語言中沒有這樣的東西,你怎麼做重構並知道一切都好?”。

這是真的。我做了幾個產品範圍的重構。IDE幫助了很多東西,當編譯完所有東西時(事情並不總是很容易完成),事實上我確信一切都很好。

但有趣的是:使用動態語言進行重構的工作量沒有Java這麼大。而動態語言也可以實現更多關於所用資料和模型的定義,但事實是,當您在動態語言環境中程式設計時,您會構建更易於更改的程式碼。

Rails 4.2
最後,我又一次在Rails專案上,這次使用Rails 4.2。我感覺有一件事:在Rails 4.2中進行程式設計與在Rails 2.3中進行程式設計相同。我並不是說沒有改進。我說的是,從我的角度來看,從一個不太記得Rails 2.3的人那裡,在Rails 4.2中編寫一個rest API實際上感覺是一樣的。

這讓我想知道:如果我沒有看到巨大的變化,為什麼升級很難?為什麼會有這麼多重大改變?這是與Java和Clojure生態系統衝突的地方,他們非常關注向後相容性。

我想到另一件事是,新的孩子不會喜歡Rails,而且招聘僱用更困難。現在很酷的孩子們喜歡Go或者Elixir,並且會對Rails皺眉。老實說,我並不期待這一點。

無論如何,我確實認為擁有一支優秀的團隊和一個需要解決的問題是優秀程式設計的主要條件。而且我非常希望Rails能夠進行測試,並儘量充分利用它。

那麼,我從使用這麼多語言中獲得了什麼?
參與過幾個生態系統真的讓我睜大眼睛,讓我想到了幾種做事的方式。這完全取決於權衡,作為工程經理,我必須從能夠從任意堆疊中檢查程式碼中獲益。我可能不是最好的低水平評論者,但從我瞭解到的情況來看,我確實有很多建議。

從Ruby開始:著重於輕鬆更換軟體,適用於小型函式和小型類。讓你的程式碼易於閱讀和理解。關注強大的物件導向程式設計。讓我們嘗試製作預設情況下易於更改的程式碼。

Clojure:考慮容易和簡單的區別。在資料和改變資料的邏輯之間有清晰的區別。能夠區分純函式和副作用功能,嘗試將它們分開。讓我們嘗試預設製作簡單的程式碼。

Java:效能,併發性和嚴格性。不要忘記你的日誌記錄和異常處理。讓我們嘗試預設快速編碼。

對於工程經理的職位,我相信是必須的,而且我覺得我有更多的見解,因為我有過不同的經歷。

缺點?
掌握多種語言的知識確實使我更具多面性。但也使我對某種特定語言的熟練程度和熟練度不夠。擔任高階工程師的工作對我來說更為複雜。幾個月前我曾申請過高階職位,當我為自己的挑戰感到自豪時,公司沒有選擇我。但經過考慮後,我意識到我在公司的“這人是否是一個高階開發人員”測試中落選了。

招聘公司希望招聘到一位經驗豐富的開發人員,使用某種特定的語言具備某種特質,技能和知識。例如:

Java:日誌記錄和異常處理非常重要,不要使用原始字串作為常量,編寫好的文件。熟悉Java中的併發性,Java記憶體模型以及GC的工作原理。

Ruby / Rails:瞭解內部Rails細節,瞭解乾淨的架構,編寫易於更改的程式碼。編寫快速測試。

Clojure:高階函數語言程式設計,Clojure中的高階併發程式設計:channels,transducers等...

遊戲程式設計:矩陣乘法可能比一個if更快。使用快取記憶體經驗。


想成為專家需要花費很多時間來做同樣的事情。沒有捷徑。

概要
雖然 學習語言很困難,但還有很多事情我們需要知道。

知道使用的語言
瞭解使用的構建工具(maven,npm,lein,bundle,...)
瞭解使用的資料儲存(postgres,mongo,elastic,cassandra,...)
瞭解如何將專案投入生產,以及什麼是最佳配置
瞭解專案的結構,在哪裡以及如何實施
瞭解應用程式的業務邏輯

所以,語言只是一小部分。我實際上相信工具和整體生態系統需要更多的時間學習。

From Rails to Clojure, then to Java, then back to

相關文章