Bună prieteni. În așteptarea lansării cursului , împărtășesc în mod tradițional cu dvs. traducerea materialului util.
Software-ul rezolvă tot mai multe sarcini de zi cu zi, devenind tot mai complex. După cum a spus odată Marc Andressen, consumă lumea.
Ca urmare, modul în care sunt dezvoltate și livrate aplicațiile s-a schimbat dramatic în ultimii câțiva ani. Acestea au fost schimbări de scară tectonă care au dus la un set de principii. Aceste principii s-au dovedit a fi utile în formarea echipei, proiectarea, dezvoltarea și livrarea aplicației dvs. către utilizatorii finali.
Principiile pot fi rezumate după cum urmează: aplicația ar trebui să fie mică, bazată pe web și să aibă o arhitectură centrată pe dezvoltatori. Având în vedere aceste trei principii, puteți crea o aplicație robustă, end-to-end, care poate fi livrată rapid și sigur utilizatorului final și este ușor scalabilă și extensibilă.
Fiecare dintre principiile propuse are o serie de aspecte pe care le vom discuta pentru a arăta modul în care fiecare principiu contribuie la scopul final, care este livrarea rapidă a aplicațiilor fiabile, ușor de întreținut și de utilizat. Ne vom uita la principii în relație cu contrariile lor pentru a clarifica ce înseamnă, să spunem: „Asigură-te că folosești principiul micimii".
Sperăm că acest articol vă va încuraja să utilizați principiile propuse pentru construirea de aplicații moderne, care vor oferi o abordare unificată a proiectării în contextul unei stive de tehnologie în continuă creștere.
Aplicând aceste principii, vă veți descoperi că profitați de cele mai recente tendințe în dezvoltarea de software, inclusiv la dezvoltarea și livrarea de aplicații, utilizarea containerelor (de exemplu, ) și cadre de orchestrare a containerelor (de exemplu, ), utilizarea microserviciilor (inclusiv Arhitectura de microservicii и pentru aplicații de microservicii.
Ce este o aplicație modernă?
Aplicații moderne? Stivă modernă? Ce înseamnă mai exact „modern”?
Majoritatea dezvoltatorilor au doar o idee generală în ce constă o aplicație modernă, așa că este necesar să se definească clar acest concept.
O aplicație modernă acceptă mai mulți clienți, fie că este o interfață de utilizator a bibliotecii JavaScript React, o aplicație mobilă Android sau iOS sau o aplicație care se conectează la un alt API. O aplicație modernă presupune un număr nedefinit de clienți pentru care furnizează date sau servicii.
O aplicație modernă oferă un API pentru a accesa datele și serviciile solicitate. API-ul ar trebui să fie imuabil și constant și să nu fie scris special pentru o anumită solicitare de la un anumit client. API-ul este disponibil prin HTTP(S) și oferă acces la toate funcționalitățile disponibile în GUI sau CLI.
Datele trebuie să fie disponibile într-un format comun acceptat, interoperabil, cum ar fi JSON. Un API expune obiecte și servicii într-un mod curat, organizat, cum ar fi RESTful API sau GraphQL oferă o interfață decentă.
Aplicațiile moderne sunt construite pe stiva modernă, iar stiva modernă este stiva care acceptă astfel de aplicații. Această stivă permite unui dezvoltator să creeze cu ușurință o aplicație cu o interfață HTTP și puncte finale API clare. Abordarea aleasă va permite aplicației dvs. să primească și să trimită cu ușurință date în format JSON. Cu alte cuvinte, stiva modernă corespunde elementelor aplicației cu doisprezece factori pentru .
Versiunile populare ale acestui tip de stivă se bazează pe , , , , и . Arhitectura de microservicii reprezintă un exemplu de stivă modernă implementată în fiecare dintre limbile menționate.
Vă rugăm să rețineți că nu susținem o abordare exclusiv cu microservicii. Mulți dintre voi lucrați cu monoliți care trebuie să evolueze, în timp ce alții au de-a face cu aplicații SOA care se extind și evoluează pentru a deveni aplicații de microservicii. Alții se îndreaptă către aplicații fără server, iar unii implementează combinații ale celor de mai sus. Principiile prezentate în articol se aplică fiecăruia dintre aceste sisteme cu doar câteva modificări minore.
Principii
Acum că avem o înțelegere comună a ceea ce sunt o aplicație modernă și o stivă modernă, este timpul să ne aprofundăm în arhitectura și principiile de dezvoltare care vă vor fi de folos în dezvoltarea, implementarea și întreținerea unei aplicații moderne.
Unul dintre principii sună ca „a face aplicații mici”, să-i spunem principiul micimii. Există aplicații incredibil de complexe care sunt alcătuite din multe părți mobile. La rândul său, construirea unei aplicații din componente mici și discrete facilitează proiectarea, întreținerea și lucrul cu ea ca întreg. (Rețineți că am spus „simplifica” nu „face simplu”).
Al doilea principiu este că putem crește productivitatea dezvoltatorilor, ajutându-i să se concentreze pe caracteristicile pe care le dezvoltă, eliberându-i în același timp de preocupările legate de infrastructură și CI/CD în timpul implementării. Deci, pe scurt, abordarea noastră concentrat pe dezvoltatori.
În cele din urmă, totul despre aplicația dvs. trebuie să fie conectat la rețea. În ultimii 20 de ani, am făcut pași mari către un viitor în rețea, pe măsură ce rețelele devin mai rapide și aplicațiile mai complexe. După cum am văzut, o aplicație modernă trebuie utilizată într-o rețea de mulți clienți diferiți. Aplicarea gândirii de rețea la arhitectură are beneficii semnificative care merg bine cu principiul micimii și conceptul de abordare, orientat spre dezvoltator.
Dacă țineți cont de aceste principii atunci când proiectați și implementați o aplicație, veți avea un avantaj incontestabil în dezvoltarea și livrarea produsului dumneavoastră.
Să ne uităm la aceste trei principii mai detaliat.
Principiul micimii
Este dificil pentru creierul uman să perceapă o cantitate mare de informații în același timp. În psihologie, termenul de încărcare cognitivă se referă la cantitatea totală de efort mental necesară pentru a păstra informația în memorie. Reducerea încărcăturii cognitive asupra dezvoltatorilor este o prioritate deoarece le permite să se concentreze pe rezolvarea problemei în loc să păstreze în cap modelul complex actual al întregii aplicații și caracteristicile dezvoltate.
Aplicațiile se descompun din următoarele motive:
- Reducerea sarcinii cognitive asupra dezvoltatorilor;
- Accelerarea și simplificarea testării;
- Livrarea rapidă a modificărilor în aplicație.
Există mai multe modalități de a reduce încărcătura cognitivă asupra dezvoltatorilor și aici intervine principiul micimii.
Deci, iată trei moduri de a reduce încărcătura cognitivă:
- Reduceți intervalul de timp pe care trebuie să îl ia în considerare atunci când dezvoltă o nouă caracteristică - cu cât intervalul de timp este mai scurt, cu atât sarcina cognitivă este mai mică.
- Reduceți cantitatea de cod pentru care se efectuează o muncă unică - mai puțin cod - mai puțină sarcină.
- Simplificați procesul de a face modificări incrementale la o aplicație.
Reducerea intervalului de timp de dezvoltare
Să ne întoarcem la vremurile când metodologia waterfall a fost standardul pentru procesul de dezvoltare, iar intervalele de timp de șase luni până la doi ani pentru dezvoltarea sau actualizarea unei aplicații erau o practică obișnuită. De obicei, inginerii citeau mai întâi documentele relevante, cum ar fi cerințele produsului (PRD), documentul de referință al sistemului (SRD), modelul de arhitectură și începeau să combine toate aceste lucruri într-un singur model cognitiv, conform căruia au codificat. Pe măsură ce cerințele și, în consecință, arhitectura s-au schimbat, a trebuit depus un efort serios pentru a informa întreaga echipă despre actualizările modelului cognitiv. O astfel de abordare, în cel mai rău caz, ar putea pur și simplu paraliza munca.
Cea mai mare schimbare în procesul de dezvoltare a aplicațiilor a fost introducerea metodologiei agile. Una dintre principalele caracteristici ale metodologiei agile este o dezvoltare iterativă. La rândul său, acest lucru duce la o reducere a sarcinii cognitive asupra inginerilor. În loc să solicite echipei de dezvoltare să implementeze aplicația într-un ciclu lung, agile abordarea vă permite să vă concentrați pe cantități mici de cod care pot fi testate și implementate rapid, primind în același timp feedback. Sarcina cognitivă a aplicației s-a schimbat de la un interval de timp de șase luni la doi ani, cu o cantitate uriașă de specificații pentru o adăugare de două săptămâni sau o modificare a caracteristicilor care vizează o înțelegere mai neclară a unei aplicații mari.
Schimbarea atenției de la o aplicație masivă la caracteristici mici specifice care pot fi finalizate într-un sprint de două săptămâni, cu nu mai mult de o funcție înainte de următorul sprint în minte, este o schimbare semnificativă. Acest lucru ne-a permis să creștem productivitatea dezvoltării, reducând în același timp încărcătura cognitivă, care a fluctuat constant.
În metodologie agile se așteaptă ca aplicația finală să fie o versiune ușor modificată a conceptului original, astfel încât punctul final al dezvoltării este neapărat ambiguu. Doar rezultatele fiecărui sprint specific pot fi clare și precise.
Baze de coduri mici
Următorul pas în reducerea sarcinii cognitive este reducerea bazei de cod. De regulă, aplicațiile moderne sunt masive - o aplicație robustă, de întreprindere, poate consta din mii de fișiere și sute de mii de linii de cod. În funcție de modul în care sunt organizate fișierele, legăturile și dependențele dintre cod și fișiere pot fi evidente sau invers. Chiar și execuția codului de depanare în sine poate fi problematică, în funcție de bibliotecile utilizate și de cât de bine disting instrumentele de depanare între biblioteci/pachete/module și codul personalizat.
Construirea unui model mental funcțional al codului unei aplicații poate dura o perioadă impresionantă de timp și poate pune din nou o povară cognitivă mare asupra dezvoltatorului. Acest lucru este valabil mai ales pentru bazele de coduri monolitice, unde există o cantitate mare de cod, a cărui interacțiune între componentele funcționale nu este clar definită, iar separarea obiectelor de atenție este adesea estompată, deoarece granițele funcționale nu sunt respectate.
Una dintre modalitățile eficiente de a reduce sarcina cognitivă a inginerilor este trecerea la o arhitectură de microservicii. Într-o abordare cu microservicii, fiecare serviciu se concentrează pe un set de caracteristici; în timp ce sensul serviciului este de obicei definit și de înțeles. Limitele unui serviciu sunt, de asemenea, clare - rețineți că comunicarea cu un serviciu se face prin intermediul unui API, astfel încât datele generate de un serviciu pot fi transmise cu ușurință altuia.
Interacțiunea cu alte servicii este de obicei limitată la câteva servicii de utilizator și la câteva servicii de furnizor care utilizează apeluri API simple și curate, cum ar fi utilizarea REST. Aceasta înseamnă că sarcina cognitivă asupra inginerului este redusă serios. Cea mai mare provocare rămâne înțelegerea modelului de interacțiune cu serviciile și modul în care se întâmplă lucruri precum tranzacțiile în mai multe servicii. Ca rezultat, utilizarea microserviciilor reduce sarcina cognitivă prin reducerea cantității de cod, definirea limitelor clare ale serviciilor și oferirea unei înțelegeri a relației dintre utilizatori și furnizori.
Mici modificări incrementale
Ultimul element al principiului micime este managementul schimbării. Este o tentație deosebită pentru dezvoltatori să se uite la baza de cod (chiar poate chiar și pe propriul lor, mai vechi cod) și să spună: „Acesta este o prostie, trebuie să rescriem totul”. Uneori aceasta este decizia corectă, iar alteori nu. Pune povara schimbării globale a modelului asupra echipei de dezvoltare, care, la rândul său, duce la o încărcare cognitivă masivă. Este mai bine ca inginerii să se concentreze asupra modificărilor pe care le pot face în timpul sprintului, astfel încât să poată implementa funcționalitatea necesară în timp util, chiar dacă treptat. Produsul final trebuie să semene cu cel planificat în prealabil, dar cu unele modificări și teste pentru a se potrivi nevoilor clientului.
Când rescrieți porțiuni mari de cod, uneori nu este posibil să livrați rapid schimbarea, deoarece alte dependențe de sistem intră în joc. Pentru a controla fluxul de modificări, puteți utiliza ascunderea caracteristicilor. În principiu, aceasta înseamnă că funcționalitatea este în producție, dar nu este disponibilă folosind setările variabilei de mediu (env-var) sau alt mecanism de configurare. Dacă codul a trecut toate procesele de control al calității, atunci acesta poate ajunge în producție într-o stare latentă. Cu toate acestea, această strategie funcționează numai dacă funcția este în cele din urmă activată. În caz contrar, va aglomera codul și va adăuga o încărcătură cognitivă cu care dezvoltatorul va trebui să se confrunte pentru a fi productiv. Gestionarea schimbărilor și schimbările incrementale în sine ajută la menținerea sarcinii cognitive a dezvoltatorilor la un nivel accesibil.
Inginerii trebuie să depășească multe dificultăți chiar și cu simpla introducere a funcționalităților suplimentare. Din partea managementului, ar fi prudent să se reducă sarcina inutilă a echipei, astfel încât aceasta să se poată concentra asupra elementelor funcționale cheie. Există trei lucruri pe care le puteți face pentru a vă ajuta echipa de dezvoltare:
- Folosiți metodologia
agilepentru a limita intervalul de timp în care echipa trebuie să se concentreze asupra caracteristicilor cheie. - Implementați aplicația dvs. ca mai multe microservicii. Acest lucru va limita numărul de caracteristici care pot fi implementate și va consolida granițele care mențin sarcina cognitivă la lucru.
- Preferați modificările incrementale decât mari și greoaie, schimbați bucăți mici de cod. Utilizați ascunderea caracteristicilor pentru a implementa modificări, chiar dacă acestea nu vor fi vizibile imediat după ce au fost adăugate.
Dacă aplicați principiul micii în munca dvs., echipa dvs. va fi mult mai fericită, mai bine concentrată pe implementarea caracteristicilor necesare și va avea mai multe șanse să implementeze schimbări calitative mai rapid. Dar asta nu înseamnă că munca nu poate deveni mai complicată, uneori, dimpotrivă, introducerea de noi funcționalități necesită modificarea mai multor servicii, iar acest proces poate fi mai dificil decât similar într-o arhitectură monolitică. În orice caz, beneficiile adoptării abordării micii merită.
Sfârșitul primei părți.
În curând vom publica a doua parte a traducerii, iar acum așteptăm comentariile voastre și vă invităm să , care va avea loc astăzi la ora 20.00.
Sursa: www.habr.com