模块化JavaScript实战：打造可读、可维护、可扩展的代码

需积分: 10 49 浏览量更新于2024-07-18 收藏 3.17MB PDF 举报

"Mastering Modular JavaScript 1st Edition - 由Nicolás Bevacqua撰写，专注于使用ECMAScript 6 (ES6) 实现模块化JavaScript编程，以提高代码可读性、可维护性和可扩展性。本书适用于高级开发者、技术领导者和软件架构师，帮助他们创建简单灵活且能控制内部复杂性的模块。" 在JavaScript开发中，模块化编程是一种关键的实践方法，它使代码结构更加清晰，便于维护和扩展。"Mastering Modular JavaScript 1st Edition" 是一本专为有经验的JavaScript开发者设计的指南，特别是那些已经熟悉ECMAScript 6 (ES6) 的读者。作者Nicolás Bevacqua通过这本书，展示了如何通过将代码库分解为更小的模块来扩展JavaScript应用程序。模块化的核心概念是将复杂的问题分解为更小、更独立的部分，每个部分都有明确的责任和接口。在JavaScript中，我们可以使用ES6的`import`和`export`关键字来实现模块之间的依赖关系。这样可以避免全局变量污染，减少代码冲突，并提高代码的复用性。书中提到，模块化架构的关键在于创建自包含的代码单元，这些单元在系统各个层次（客户端和服务器端）都能独立工作。通过这种方式，可以确保代码的灵活性，同时控制内部的复杂性。模块应该具有低耦合度，高内聚性，使得它们可以在不干扰其他模块的情况下进行修改或替换。高级开发者和技术领导者需要理解如何设计和组织这些模块，以实现良好的架构。这包括如何定义模块接口，如何有效地管理模块间的依赖，以及如何利用模块化的特性来优化性能。此外，书中还会探讨如何通过模块化来解决大型项目中的代码组织问题，如代码的分发、加载策略和懒加载等。模块化不仅仅是代码结构的问题，还涉及到测试、调试和文档编写。书中的设计实践可以帮助开发者创建易于测试的模块，这可以通过单元测试和集成测试来验证模块的功能。同时，模块化也有助于提高代码的可读性，这对于维护和协作至关重要。在实际项目中，模块化还可以结合其他现代前端框架和库，如React、Angular或Vue.js，这些框架都支持基于模块的组件化开发。通过结合模块化与这些工具，开发者可以构建出更加灵活且可扩展的单页应用(SPA)或复杂的web服务。 "Mastering Modular JavaScript 1st Edition" 提供了关于JavaScript模块化编程的深入见解，对于任何希望提升其在JavaScript项目中实施模块化能力的人来说，都是一本宝贵的资源。通过学习和应用书中的知识，读者能够提升代码质量，优化开发流程，从而更好地应对大型、复杂项目的需求。

theCommonJSstandardismoreinlinewithtraditionalmoduleloadingmechanisms.In

CommonJS,eachfileisamodulewithitsownscopeandcontext.Dependenciesareloaded

usingasynchronousrequirefunctionthatcanbedynamicallyinvokedatanytimeinthe

lifecycleofamodule,asillustratedinthissnippet:

constmathlib=require('./mathlib')

MuchlikeRequireJSandAngularJS,CommonJSdependenciesarealsoreferredtobya

pathname.Themaindifferenceisthattheboilerplatefunctionanddependencyarrayarenow

bothgone,andtheinterfacefromamodulecouldbeassignedtoavariablebinding,orused

anywhereaJavaScriptexpressioncouldbeused.

UnlikeRequireJSorAngularJS,CommonJSwasratherstrict.InRequireJSandAngularJS,you

couldhavemanydynamicallydefinedmodulesperfile,whereasCommonJShadaonetoone

mappingbetweenfilesandmodules.Atthesametime,RequireJShadseveralwaysofdeclaring

amodule,andAngularJShadseveralkindsoffactories,services,providers,andsoon—besides

thefactthatitsdependencyinjectionmechanismwastightlycoupledtotheAngularJS

frameworkitself.CommonJS,incontrast,hadasinglewayofdeclaringmodules.Any

JavaScriptfilewasamodule,callingrequirewouldloaddependencies,andanything

assignedtomodule.exportswasitsinterface.Thisenabledbettertoolingandcode

introspection,makingiteasierfortoolstolearnthehierarchyofaCommonJScomponent

system.

Eventually,BrowserifywasinventedasawayofbridgingthegapbetweenCommonJSmodules

forNode.jsserversandthebrowser.Usingthebrowserifycommandlineinterfaceprogram

