Hvordan fremskynder man softwareudvikling med JavaScript?

Definition af hurtig udvikling af applikationer

Udtrykket "hurtig udvikling" kan tolkes på mange forkerte måder. For at undgå det, lad os forklare, hvad vores forventninger er. Den vigtigste ting er budgettet. For at bygge mange versioner af den samme applikation har vi brug for mange udviklere fra forskellige tekniske stakke og for at betale dem alle. For at bygge native mobilapps skal vi duplikere vores Kode til at fungere godt på begge platforme - Android og iOS. En almindelig tilgang er at holde begge applikationer ens, bruge den samme API, opretholde den samme adfærd og så videre. Derfor er vi nødt til at duplikere koden for at bygge to versioner af den samme applikation. JS er et sprog, der giver os mulighed for at bygge mobilapplikationer og webapplikationer på samme tid. Lyder det umuligt? Lad mig forklare, hvad jeg taler om.

Mobil? Web? Jeg er ligeglad.

Lad os sige, at vi vil bygge en applikation, der bruger React-biblioteket. Dette bibliotek kan bruges til at bygge webapplikationer og mobilapplikationer med React native. De logiske mekanismer i applikationen, såsom autorisation, databehandling, filtrering af data og så videre, kan udføres med React-hooks. Pointen er, at disse hooks kan deles af begge versioner af applikationen - web og mobil. Takket være denne mulighed har vi følgende besparelser:

• Der er ingen grund til at duplikere den kode, der er ansvarlig for den samme ting,
• Der er ingen grund til at ansætte indfødte mobiludviklere til at implementere den samme del af applikationerne,
• Der er ingen grund til at blande forskellige sprog for at implementere den samme applikation på tværs af forskellige mobilplatforme (Android/iOS),
• En udvikler kan være ansvarlig for at implementere specifikke applikationsfunktioner på alle platforme.

For at opsummere dette afsnit - det er ikke sådan, at én kodebase vil drive alle versioner af applikationen, selvom vi kan opdele den fælles kode og bruge den i hver enkelt version for at gøre udviklingsprocessen virkelig hurtigere.

Konklusion - hvis du vil bygge en webapplikation og en mobilapplikation på samme tid, bør du overveje React-biblioteket, der kan dele en kodebase i mobil- og webversionen af applikationen.

Men hvad med backend?

For et par år siden, når vi talte om backend, var det nok de færreste, der forestillede sig, at vedligeholdelsen af den kunne ske ved hjælp af et sprog som JS. Udviklingen af dette sprog er fantastisk, og dets frugter kan høstes den dag i dag.

Hvad er det, jeg taler om? Hvis du ansætter den rigtige JS-udviklereDet viser sig, at de ikke kun kan skrive applikationens frontend, men også backend - det vil sige være ansvarlige for behandling af data på serveren, kommunikation med databasen, forskellige typer integrationer osv. Er du stadig tøvende eller ikke overbevist om dette sprog? Der er ingen grund til at have den holdning! Backend ved hjælp af JS kan implementeres på to populære måder - i en udvidelig og konfigurerbar tilstand, som express.js kan give os, og i en struktureret tilstand ved hjælp af DI-mønsteret - nest.js.

Begge løsninger er ekstremt populære og driver mange produktionsapplikationer, hvis ejere er "tech-giganter" i deres branche. Jeg tror, de er modnet nok til at overbevise dig om at vælge en af dem.

Er det stadig ikke nok? I lighed med kodedeling mellem web- og mobilapplikationer kan backend dele ressourcer med både førstnævnte og sidstnævnte. Nøgleordet her er TypeScript - det giver os blandt andet mulighed for at dele en kodebase, dvs. en fælles datatypedefinition mellem alle platforme.

Med applikationer, der udelukkende er bygget på JavaScript / TypeScript Når vi bruger monolith, sparer vi en masse kodelinjer, som vi skulle have kopieret i de oprindelige programmeringssprog. På den anden side kan vi ved at bruge det samme sprog på alle fronter dele en enorm mængde logik mellem alle applikationer, hvilket helt sikkert vil fremskynde den tid, det tager at bygge en bestemt applikation. Lyder det ikke fantastisk?

Kan JS drive desktop-applikationer?

Det viser sig, at teknologier til at bygge browserapplikationer er gode til at vedligeholde de applikationer, som vi bruger i deres desktopform - et godt eksempel her kan være Slack. Slack er en applikation, der bruges til hold kommunikation - ud over standardbeskeder har det mange forskellige funktioner og forskellige typer af eksterne integrationer. Alt dette gør det til en af de mest populære applikationer, der primært bruges i IT-branchen.

Det viser sig, at Slack også bruger webteknologier (og dermed JavaScript) til at opbygge sin applikationsgrænseflade. Det grundlag, der gør det muligt at køre sådanne applikationer på dit skrivebord, er elektron. At skabe grafiske grænseflader ved hjælp af webteknologier gør det meget nemmere, hurtigere og generelt muligt at udvikle applikationer til forskellige platforme på samme tid.

Er JS moden nok?

Når man ser på frontend-delen af applikationen, er der ingen illusion om, at JS er det eneste og eksklusive sprog, der driver økosystemet her. På nuværende tidspunkt er der ingen levedygtige alternativer, der kan erstatte denne del af applikationen (selvom jeg tror, at WebAssembly kan overraske os i fremtiden). Så når vi taler om JS' modenhed på frontend, er der ingen tvivl om, at det er den eneste kongelige.

Når vi taler om backend, kan mange udviklere virke chokerede eller straks benægte, at JS er egnet som programmeringssprog i backend. Men sagen skal analyseres objektivt.

