引言：JavaScript 應用變得越來越龐大。這是因為使用JavaScript能做的事情遠比我們大多數人所需求的要多得多。我們不能僅因為技術上可行，就去考慮軟體系統的擴充套件問題。為一個不需要擴充套件的系統增加擴充套件性是不值得的，尤其對終端使用者來說，這隻會使系統顯得更加笨重。 
本文選自《大型JavaScript應用最佳實踐指南》。

　　作為JavaScript 開發者和架構師，必須承認並瞭解影響擴充套件性的因素。雖然不是所有JavaScript 應用都需要擴充套件，但總有一部分是需要的。比如，我們很難確認某個系統不需要擴充套件，不需要為它的可擴充套件性花費時間和精力。除非我們開發的系統不需要後期維護，否則總會有對增長和成功的預期。 
　　從另一方面講，JavaScript 應用並非天生成熟的可擴充套件應用，而是逐步積累、進化成的可擴充套件應用。對於JavaScript 開發人員來說， “可擴充套件性的影響因素”是一個有效的工具。我們不希望一開始就過度設計，更不希望被早期設計綁住手腳，限制了可擴充套件性。

對可擴充套件的需要

　擴充套件軟體是一種基於反應的活動。考慮可擴充套件性的影響因素可以幫助我們積極地做出準備。在應用後端等系統中，這種“擴充套件活動”通常是被自動處理的，可能是短暫的訪問高峰。例如，激增的使用者請求導致負載驟增，這時負載均衡器介入，將負載均勻地分派到後端伺服器。在某些極端情況下，系統可能會在需要時自動準備新的後端資源來應對變化，當不再需要時將這些資源自動銷燬。 
　　但是前端不一樣，前端的擴充套件活動通常發生的時間週期較長，而且更加複雜。JavaScript應用的獨特一面在於，瀏覽器能獲得的硬體資源就是它能使用的全部硬體資源，它從後端獲取的資料可以很好地按比例增長，但這不是我們需要考慮的。隨著軟體的不斷演進，我們要想成功做點什麼，就必須關注“可擴充套件性的影響因素”。 

不斷增長的使用者

　　如果構建的應用只服務於一個使用者，就沒有必要這麼大費周章了。基於典型使用者的需求來構建的應用將會為更多使用者提供服務。所以在應用進化過程中，應該預見到使用者的增長。儘管並沒有確切的目標使用者數量，不過，基於應用自身的特點，仍然可以使用http://www.alexa.com/這類工具作為基準，設定活躍使用者數量的目標值。比如，如果我們的應用是任何人都可以訪問的，就會希望有大量的註冊使用者；但如果僅針對個人安裝，那麼加入系統的使用者數量的增長就會比較緩慢。但即使如此，我們還是希望部署數量不斷增加，以提升軟體的使用者總量。 
　　與前端介面互動的使用者數量是擴充套件應用最大的影響因素。每增加一個使用者都伴隨著各種架構層面上指數級的增長。如果自上而下地看，使用者決定一切。應用的存在終歸是為了服務使用者。JavaScript 程式碼越易於擴充套件，就越能取悅使用者。

新增新功能

　　也許能夠取悅使用者的功能就是使用者基數龐大的成功軟體最顯而易見的附帶產物。軟體的功能會隨著使用者數不斷增長，儘管新功能顯而易見，但還是經常被忽視。明明知道增加新功能不可避免，但我們還是很少思考如何合理地在程式碼中實現源源不斷的新需求。正是缺少這樣的思考，阻礙了我們繼續發展。 
　　這在軟體交付初期非常棘手。軟體開發商會竭盡全力吸引新的使用者，但由於初期階段能夠吸引使用者的功能有限，導致收效甚微。沒有足夠多的成熟特性，沒有龐大的開發團隊，也沒有機會去打破使用者習慣。當沒有這些限制條件時，比較容易能夠實現一些功能讓已有或潛在使用者感到眼花繚亂。但是我們如何才能在早期決策時迫使自己考慮周全？如何才能在提供更多功能的前提下確保沒有限制我們擴充套件軟體的能力？ 
　　你也許會發現，不管是開發新功能還是增強已有的功能，都是可擴充套件JavaScript 架構始終需要考慮的問題。我們需要考慮的不僅僅是軟體推廣文案中羅列的各種功能，還要考慮這些功能的複雜度、各個功能之間的共性以及各個功能有多少“移動部件（MovingParts）”。當自上而下審視JavaScript 架構時，如果使用者是第一層級，那麼各個功能就是下一個層級。從這個層級開始擴充套件變得紛繁複雜。 
　　使功能變複雜的，並不是某一個單獨使用者，而是一群需要這個功能的使用者。從這個角度講，我們不得不思考使用軟體的使用者的特徵或者角色，以及哪些功能提供給哪些角色。對這種組織結構的需求在一開始並不明顯。直到後期，我們先前的決策使得引入基於角色的特性難以實施時，它才會顯現出來。並且，這還取決於我們的軟體是如何部署的，有時可能需要支援多種不同的用例。比如，可能幾個大機構使用者，都有各自的部署方案，並且很可能有各自獨特的使用者結構上的限制。這是十分具有挑戰性的，如果希望做到可擴充套件，架構就需要支援這些組織結構迥然不同的需求。

僱傭更多的開發者

　　實現軟體的各種功能需要可靠的JavaScript 開發人員，並且他們應該知道自己在做什麼。能有一個這樣的開發者團隊是非常幸運的事情。團隊組建不是自發的，在團隊可以開發出優秀程式碼之前，需要在某種程度上建立起彼此之間的信任和尊重。一旦開始，我們就處於一個良好的狀態。再看一下前面提到的自上而下的可擴充套件性影響因素，我們要開發的功能會直接影響團隊的健康。這之間的平衡基本上是無法維持的，但是可以儘量接近。缺少人手但又有太多的功能要實現，這會讓團隊成員倍感壓力。當如期交付毫無希望時，大家就不會努力嘗試了。另一方面，如果開發人員過多，要開發的功能有限，就會帶來更多的溝通負擔，而定義職責又很困難，所以當大家對職責沒有共識時，離失敗就不遠了。 
　　相對於擁有太多的開發人員，開發人員不足反而更易於功能的開發。當面臨巨大的功能開發壓力時，是一個很好的時機來退後想一想：“如果我們有更多的開發者，會與現在有哪些不同呢？”這個問題經常被忽略掉，直接去招更多的開發者。而讓大家驚訝的是，招聘到新人後功能的產出並沒有立竿見影的效果。這就是為什麼我們需要一個沒有愚蠢問題、責任分配明確的研發文化。 
　　團隊組織結構和開發方法並沒有定式，開發團隊需要有針對性地處理開發中的情況，最大的問題無疑就是功能的數量、規模和複雜度。所以，這些才是我們在建立團隊之初，以及團隊成長過程用應該考慮的。後一點尤為重要，因為當功能大量增加後，初期的團隊結構是無法適應的。 
　　鑑於這些擴充套件影響因素會隨著時間推移而改變，我們以架構的角度來調整設計或者修改產品，以應對擴充套件所面臨的挑戰。 
若要進一步討論這些影響擴充套件的各項因素，深入瞭解它們並準備一個核對清單，以幫助我們實現可擴充套件的JavaScript 應用來響應這些事件，可見《大型JavaScript應用最佳實踐指南》一書。 
　　本文選自《大型JavaScript應用最佳實踐指南》，點此連結可在博文視點官網檢視此書。 
　　　　　　　　　　　　　　　　　　　　

想及時獲得更多精彩文章，可在微信中搜索“博文視點”或者掃描下方二維碼並關注。