andprovidingitwiththepathtoanentrypointmodule,onecouldcombineanunthinkable

numberofmodulesintoasinglebrowserreadybundle.ThekillerfeatureofCommonJS,the

npmpackageregistry,wasdecisiveinaidingitstakeoverofthemoduleloadingecosystem.

Granted,npmwasn’tlimitedtoCommonJSmodulesorevenJavaScriptpackages,butthatwas

andstillisbyandlargeitsprimaryusecase.Theprospectofhavingthousandsofpackages

(nowoverhalfamillionandsteadilygrowing)availableinyourwebapplicationatthepressof

afewfingertips,combinedwiththeabilitytoreuselargeportionsofasystemonboththe

Node.jswebserverandeachclient’swebbrowser,wastoomuchofacompetitiveadvantagefor

theothersystemstokeepup.

1.2.4 ES6, import, Babel, and Webpack

WithES6becomingstandardizedinJune2015,andBabeltranspilingES6intoES5longbefore

then,anewrevolutionwasquicklyapproaching.TheES6specificationincludedamodule

syntaxnativetoJavaScript,oftenreferredtoasECMAScriptmodules(ESM).

ESMislargelyinfluencedbyCJSanditspredecessors,offeringastaticdeclarativeAPIaswell

asapromisebaseddynamicprogrammableAPI,asillustratedhere:

importmathlibfrom'./mathlib'

import('./mathlib').then(mathlib=>{

//...

})

InESM,too,everyfileisamodulewithitsownscopeandcontext.Onemajoradvantagein

ESMoverCJSishowESMhas—andencourages—awayofstaticallyimportingdependencies.

Staticimportsvastlyimprovetheintrospectioncapabilitiesofmodulesystems,giventheycan

beanalyzedstaticallyandlexicallyextractedfromtheabstractsyntaxtree(AST)ofeach

moduleinthesystem.StaticimportsinESMareconstrainedtothetopmostlevelofamodule,

furthersimplifyingparsingandintrospection.AnotheradvantageofESMoverCommonJS

require()isthatESMspecifiesawayofdoingasynchronousmoduleloading,which

impliesthatpartsofanapplication’sdependencygraphcouldbeloadedinresponsetospecific

events,concurrently,orlazilyasneeded.Althoughthisfeatureisnotyetimplementedinmost

environmentsatthetimeofthiswriting,thereisstrongindicationthatNode.jswould

incorporateitinthefuture.

InNode.jsv8.5.0,ESMsupportwasintroducedbehindanexperimentalmodules

flag,providedthatweusethe.mjsfileextensionforourmodules.Mostevergreenbrowsers

alreadysupportESMwithoutflags.

WebpackisasuccessortoBrowserifythatlargelytookovertheroleofuniversalmodule

bundler,thankstoabroadersetoffeatures.JustasinthecaseofBabelandES6,Webpackhas

longsupportedESMwithbothitsstaticimportandexportstatementsaswellasthe

dynamicimport()functionlikeexpression.Ithasmadeaparticularlyfruitfuladoptionof

ESM,innolittlepartthankstotheintroductionofa“codesplitting”mechanism,wherebyit’s

abletopartitionanapplicationintodifferentbundlestoimproveperformanceonfirstload

experiences.

GivenhowESMisnativetothelanguage(asopposedtoCJS),itcanbeexpectedtocompletely

overtakethemoduleecosysteminafewyears.

1.3 The Perks of Modular Design

We’vealreadyaddressedthefactthatmodularity,asopposedtoasinglesharedglobalscope,

helpsavoidunexpectedclashesinvariablenamesthankstothediversificationofscopingacross

modules.Beyondafixforclashes,modularityspreadacrossfileslimitstheamountof

complexitywehavetopayattentiontowhenworkingonanyoneparticularfeature.Asaresult,

ourteamisabletofocusonthetaskathandandbemoreproductive.

Maintainability,ortheabilitytoeffectchangeinthecodebase,alsoimprovessignificantly

becauseofthis.Whencodeissimpleandmodular,it’seasiertobuilduponandextend.

Maintainabilityisvaluableregardlessofteamsize:eveninateamofone,ifweleaveapieceof

codeuntouchedforafewmonthsandthencomebacktoit,itmightbehardtoimproveuponor

evenunderstandifwedidn’tconsiderwritingmaintainablecodethefirsttimearound.

Modularcodeismeanttobehighlymaintainablebydefault.Bykeepingpiecesofcodesimple