Masser af cloud-udbydere leverer SDK'er, der giver dig mulighed for direkte at bruge sky metoder. Mærkeligt nok er en af de mest populære faner, lige ved siden af C#, Go and Java, er Node.js. Det viser sig, at denne platform er ideel til skalering og opbygning af applikationer baseret på mikrotjenester eller serverløs arkitektur. Konklusion - JS er et af de mest populære sprog til udvikling af applikationer baseret på mikrotjenester/serverløs arkitektur. På skærmbillederne nedenfor kan vi se, at den hellige treenighed (Google Computing Services, AWS, Azure) af cloud-udbydere giver os mulighed for at bygge applikationer ved hjælp af Knudepunkt.js.

Hvad angår node.js-økosystemet, er alle sikkert bekendt med et bibliotek, der hedder express.js - det er et enkelt og ligetil værktøj, der giver dig mulighed for at definere stier og derefter fodre dem med passende data, der er blevet behandlet korrekt på JS-siden. Desuden er det mønster, der bruges blandt HTTP-anmodninger, der håndteres i express.js, blevet et af de mest populære i hele økosystemet og er en slags mønster for forskellige andre biblioteker, der f.eks. bruger serverløs arkitektur.

Konklusion - JS er et sprog, der er modent nok til at lægge alle kortene på bordet og bygge både frontend og backend. Derudover er det et ret nyt sprog, der let finder vej ind i moderne applikationsarkitekturer. Det er fantastisk, at en programmør, der kan ét sprog, kan mestre begge sider (full stack) af en applikation.

Er JS hurtig nok?

Den motor, der oftest bruges til at afvikle JS-kode, er v8, der drives af C++-sprog. Denne motor er udviklet af Google og er dedikeret til at køre applikationer til webplatforme. En interessant ting er, at denne motor ikke fortolker JS-koden. I stedet udfører den det, der kaldes "JIT" - "just in time compilation". Takket være det behøver vi ikke at fortolke JS-koden linje for linje, vi kompilerer den bare og afvikler den. Det er endnu hurtigere og giver os virkelig gode resultater.

Er JS fair nok, når det gælder performance? Ja, det er det. Så længe du holder dine algoritmer fair nok, er det ikke noget problem at bruge JS på serversiden. Den anden ting er at holde din kode så asynkron, som den kan være. Med disse fremgangsmåder kan din kode håndtere parallelle forespørgsler uden problemer. Du behøver ikke at bekymre dig om teknologibyttet på grund af ydeevnen - især ikke, når applikationens arkitektur er skalerbar.

Jeg har allerede diskuteret ydeevne og benchmarks i detaljer i denne artikel.

Er JS ikke sådan en særhed blandt andre sprog?

Der er masser af meninger om, at JS-sproget opfører sig underligt i nogle tilfælde, og at håndteringen af det er noget, der vil få dit hoved til at eksplodere under udviklingsprocessen. Jeg er ikke enig 🙂 Ligesom alle andre sprog har det flere mønstre/adfærd, der ikke er elegante, men med en forståelse af, hvordan de fungerer, og hvad deres mål er, er det ikke ubehageligt at udvikle applikationer med JS.

Især bemærkningen om "asynkron" lige før JS får nogle udviklere til at ryste i bukserne. Det er svært at forstå, når man ikke har erfaring med det. Men det er en del af JS, som giver os mulighed for at bygge moderne løsninger på en nem måde. Lad os se på websockets: Da de er begivenhedsbaserede, kan hver af de forbundne enheder - brugeren og serveren - udsende og modtage begivenheder parallelt. Hvis koden, der driver denne app, er asynkron nok og ikke blokerer hovedtråden, kan vi nemt håndtere tusindvis af anmodninger på kort tid.

Lad os sammenligne JS og PHP i forbindelse med websockets. PHP er et synkront programmeringssprog, så at løse websocket-emner giver en enorm hovedpine. Vi kan se, at PHP får mønstre fra JS til at bygge interaktive backend-applikationer, der kan bruge moderne teknologier, såsom webrtc eller websockets.

Bland det hele sammen

Når vi samler alle afsnittene, kan vi konstatere et par fakta:

JavaScript er et sprog, der kan bruges til at bygge alle slags applikationer - fra web, til mobil, til desktop;
Programmer skrevet i JS kan dele forskellige kodefragmenter med hinanden, f.eks. dem, der er ansvarlige for dataformatering eller typer i Typescript;
Takket være væksten på nettet er den ydeevne, som JS tilbyder, god nok til at vælge både frontend- og backend-applikationsudvikling;
Takket være sit usædvanlige design er JavaScript i stand til at understøtte moderne applikationsinfrastrukturer, såsom websockets og WebRTC;
Ved at hyre en dygtig udvikler kan du udnytte dets potentiale på alle tilgængelige frontends, der driver dette sprog;
JS er et sprog, der har været på vej op ad popularitetslisterne i flere år nu, og der er ingen tegn på, at det vil ændre sig på nogen måde.

For at give min ganske vist forudindtagede mening - at udnytte JavaScript's mulighed for at genbruge den samme kode på alle tilgængelige fronter er noget, der helt sikkert vil fremskynde applikationsudviklingen og reducere antallet af udviklere, der er involveret i at vedligeholde backend af applikationer, der er skrevet i andre teknologier. Lad os som en bekræftelse huske på, at et stort antal såkaldte IT-giganter følger dette mønster og deler en hel del kodebase på tværs af platforme. På trods af forskellige meninger om dette sprog skal man tage højde for, at statistikkerne over brugen og tilfredsheden med brugen af JS vokser fra år til år, og dens udviklere kan nemt koble sig på trenden med full stack.

Læs mere om det:

Hvorfor du (sandsynligvis) bør bruge Typescript

Hvordan dræber man ikke et projekt med dårlig kodningspraksis?

Strategier for at hente data i NextJS