Moien Frënn. An der Erwaardung vum Start vum Cours , traditionell mat Iech d'Iwwersetzung vun nëtzlecht Material deelen.
Software léist ëmmer méi alldeeglech Aufgaben, a gëtt ëmmer méi komplex. Wéi de Marc Andressen eemol gesot huet, et verbraucht d'Welt.
Als Resultat huet d'Art a Weis wéi Uwendungen entwéckelt a geliwwert ginn an de leschte Joeren dramatesch geännert. Dëst waren Verréckelung vun tektonesche Skala, déi zu enger Rei vu Prinzipien gefouert hunn. Dës Prinzipien hu sech als hëllefräich bewisen am Teambuilding, Design, Entwécklung an Liwwerung vun Ärer Applikatioun un Endbenotzer.
D'Prinzipien kënne wéi follegt zesummegefaasst ginn: d'Applikatioun soll kleng sinn, web-baséiert, an hunn eng Entwéckler-centric Architektur. Mat dësen dräi Prinzipien am Kapp, kënnt Dir eng robust, end-to-end Applikatioun erstellen déi séier a sécher un den Endbenotzer geliwwert ka ginn, an einfach skalierbar an erweiterbar ass.
Jiddereng vun den proposéierte Prinzipien huet eng Rei vun Aspekter, déi mir diskutéieren fir ze weisen, wéi all Prinzip zum ultimativen Zil bäidréit, dat ass déi séier Liwwerung vun zouverléissege Applikatiounen, déi einfach ze pflegen an ze benotzen. Mir wäerten d'Prinzipien a Relatioun zu hire Géigewier kucken fir ze klären wat et heescht, sot: "Vergewëssert Iech datt Dir benotzt Klengegkeet Prinzip".
Mir hoffen, datt dësen Artikel Iech encouragéiert déi proposéiert Prinzipien ze benotzen fir modern Uwendungen ze bauen, déi eng vereenegt Approche fir Design am Kontext vun engem ëmmer wuessende Technologiestack ubidden.
Andeems Dir dëse Prinzipien applizéiert, fannt Dir Iech vun den neisten Trends an der Softwareentwécklung profitéieren, dorënner de fir d'Entwécklung an d'Liwwerung vun Uwendungen, d'Benotzung vu Container (zum Beispill, ) a Container Orchestratioun Kaderen (zum Beispill, ), d'Benotzung vu Mikroservicer (inklusiv der Microservice Architecture и fir Mikroservice Uwendungen.
Wat ass eng modern Applikatioun?
Modern Applikatiounen? Moderne Stack? Wat genee heescht "modern"?
Déi meescht Entwéckler hunn nëmmen eng allgemeng Iddi vu wat eng modern Applikatioun besteet, also ass et néideg dëst Konzept kloer ze definéieren.
Eng modern App ënnerstëtzt verschidde Clienten, egal ob et eng React JavaScript Bibliothéik User Interface ass, eng Android oder iOS mobil App, oder eng App déi mat enger anerer API verbënnt. Eng modern Applikatioun implizéiert eng onbestëmmten Zuel vu Clienten fir déi se Daten oder Servicer ubitt.
Eng modern Applikatioun bitt eng API fir Zougang zu den ugefrote Donnéeën a Servicer. D'API soll onverännerbar a konstant sinn, an net speziell fir eng spezifesch Ufro vun engem spezifesche Client geschriwwe ginn. D'API ass verfügbar iwwer HTTP(S) a bitt Zougang zu all Funktionalitéit verfügbar am GUI oder CLI.
D'Donnéeë mussen an engem allgemeng akzeptéierten, interoperablen Format wéi JSON verfügbar sinn. Eng API exponéiert Objeten a Servicer op eng propper, organiséiert Manéier, wéi RESTful API oder GraphQL bitt eng anstänneg Interface.
Modern Uwendungen sinn um modernen Stack gebaut, an de modernen Stack ass de Stack deen esou Uwendungen ënnerstëtzt, respektiv. Dëse Stack erlaabt en Entwéckler einfach eng Applikatioun mat engem HTTP-Interface a kloer API Endpunkte ze kreéieren. Déi gewielte Approche erlaabt Är Uwendung einfach Daten am JSON Format ze kréien an ze schécken. An anere Wierder, entsprécht de modernen Stack d'Elementer vun der Zwielef-Factor Applikatioun fir .
Populär Versioune vun dëser Zort Stack baséiert op , , , , и . Microservice Architektur duerstellt e Beispill vun engem modernen Stack an all eenzel vun de genannte Sproochen ëmgesat.
Maacht weg datt mir net eng exklusiv Mikroservice Approche plädéieren. Vill vun iech schaffe mat Monolithen déi sech musse entwéckelen, während anerer sech mat SOA Uwendungen beschäftegen déi sech ausdehnen an evoluéieren fir Mikroservice Uwendungen ze ginn. Nach anerer réckelen op Serverlos Uwendungen, an e puer implementéiere Kombinatioune vun den uewe genannten. D'Prinzipien, déi am Artikel duergestallt ginn, gëllen fir all eenzel vun dëse Systemer mat nëmmen e puer kleng Ännerungen.
Grondsätz
Elo datt mir e gemeinsame Verständnis hunn wat eng modern Applikatioun a modernen Stack sinn, ass et Zäit fir an d'Architektur an d'Entwécklungsprinzipien ze dauchen, déi Iech gutt bei der Entwécklung, der Ëmsetzung an der Ënnerhalt vun enger moderner Applikatioun déngen.
Ee vun de Prinzipien kléngt wéi "kleng Applikatiounen maachen", ruffe mer et einfach Klengheet Prinzip. Et ginn onheemlech komplex Uwendungen déi aus ville bewegt Deeler besteet. Am Tour, eng Applikatioun aus klengen, diskrete Komponenten ze bauen mécht et méi einfach ze designen, ze pflegen an ze schaffen als Ganzt. (Notéiert datt mir gesot hunn "vereinfacht" net "einfach mécht").
Den zweete Prinzip ass datt mir d'Entwécklerproduktivitéit erhéijen kënnen andeems se hinnen hëllefen op d'Features ze fokusséieren déi se entwéckelen, wärend se vun Infrastrukturen an CI / CD Bedenken während der Implementatioun befreien. Also, an enger Nossschuel, eis Approche op Entwéckler konzentréiert.
Schlussendlech muss alles iwwer Är Applikatioun mam Netz verbonne sinn. An de leschten 20 Joer hu mir grouss Schrëtt a Richtung vernetzt Zukunft gemaach well Netzwierker méi séier ginn an Uwendungen méi komplex ginn. Wéi mir scho gesinn hunn, muss eng modern Applikatioun iwwer e Netzwierk vu ville verschiddene Clienten benotzt ginn. Netzdenken op d'Architektur applizéieren huet bedeitend Virdeeler déi gutt matmaachen Klengheet Prinzip an d'Konzept vun der Approche, Entwéckler orientéiert.
Wann Dir dës Prinzipien am Kapp behält wann Dir eng Applikatioun designt an ëmsetzt, hutt Dir en onbestreidege Virdeel an der Entwécklung an der Liwwerung vun Ärem Produkt.
Loosst eis dës dräi Prinzipien méi detailléiert kucken.
Klengegkeet Prinzip
Et ass schwéier fir de mënschleche Gehir eng grouss Quantitéit un Informatioun zur selwechter Zäit ze gesinn. An der Psychologie bezitt de Begrëff kognitiv Belaaschtung op de Gesamtbetrag u mentaler Ustrengung déi néideg ass fir Informatioun an der Erënnerung ze halen. D'Reduktioun vun der kognitiver Belaaschtung op Entwéckler ass eng Prioritéit, well et hinnen erlaabt sech op d'Léisung vum Problem ze fokusséieren anstatt den aktuellen komplexe Modell vun der ganzer Applikatioun an de Fonctiounen an hirem Kapp ze halen.
Uwendungen zerstéieren aus de folgende Grënn:
- Reduzéiert kognitiv Belaaschtung op Entwéckler;
- Beschleunegung an Vereinfachung vum Test;
- Schnell Liwwerung vun Ännerungen an der Applikatioun.
Et gi verschidde Weeër fir d'kognitiv Laascht op d'Entwéckler ze reduzéieren, an dat ass wou de Prinzip vun der Klengheet an d'Spill kënnt.
Also hei sinn dräi Weeër fir kognitiv Belaaschtung ze reduzéieren:
- Reduzéieren den Zäitframe, dee se musse berücksichtegen wann se eng nei Feature entwéckelen - wat méi kuerz ass den Zäitframe, dest manner kognitiv Belaaschtung.
- Reduzéieren de Betrag vum Code op deem eng Kéier Aarbecht duerchgefouert gëtt - manner Code - manner Belaaschtung.
- Vereinfacht de Prozess fir inkrementell Ännerunge fir eng Applikatioun ze maachen.
Reduktioun vun der Entwécklung Zäitframe
Komme mer zréck op d'Deeg wou d'Methodologie waterfall war de Standard fir den Entwécklungsprozess, an Zäitframe vu sechs Méint bis zwee Joer fir eng Applikatioun z'entwéckelen oder ze aktualiséieren waren allgemeng Praxis. Typesch wäerten Ingenieuren als éischt relevant Dokumenter liesen wéi d'Produktfuerderunge (PRD), System Referenzdokument (SRD), Architektur Blueprint, a fänken un all dës Saachen zesummen an ee kognitiven Modell ze kombinéieren, no deem se kodéiert hunn. Wéi d'Ufuerderungen an doduerch d'Architektur geännert hunn, huet e seriöse Effort misse gemaach ginn fir d'ganz Team iwwer Updates vum kognitiven Modell z'informéieren. Esou eng Approche kéint am schlëmmste Fall d'Aarbecht einfach paralyséieren.
Déi gréissten Ännerung am Applikatiounsentwécklungsprozess war d'Aféierung vun der agile Methodologie. Ee vun den Haaptmerkmale vun der Methodik agile ass eng iterativ Entwécklung. Am Tour féiert dëst zu enger Reduktioun vun der kognitiver Belaaschtung op Ingenieuren. Amplaz d'Entwécklungsteam ze erfuerderen d'Applikatioun an engem laangen Zyklus ëmzesetzen, agile Approche erlaabt Iech op kleng Quantitéiten vu Code ze konzentréieren, déi séier getest an ofgesat kënne ginn, wärend Dir och Feedback kritt. D'kognitiv Belaaschtung vun der App ass vun engem sechs Méint op zwee Joer Zäitframe verréckelt mat enger enormer Quantitéit u Spezifikatioune fir eng zwou Woche Add- oder Feature-Ännerung zielt op e méi verschwonnt Verständnis vun enger grousser App.
De Fokus vun enger massiver Applikatioun op spezifesch kleng Features ze wiesselen, déi an engem Sprint vun zwou Wochen ofgeschloss kënne ginn, mat net méi wéi eng Feature virum nächste Sprint am Kapp, ass eng bedeitend Ännerung. Dëst huet eis erlaabt d'Entwécklungsproduktivitéit ze erhéijen an d'kognitiv Belaaschtung ze reduzéieren, déi stänneg schwankt.
An der Methodik agile déi lescht Applikatioun gëtt erwaart eng liicht modifizéiert Versioun vum originelle Konzept ze sinn, sou datt den Endpunkt vun der Entwécklung onbedéngt zweedeiteg ass. Nëmmen d'Resultater vun all spezifesche Sprint kënne kloer a präzis sinn.
Kleng Codebasen
De nächste Schrëtt fir kognitiv Belaaschtung ze reduzéieren ass d'Codebase ze reduzéieren. In der Regel sinn modern Uwendungen massiv - eng robust Enterprise-Applikatioun kann aus Dausende vu Dateien an Honnerte vun Dausende vu Codelinn besteet. Ofhängeg wéi d'Dateie organiséiert sinn, kënnen d'Links an d'Ofhängegkeeten tëscht Code a Dateien offensichtlech sinn, oder vice versa. Och Debugging Code Ausféierung selwer ka problematesch sinn, ofhängeg vun de benotzte Bibliothéiken a wéi gutt d'Debugging Tools tëscht Bibliothéiken / Packagen / Moduler a personaliséierte Code ënnerscheeden.
Bauen vun engem funktionnéierende mentale Modell vum Code vun enger Applikatioun kann beandrockend Zäit daueren, an nach eng Kéier eng grouss kognitiv Belaaschtung op den Entwéckler setzen. Dëst ass besonnesch wouer fir monolithesch Codebasen, wou et eng grouss Quantitéit vu Code gëtt, d'Interaktioun tëscht de funktionnelle Komponenten vun deenen net kloer definéiert ass, an d'Trennung vun Opmierksamkeetsobjekter ass dacks verschwonn well funktionell Grenzen net respektéiert ginn.
Ee vun den effektiven Weeër fir d'kognitiv Belaaschtung op Ingenieuren ze reduzéieren ass op eng Mikroservicearchitektur ze plënneren. An enger Mikroservice Approche fokusséiert all Service op eng Rei vu Funktiounen; während d'Bedeitung vum Service normalerweis definéiert a verständlech ass. D'Grenze vun engem Service sinn och kloer - denkt drun datt d'Kommunikatioun mat engem Service iwwer eng API gemaach gëtt, sou datt Daten, déi vun engem Service generéiert ginn, einfach un en aneren weiderginn.
Interaktioun mat anere Servicer ass normalerweis limitéiert op e puer Benotzer Servicer an e puer Provider Servicer déi einfach a propper API Uriff benotzen, wéi REST benotzen. Dëst bedeit datt d'kognitiv Belaaschtung op den Ingenieur eescht reduzéiert gëtt. Déi gréissten Erausfuerderung bleift de Service Interaktiounsmodell ze verstoen a wéi Saachen wéi Transaktiounen iwwer verschidde Servicer geschéien. Als Resultat reduzéiert d'Benotzung vu Mikroservicer kognitiv Belaaschtung andeems d'Quantitéit vum Code reduzéiert gëtt, kloer Servicegrenzen definéiert an e Verständnis vun der Bezéiung tëscht Benotzer a Fournisseuren ubitt.
Kleng inkrementell Ännerungen
Déi lescht Element vum Prinzip Klengegkeet ass Changement Management. Et ass eng besonnesch Versuchung fir Entwéckler d'Codebasis ze kucken (och vläicht hiren eegene, eelere Code) a soen: "Dëst ass Schrecken, mir mussen alles iwwerschreiwe." Heiansdo ass dat déi richteg Entscheedung, an heiansdo net. Et setzt d'Belaaschtung vun der globaler Modellännerung op d'Entwécklungsteam, wat am Tour zu enger massiver kognitiver Belaaschtung féiert. Et ass besser fir d'Ingenieuren sech op d'Verännerungen ze konzentréieren, déi se während dem Sprint maache kënnen, sou datt se déi néideg Funktionalitéit op eng fristgerecht Manéier ausrollen, och wann se graduell. D'Finale Produit soll de pre-geplangten eent ähnelen, awer mat e puer Ännerungen an Tester fir de Client seng Besoinen ze Kostüm.
Wann Dir grouss Portioune vu Code nei schreift, ass et heiansdo net méiglech d'Ännerung séier ze liwweren, well aner Systemabhängegkeeten an d'Spill kommen. Fir de Flux vun Ännerungen ze kontrolléieren, kënnt Dir Feature verstoppen benotzen. Am Prinzip heescht dat datt d'Funktionalitéit an der Produktioun ass, awer et ass net verfügbar mat den Ëmfeldvariabelen Astellungen (env-var) oder en aneren Konfiguratiounsmechanismus. Wann de Code all Qualitéitskontrollprozesser passéiert huet, da kann et an der Produktioun an engem latenten Zoustand ophalen. Wéi och ëmmer, dës Strategie funktionnéiert nëmme wann d'Feature schlussendlech aktivéiert ass. Soss wäert et nëmmen de Code räissen an eng kognitiv Belaaschtung addéieren, déi den Entwéckler muss këmmeren fir produktiv ze sinn. Ännerungsmanagement an inkrementell Ännerungen selwer hëllefen d'kognitiv Belaaschtung vun den Entwéckler op engem bezuelbare Niveau ze halen.
Ingenieuren mussen vill Schwieregkeeten iwwerwannen och mat der einfacher Aféierung vun zousätzlech Funktionalitéit. Op der Säit vun der Gestioun wier et virsiichteg déi onnéideg Belaaschtung op d'Team ze reduzéieren, sou datt et op Schlësselfunktionell Elementer konzentréiere kann. Et ginn dräi Saachen déi Dir maache kënnt fir Äert Entwécklungsteam ze hëllefen:
- Benotzt Methodik
agilefir den Zäitframe ze limitéieren an deem d'Team op Schlësselfeatures fokusséiere muss. - Implementéiert Är Applikatioun als Multiple Mikroservicer. Dëst wäert d'Zuel vun de Fonctiounen limitéieren, déi implementéiert kënne ginn an d'Grenze verstäerken, déi d'kognitiv Laascht op der Aarbecht halen.
- Virléift inkrementell Ännerungen iwwer grouss an ongewollt, änneren kleng Stécker vum Code. Benotzt Feature verstoppt fir Ännerungen ëmzesetzen och wa se net direkt sichtbar sinn nodeems se se derbäigesat hunn.
Wann Dir de Prinzip vun der Klengheet an Ärer Aarbecht applizéiert, wäert Äert Team vill méi glécklech sinn, besser fokusséiert op d'Ëmsetzung vun den néidege Funktiounen a méi wahrscheinlech qualitativ Ännerungen méi séier auszerollen. Awer dat heescht net datt d'Aarbecht net méi komplizéiert ka ginn, heiansdo, am Géigendeel, erfuerdert d'Aféierung vun neie Funktionalitéit d'Modifikatioun vu verschiddene Servicer, an dëse Prozess kann méi schwéier sinn wéi ähnlech an enger monolithescher Architektur. Op alle Fall sinn d'Virdeeler vun der Klengheet Approche wäert et.
Enn vum éischten Deel.
Geschwënn wäerte mir den zweeten Deel vun der Iwwersetzung publizéieren, an elo waarden mir op Är Kommentaren an invitéieren Iech op , déi haut um 20.00 Auer stattfënnt.
Source: will.com