andfollowingthesingleresponsibilityprinciple(SRP),wherebyeachaimstofulfillonlyone

goal,andcombiningthesesimplepiecesofcodeintomoresophisticatedcomponents,we’re

abletocomposeourwaytolargercomponents,andeventuallytoanentireapplication.When

eachpieceofcodeinaprogramismodular,thecodebaseappearstobesimplewhenwe’re

lookingatindividualcomponents,yetonthewhole,itisabletoexhibitcomplexbehaviors,just

likethebookpublishingprocesswediscussedatthebeginningofthischapter.

Componentsinmodularapplicationsaredefinedbytheirinterfaces.Theimplementationof

thosecomponentsisnottheiressence,buttheirinterfacesare.Wheninterfacesarewell

designed,theycanbegrowninnonbreakingways,augmentingthenumberofusecasestheycan

satisfy,withoutcompromisingexistingusage.Whenwehaveamindfullydesignedinterface,

theimplementationbehindthatinterfacebecomeseasytotweakorswapentirely.Strong

interfacesareeffectiveathidingawayweakimplementations,whichcanbelaterrefactoredinto

morerobustimplementations,providedtheinterfaceholds.Stronginterfacesarealsoexcellent

forunittestingbecausewewon’thavetoworryabouttheimplementationandcantestthe

interface—theinputsandoutputsofacomponentorfunction.Iftheinterfaceiswelltestedand

robust,wecansurelyconsideritsimplementationinasecondaryplane.

Giventhatthoseimplementationsaresecondarytotheforemostrequirementofhavingintuitive

interfaces,whicharen’tcoupledtotheirimplementations,wecanconcernourselveswiththe

tradeoffbetweenflexibilityandsimplicity.Flexibilityinevitablycomesatthecostofadded

complexity,whichisagoodreasonnottoofferflexibleinterfaces.Atthesametime,flexibility

isoftenanecessity,andthusweneedtostriketherightbalancebydecidinghowmuchrigidity

wecangetawaywithinourinterfaces.Thisbalancewouldmeananinterfaceappeasesits

consumersthankstoitseaseofuse,butthatitalsoenablesadvancedormoreuncommonuse

caseswhenneeded,withouttoomuchofadetrimentaleffectontheeaseofuseoratthecostof

greatlyenhancedimplementationcomplexity.

We’lldiscussthetradeoffsbetweenflexibility,simplicity,composability,andtherightamount

offutureproofinginthefollowingcoupleofchapters.

1.4 Modular Granularity

Wecanapplymodulardesignconceptsoneverylevelofagivensystem.Ifaproject’sdemands

outgrowitsinitialscope,maybeweshouldconsidersplittingthatprojectintoseveral,smaller

projectswithsmallerteamsthataremoremanageable.Thesamecanbesaidofapplications:

whentheybecomelargeorcomplexenough,wemightwanttosplitthemintodifferentiated

products.

Whenwewanttomakeanapplicationmoremaintainable,weshouldconsidercreating

explicitlydefinedlayersofcodesothatwecangroweachlayerhorizontallywhilepreventing

thecomplexityofthoseadditionsfromspreadingtoother,unrelated,layers.Thesamethought

processcanbeappliedtoindividualcomponents,splittingthemintotwoormoresmaller

componentsthatarethentiedtogetherbyyetanothersmallcomponent,whichcouldactasa

compositionlayerwhosesoleresponsibilityisknittingtogetherseveralunderlyingcomponents.

Atthemodulelevel,weshouldstrivetokeepfunctionssimpleandexpressive,withdescriptive

namesandnottoomanyresponsibilities.Maybewe’llhaveafunctiondedicatedexclusivelyto

pullingtogetheragroupoftasksunderaparticularasynchronousflow,whilehavingother

functionsforeachtaskthatweneedtoperformwithinthatcontrolflow.Thetopmostflow

controllingfunctioncouldbeexposedasapublicinterfacemethodforourmodule,buttheonly

partofitthatshouldbetreatedasapublicinterfacearetheparametersthatwereceiveasinputs

forthatfunctionandtheoutputproducedbythatsametopmostfunction.Everythingelse

becomesanimplementationdetailandis,assuch,tobeconsideredswappable.

Theinternalfunctionsofamodulewon’thaveasrigidofaninterfaceeither:aslongasthe

publicinterfaceholds,wecanchangetheimplementation—includingtheinterfacesoffunctions

thatmakeupthatimplementation—howeverwewant.Thisisnottosay,however,thatwe

shouldtreatthoseinterfacesanylessdeliberately.Thekeytopropermodulardesignisinhaving

