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