JavaScript 踩坑心得— 為了高速（上）

OneAPM官方技術部落格發表於2016-03-16
JavaScript
一.前言

很多情況下，產品的設計與開發人員一直想打造一套高品質的解決方案，從而快速、平穩地適應產品迭代。速度是衡量產品適應性的真正且唯一的標準，而且，這並不是筆者的一家之言。

「速度是衡量適應能力的真正指標。」 ——艾瑞克·埃利奧特

許多公司選擇 JavaScript，就是看中了它靈活、快速的優點。儘管此言非虛，但如果你在構建 JavaScript 系統時考慮得不夠周全，靈活與高速的特性反而可能將你帶入歧途。

一些值得特別關注的問題包括：

  • 程式碼重複
  • 樣式或風格不一致
  • 無法隨意擴充套件
  • 工具與模組選擇阻礙了生產力
  • 測試程式不可靠或缺失
  • 深度繼承(猩猩/香蕉問題)

原作者曾在多個側重 JavaScript 的開發環境中工作了一段時間之後，幾乎經歷了所有擴充套件 JavaScript 應用可能導致的問題，客戶端與伺服器端均不能倖免。以下是對這些問題的總結，希望能幫助大家少走一些彎路。

二.基礎性原則

在探討與上下文相關的 JavaScript 問題之前，以下是一些與平臺相獨立的建議，肯定能幫助你減輕工作負擔。

1.避免經典的物件導向模式

JavaScript 功能非常強大，它為物件組合提供了原型繼承與函數語言程式設計功能，使用 JavaScript 的這兩大支柱功能，而不執著於經典的物件導向模式，能夠有效發揮 JavaScript 的強勁功能。應用的組合度與模組化程度越高，今後就越容易重構與擴充套件。

2.越懶越好

現而今，NPM 上提供了超過20萬個模組。時間就是金錢，你花在程式碼維護上的時間越多，對僱主而言，你就越昂貴。更何況，許多程式碼其實不用你親自編寫。

在這裡，筆者還建議你使用第三方的運維服務與工具。沒必要建立自己的分析平臺，除非你的應用擴充套件到非常大的規模，以致於 Google Analytics，Mixpanel，百度統計等 SaaS 營銷軟體無法滿足你的需求。使用這些服務處理相關任務，能促使你專注於真正重要的東西——產品，而且，現在研發的人力成本越來越高，使用適當的 APM 軟體也能減少開發維護網站的任務量，例如 OneAPM 、NewRelic、APPdynamic 等，這能讓工程師專注於生產價值，而不是管理程式碼質量。

3.保持一致性

導致生產力嚴重下滑的另一重要原因是面對陌生程式碼時手足無措，四處翻找。採用統一的風格指南，建立可辨明的樣式，就能解決這一難題。同樣的風格與樣式意味著新的專案看起來也更為熟悉。

筆者尤其偏愛 Airbnb 的風格指南。該指南的貢獻者超過 160 人，每個月有16.9萬次的下載。此外，它還提供了一個 ESLint 外掛，也就是說，如果你不準備覆蓋什麼的話，無需任何配置就能為你所用。

與成千上萬名 JavaScript 工程師共享樣式與風格。

此外，使用 linter 以確保團隊內部的樣式一致。目前，ESLint 是筆者最愛的 linter，因為它不僅提供了外掛能力，還擁有來自開源社群的持續支援。幾乎針對每一種文字編輯器與 IDE，都有 ESLint 外掛可用。

Yeoman 也可以幫你建立在新專案中使用的應用模板，實現更為深入的一致性。有了 Yeoman，你可以在每個應用中使用相同的基本依賴關係，編碼樣式以及風格。

4.充分利用豐富的工具

JavaScript 是擁有最完備的工具生態系統的程式語言之一。請一定要利用這一點！iron-node,react devtools 和 redux devtools 都是不容錯過的工具。

Electron 與 React Native 提供了訪問原始環境的能力，允許你為對種平臺建立應用，而且，能有效提高程式碼重用率。

三.編寫過程中的「坑」
1.儘可能保持小巧

將應用分為許多小巧的模組，能真正實現可組合的 JavaScript。遵循 FIRST 原則（Focused 專注，Independent 獨立，Reusable 可重用，Small 小巧，Testable 可測試），能夠降低應用複雜度，同時提升測試能力與重用率。

「無論是客戶端元件還是伺服器端的元件，無論是 Node 模組還是一段視覺化 UI，龐大的元件總是比小巧的元件更復雜，更難以維護。」 ——阿迪·奧斯馬尼