theutmostrespectforallinterfaces,andthatincludestheinterfacesexposedbyinternal

functions.

Withinfunctions,wealsoneedtocomponentizeaspectsoftheimplementation,givingthose

aspectsanameinthewayoffunctioncalls,deferringcomplexitythatdoesn’tneedtobe

immediatelydealtwithinthemainbodyofthefunctionuntillaterinthereadthroughofagiven

pieceofcode.We’rewritingprogramsthataremeanttobereadableandwritableforother

humansandevenourselvesinthefuture.Virtuallyeveryonewhohasdoneanyamountof

programminghasexperiencedafeelingoffrustrationwhenglancingatapieceofcodethey

themselveswroteafewmonthsprior,onlytolaterrealizethat,withafreshpairofeyes,the

designtheyhadthencomeupwithwasn’tassolidastheyoriginallyintended.

Remember,computerprogramdevelopmentislargelyahumanandcollaborativeendeavor.

We’renotoptimizingforcomputerstorunprogramsasfastaspossible.Ifwewere,we’dbe

writingbinaryorhardcodinglogicintocircuitboards.Instead,ourfocusistoempoweran

organizationsothatitsdeveloperscanremainproductiveandquicklyunderstandandeven

modifypiecesofcodetheyhaven’trunacrossbefore.Workingunderthesoftembraceof

conventionsandpractices,whichplacedevelopersonanevenkeel,closesthatcyclebymaking

surefuturedevelopmentisconsistentwiththewaytheapplicationhastakenshapeupuntilthe

present.

Goingbacktoperformance,weshouldbetreatingitasafeature,andforthemostpartwe

shouldn’tplaceahigherpremiumonitthanwewouldforotherfeatures.Unlessperformance

needstobeadefiningfeatureofoursystemforbusinessreasons,weshouldn’tworryabout

ensuringthatthesystemrunsattopspeedonallcodepaths.Doingsoisboundtoresultin

highlycomplexapplicationsthatarehardtomaintain,debug,extend,andjustify.

We,asdevelopers,oftenoverdoarchitectureaswell,andalotofthereasoningabout

performanceoptimizationapplieshere.Layingoutanallencompassingarchitecturethathasthe

potentialtosaveustroubleaswescaletobillionsoftransactionspersecondmightcostus

considerabletimespentupfrontandpossiblyalsolockusintoaseriesofabstractionsthatwill

behardtokeepupwith,fornoforeseeablegainsinthenearterm.It’salotbetterwhenwefocus

onproblemswe’realreadyrunninginto,ormightsoonruninto,insteadoftryingtoplanfora

hockeystickgrowthofinfrastructureandthroughputwithoutanydatatobackupthehockey

stickgrowthwe’reanticipating.

Whenwedon’tplaninsuchalongtermform,aninterestingthingoccurs:oursystemsgrow

morenaturally,adaptingtotheneedsofthenearterm,graduallyprogressingtowardsupportfor

alargerapplicationandlargersetofrequirements.Whenthatprogressionisgradual,wenoticea

correctivebehaviorinthewayabstractionsarepickedupordiscardedaswegrow.Ifwesettle

onabstractionstooearly,andtheyendupbeingthewrongabstractions,wepaydearlyforthat

mistake.Badabstractionsforceustobendentireapplicationstotheirwill.Afterwe’verealized

thattheabstractionisbadandoughttoberemoved,wemightbesoheavilyinvestedinitthat

pullingoutmightbecostly.This,pairedwiththesunkcostfallacy,wherebywe’retemptedto

keeptheabstractionjustbecausewe’vespentalotoftime,sweat,andbloodonit,canbe

hazardousindeed.

We’lldevoteanimportantpartofthisbooktounderstandinghowtoidentifyandleveragethe

rightabstractionsattherighttimesothattheriskweincurisminimized.

剩余127页未读，继续阅读

tlforest

粉丝: 27
资源: 198

模块化JavaScript实战：打造可读、可维护、可扩展的代码

Mastering Modular Javascript

mastering javascript 电子书

英文原版-Mastering Search Analytics 1st Edition

mastering-avalanche:Mastering Avalanche 1st Edition-金融互联网上的编码

英文原版-Mastering HyperV Deployment 1st Edition

英文原版-Mastering the BMAT 1st Edition

Mastering JavaScript Functional Programming, Second Edition.pdf

Mastering Reactive JavaScript

英文原版-Mastering Microsoft Office Access 2007 Development 1st Edition

Mastering Reactive JavaScript epub

最新资源