Car2go 的前端框架選擇

已禁用發表於2017-09-11

作者:Sumit Kumar 原文連結:car2godevs


2016年12月,car2go 開始在柏林及漢堡組建新的前端團隊開發一些內部產品。匯聚了一批有 NodeJS、前端、rails 以及其它開發經驗的人,很快,前端框架的問題暴露出來了。

在2017年組建一支新的前端開發團隊意味著不得不面對框架選擇的爭論。雖然我已經是一些框架的粉絲了,但我還是給團隊機會來解決這個問題,我希望接下來的兩年都不再起爭論。在本文中,我會講講我們是怎麼做的以及我們最後的選擇。

問題

將擁有不同經驗、背景、程式設計思維和技能的人聚到一個團隊裡,意味著他們每一個人對理想的產品、工作流和編碼風格都有不同的想法。水平層次高低也意味著部分開發者選擇某一框架純粹是出於偏愛或者之前的專案中用過。而另一部分開發者則會關注商業應用以及 App 需求。我的角色是找到一個可長期使用的、社群活躍的、已熟悉的以及開發者們願意使用的框架。

有一點很重要,這個決定不由某一個管理者做出,而是開發團隊中的一些產品所有者和我一起討論。並且我還加了一些更高的要求:比如新人上手的時間。

這一想法的目的是縮小滿足需求的框架的範圍,讓開發者們能在一個「hackweek」內用這些框架做一些小的 App。接著,他們會圍繞這些 App 進行討論,共同客觀的決定一個框架。

這項工作不能盲目的進行,所以我們定了一些規則。

Hackweek 規則

  • 每一個開發者都獨立的從頭開發產品
  • 必須選一個自己不喜歡或不熟悉的框架。這能降低認知偏差,同時能讓他們更客觀的評價所使用的框架。
  • 所開發的產品必須能讓他們深入的瞭解框架。不能是一個簡單的 to-do demo。
  • 所有人都開發同一個產品(後面會講)以更好的比較結果。
  • 每個人在 hackweek 期間都必須按預設的規則來開發產品

候選框架及標準

有些框架馬上就能做出決定。比如 backbone、ember 和 angular1,都2017年了還選它們沒有意義。 比較明顯的社群活躍且有前景的三個框架是 reactJS,angular2 和 vueJS。 VueJS 知道的人較少,而 React 和 Angular 業界及團隊已經有許多討論了。在用其中某個框架做開發的時候,開發人員需要總結經驗。

至於別的框架,需要考慮的標準有:

  • 文件
  • 維護者的活躍度
  • 常用平臺上的提問和回答
  • 可用工具
  • 外掛或擴充套件的數量及質量
  • Web 技術標準
  • 設定開發環境所需時間(設定開發和支援工具,比如 sass ,自定義字型等)
  • 程式碼風格,API 設計
  • 可擴充性

需要開發的產品

要開發的產品很直觀:在單張地圖上顯示所有 Car2go 的車輛(不使用任何已有的單張地圖框架),資料每10s 更新一次。每一座城市/地點都能夠通過 URL 及選框選中。

獲取車輛的地理位置資訊並顯示在地圖上。然後計算每一區域的車輛總數顯示在該區域中——每10s 更新一次。

Berlin - the results looked something like this with a header to switch locations

開發者們需要確定路由、狀態管理、HTTP 請求的解決方案。並且為了應用單張地圖,即使不在框架更新機制中的 DOM 也需要響應狀態變化。這對於開發者探索元件的生命週期與響應等細節非常有幫助。

彙報日

某一個週五,整整一天都被用來展示作品以及進行後續討論。每一個開發者都展示了自己的進展,講了框架的難點和好處。在網上獲得幫助/答案是否容易?文件是否完善?回答問題,漸漸開始小範圍討論,解釋該框架執行我們標準的方式。比如用過 Angular 2 的開發者看了首次使用的人的彙報後,可以迴應他們遇到的問題,而彙報的人也能瞭解到另一種解決問題的辦法。

有一些人在初次嘗試之後就對其所使用的框架表現出極大的熱情。有一些人簡單的說他們用的框架不錯、用它來做開發沒問題。還有一部分人對自己使用的框架感到失望,不推薦使用該框架。

最後,團隊共同客觀的決定一個用起來舒服的框架作為最終選擇。

我們的選擇及一些有趣的評價

我想分享下彙報日中產生的一些有趣的爭論。注意這不是要羅列各框架的優劣點。

一些人建議不要用 VueJS ,因為 StackOverflow 上沒有足夠多相關的問題。而另一些人認為這恰恰說明 Vue 的文件完備且 Vue 論壇活躍。當然,到目前為止,VueJS 的文件的確是最完善的。

TypeScript 也引起了較大的爭議。最終,團隊決定採用標準 ES6 以免給後續接手我們 app 的開發團隊留下太多坑。畢竟,我們所有人都不想接手一個 CoffeeScript App。但以防萬一,我們用 Flow 做型別檢查。

至於 Angular 2,儘管在使用 TypeScript 時, Angular 2 有一些好用的工具,但是 「hackweek」 中,它沒有獲得新的支持者。它的文件,尤其是 JavaScript 文件,不完善、冗長且令人迷惑。開發者們需要更多的時間來上手和使用它。而且它詭異的釋出週期讓人對其未來沒有任何信心。這時候第4版(!)都發布了。

JSX vs Directives - HTML in JS vs Logic in HTML 也是一個有趣的爭論點。最後,團隊得出結論: directive 讓 HTML 更具可讀性,並且大家有使用 Angular 1 的經驗,所以對 directive 更熟悉。VueJS 雖然支援了 JSX 但是它對 directive 的處理也非常優雅。

ReactJS 和 VueJS 彼此類似,但是在文件和 API 的優雅程度上,VueJS 更勝一籌。

最後說一下,所有的框架都解決了我們的問題,而且所有開發者都有所偏愛。所以不要直接採用我們的決策或者將其作為一個放之四海而皆準的事實。而是將它看作是我們的開發者比較贊同的意見。

未來

frontend landscape 每隔一週介紹一款新的框架(hello,moonJS),開發者們顯然想試試這些框架。在可預見的未來,我們會用 VueJS 開發和主體業務有關的 app,而在一些概念驗證性產品及儀表盤 app 中會使用新出現的框架。

總結

從參與 「hackweek」 的開發者、管理人員和其它觀察者的反饋來看,這一週對我來說相當成功,雖然開銷有點貴(這一週啥也沒開發)。但沒讓團隊走上另一條道路(技術問題),也開啟了更輕鬆的進行團隊合作的大門。如同移交 app 給其它團隊,分享知識的最佳辦法:通用元件。


翻譯:YoungZ 部分翻譯採用意義;水平有限,翻譯中可能有微小錯誤(但不影響掌握文章大意)請指出。

相關文章