請記住，模組的功能越小越好。事實上，模組越小，其重用率就越高。

2.充分利用 ES2015

將其用於 APIs，SPAs，以及兩者的所有中間環節。類似 Bable的工具能給你帶來極大的優勢。在今天，使用 ES2015 的能力意味著你可以用更少、更整潔的程式碼建立應用。不要因為害怕供應商鎖定或這些工具不容易找到而放棄使用它們。

老實說，現在已經沒有理由不適用 Babel 了！Bable 既可以處理普通的 JavaScript，也可以處理任何型別的編譯程式碼。這意味著，你可以隨時將模組移回 ES5。

建立能與 JavaScript 完好擴充套件的服務並非易事。應用越大，快速執行並適應新變化就越難。請確保你正在建造的服務是高度可用，且支援自動擴充套件的。

3.建立支援 JavaScript 應用的基礎架構

JavaScript 是一種單執行緒的語言。這意味著，在沒有叢集的情況下，你的應用只能使用單個 CPU。筆者喜歡將負載平衡工作留給代理或 NGINX 之類的負載平衡器，而不是交由 Node 的叢集模組處理。此外，筆者還偏好使用較小的伺服器來執行應用。這樣，當需要更多資源時，筆者只需增加伺服器的數量就能輕易實現橫向擴充套件。這能幫助筆者最小化當前的運營成本。

4.集裝箱化！集裝箱化！集裝箱化！

以下是部分原因：

  1. 集裝箱化會迫使你遵從應用開發12大原則。
  2. 通過集裝箱化，可以實現開發、階段、測試以及生產環境的對等。
  3. 集裝箱非常易於橫向擴充套件。
  4. 你可以輕易將應用轉移到其他雲服務上。（防止供應商鎖定，使用其他支出服務。）

實現環境集裝箱化的理由還有很多很多，一旦掌握了基本知識，集裝箱化就不難實現。如果你想打造在任何平臺都能使用的靈活應用，集裝箱化是必須掌握的第一步。而且，由於集裝箱在外部是無狀態的，可以支援無限次複製。

5.打造易於擴充套件與維護的應用

對於 APIs 與服務，選擇 Hapi 作為伺服器框架，Joi 用於校驗，hapi-swagger 外掛用於維護活文件，是相當不錯的組合。

Hapi 特別適用於模組化的大型應用，同時也能為簡單的應用提供支援。此外，最讓它與眾不同的是其提供的封裝能力。Hapi 提供了許多通過依賴注入訪問伺服器的「外掛」。這樣，你可以將業務邏輯按照緊密程度進行分組。將應用分解到這些外掛中，能極大地提高擴充套件能力。專案的操縱也變得極為直白，原因是不需要學習自定義的外掛架構，而 Hapi 本身又提供了豐富的文件資料。

Joi 是一種驗證模組，與 Hapi 出自同一班工程師之手（Walmart Labs）。Joi 的 API 與其卓越的功能使得驗證變成小菜一碟。你知道如何建立驗證模式，因此建立驗證模組也變得非常簡單。用於驗證 UI 中某個表格的一段程式碼也可以用來驗證一個傳入的請求、一個模組，或測試。的確是非常令人驚奇。

將 hapi-swagger 插入伺服器後，你可以輕易地將任意路徑標記為 API 的一部分，hapi-swagger 會幫你生成活文件。更不用說，hapi-swagger 會讀取 Joi 驗證，為開發者提供細緻的 API 文件，而你不用費吹灰之力。不過，使用 Express 或 Koa 也可能得到相同的效果，但筆者仍舊認為 Hapi 是非常驚人的工具。

四.關於後續

本文主要講的是關於 JavaScript 使用過程中的一些基礎性的心得體驗，不一定適合每一個人，但是確實也是作者的「踩坑之得」，大家在閱讀之後如果有什麼想分享的也可以在討論區進行回覆，閉門造車總是不行的。

本文的下一個姊妹篇，主要講的內容預計為關於 JavaScript 使用過程中如何提高使用者體驗和效能優化這方面的內容，敬請期待~

Browser Insight 是一個基於真實使用者的 Web 前端效能監控平臺，能夠幫大家定位網站效能瓶頸，網站加速效果視覺化；支援瀏覽器、微信、App 瀏覽 HTML 和 HTML5 頁面。想閱讀更多技術文章，請訪問OneAPM 官方技術部落格。

本文轉自 OneAPM 官方部落格

相關文章