引言：JavaScript 應用變得越來越龐大。這是因為使用JavaScript能做的事情遠比我們大多數人所需求的要多得多。我們不能僅因為技術上可行，就去考慮軟體系統的擴充問題。為一個不需要擴充的系統增加擴充性是不值得的，尤其對最終使用者來說，這隻會使系統顯得更加笨重。
本文選自《大型JavaScript應用最佳實踐指南》。
作為JavaScript 開發者和架構師，必須承認并了解影響擴充性的因素。雖然不是所有JavaScript 應用都需要擴充，但總有一部分是需要的。比如，我們很難确認某個系統不需要擴充，不需要為它的可擴充性花費時間和精力。除非我們開發的系統不需要後期維護，否則總會有對增長和成功的預期。
從另一方面講，JavaScript 應用并非天生成熟的可擴充應用，而是逐漸積累、進化成的可擴充應用。對于JavaScript 開發人員來說， “可擴充性的影響因素”是一個有效的工具。我們不希望一開始就過度設計，更不希望被早期設計綁住手腳，限制了可擴充性。
對可擴充的需要
擴充軟體是一種基于反應的活動。考慮可擴充性的影響因素可以幫助我們積極地做出準備。在應用後端等系統中，這種“擴充活動”通常是被自動處理的，可能是短暫的通路高峰。例如，激增的使用者請求導緻負載驟增，這時負載均衡器介入，将負載均勻地分派到後端伺服器。在某些極端情況下，系統可能會在需要時自動準備新的後端資源來應對變化，當不再需要時将這些資源自動銷毀。
但是前端不一樣，前端的擴充活動通常發生的時間周期較長，而且更加複雜。JavaScript應用的獨特一面在于，浏覽器能獲得的硬體資源就是它能使用的全部硬體資源，它從後端擷取的資料可以很好地按比例增長，但這不是我們需要考慮的。随着軟體的不斷演進，我們要想成功做點什麼，就必須關注“可擴充性的影響因素”。
上圖自上而下地展示了可擴充性的影響因素。首先是使用者提出軟體需要實作的功能，接着功能尺寸、與其他功能的關系等因素會直接影響開發團隊的構成，沿着箭頭自上而下影響相應地增長。
不斷增長的使用者
如果建構的應用隻服務于一個使用者，就沒有必要這麼大費周章了。基于典型使用者的需求來建構的應用将會為更多使用者提供服務。是以在應用進化過程中，應該預見到使用者的增長。盡管并沒有确切的目标使用者數量，不過，基于應用自身的特點，仍然可以使用http://www.alexa.com/這類工具作為基準，設定活躍使用者數量的目标值。比如，如果我們的應用是任何人都可以通路的，就會希望有大量的注冊使用者；但如果僅針對個人安裝，那麼加入系統的使用者數量的增長就會比較緩慢。但即使如此，我們還是希望部署數量不斷增加，以提升軟體的使用者總量。
與前端界面互動的使用者數量是擴充應用最大的影響因素。每增加一個使用者都伴随着各種架構層面上指數級的增長。如果自上而下地看，使用者決定一切。應用的存在終歸是為了服務使用者。JavaScript 代碼越易于擴充，就越能取悅使用者。
添加新功能
也許能夠取悅使用者的功能就是使用者基數龐大的成功軟體最顯而易見的附帶産物。軟體的功能會随着使用者數不斷增長，盡管新功能顯而易見，但還是經常被忽視。明明知道增加新功能不可避免，但我們還是很少思考如何合理地在代碼中實作源源不斷的新需求。正是缺少這樣的思考，阻礙了我們繼續發展。
這在軟體傳遞初期非常棘手。軟體開發商會竭盡全力吸引新的使用者，但由于初期階段能夠吸引使用者的功能有限，導緻收效甚微。沒有足夠多的成熟特性，沒有龐大的開發團隊，也沒有機會去打破使用者習慣。當沒有這些限制條件時，比較容易能夠實作一些功能讓已有或潛在使用者感到眼花缭亂。但是我們如何才能在早期決策時迫使自己考慮周全？如何才能在提供更多功能的前提下確定沒有限制我們擴充軟體的能力？
你也許會發現，不管是開發新功能還是增強已有的功能，都是可擴充JavaScript 架構始終需要考慮的問題。我們需要考慮的不僅僅是軟體推廣文案中羅列的各種功能，還要考慮這些功能的複雜度、各個功能之間的共性以及各個功能有多少“移動部件（MovingParts）”。當自上而下審視JavaScript 架構時，如果使用者是第一層級，那麼各個功能就是下一個層級。從這個層級開始擴充變得紛繁複雜。
使功能變複雜的，并不是某一個單獨使用者，而是一群需要這個功能的使用者。從這個角度講，我們不得不思考使用軟體的使用者的特征或者角色，以及哪些功能提供給哪些角色。對這種組織結構的需求在一開始并不明顯。直到後期，我們先前的決策使得引入基于角色的特性難以實施時，它才會顯現出來。并且，這還取決于我們的軟體是如何部署的，有時可能需要支援多種不同的用例。比如，可能幾個大機構使用者，都有各自的部署方案，并且很可能有各自獨特的使用者結構上的限制。這是十分具有挑戰性的，如果希望做到可擴充，架構就需要支援這些組織結構迥然不同的需求。
雇傭更多的開發者
實作軟體的各種功能需要可靠的JavaScript 開發人員，并且他們應該知道自己在做什麼。能有一個這樣的開發者團隊是非常幸運的事情。團隊組建不是自發的，在團隊可以開發出優秀代碼之前，需要在某種程度上建立起彼此之間的信任和尊重。一旦開始，我們就處于一個良好的狀态。再看一下前面提到的自上而下的可擴充性影響因素，我們要開發的功能會直接影響團隊的健康。這之間的平衡基本上是無法維持的，但是可以盡量接近。缺少人手但又有太多的功能要實作，這會讓團隊成員倍感壓力。當如期傳遞毫無希望時，大家就不會努力嘗試了。另一方面，如果開發人員過多，要開發的功能有限，就會帶來更多的溝通負擔，而定義職責又很困難，是以當大家對職責沒有共識時，離失敗就不遠了。
相對于擁有太多的開發人員，開發人員不足反而更易于功能的開發。當面臨巨大的功能開發壓力時，是一個很好的時機來退後想一想：“如果我們有更多的開發者，會與現在有哪些不同呢？”這個問題經常被忽略掉，直接去招更多的開發者。而讓大家驚訝的是，招聘到新人後功能的産出并沒有立竿見影的效果。這就是為什麼我們需要一個沒有愚蠢問題、責任配置設定明确的研發文化。
團隊組織結構和開發方法并沒有定式，開發團隊需要有針對性地處理開發中的情況，最大的問題無疑就是功能的數量、規模和複雜度。是以，這些才是我們在建立團隊之初，以及團隊成長過程用應該考慮的。後一點尤為重要，因為當功能大量增加後，初期的團隊結構是無法适應的。
鑒于這些擴充影響因素會随着時間推移而改變，我們以架構的角度來調整設計或者修改産品，以應對擴充所面臨的挑戰。
若要進一步讨論這些影響擴充的各項因素，深入了解它們并準備一個核對清單，以幫助我們實作可擴充的JavaScript 應用來響應這些事件，可見《大型JavaScript應用最佳實踐指南》一書。
本文選自《大型JavaScript應用最佳實踐指南》，點此連結可在博文視點官網檢視此書。
