Prezentul articol are drept scop să răspundă la o serie de întrebări fundamentale despre arhitectura software. Răspunsurile au fost inspirate din:
Conversaţiile cu Rebecca Wirfs-Brock şi Simon Brown;
Planificarea produsului eventrix.co;
Facilitarea de "Architectural Katas";
Nenumărate conversaţii cu arhitecţi şi dezvoltatori în cadrul unor conferințe internaţionale;
Articolul este structurat în format Q&A, pentru facilitarea citirii. Nu ezitaţi să mergeţi direct la întrebările pe care le consideraţi mai interesante şi să-l citiţi în orice ordine doriţi. Recomandăm să începeţi cu prima întrebare, dat fiind că are un impact asupra înţelegerii întregului articol. Vă dorim lectură plăcută!
Nu există o definiţie clară a arhitecturii software. Apelaţi de exemplu la Wikipedia:
"Arhitectura software face referire la structurile fundamentale ale unui sistem software, disciplina elaborării acestor structuri şi documentarea acestor structuri"
Această definiţie include câteva elemente. Care sunt "structurile fundamentale" ale unui sistem software? Ce sunt "structurile" unui sistem software?
Propunem o definiţie mai dezvoltată:
"Arhitectura software face referire la un set de decizii tehnice strategice ale unui produs software, documentându-le şi asigurând implementarea lor".
Deciziile strategice sunt acele decizii care:
Au impact asupra mai multor persoane;
Implică perioade mai îndelungate;
Vă propun să vedem câteva exemple pentru a clarifica semnificaţia deciziilor tehnice strategice:
Exemplul 1: Alegerea limbajului de programare pentru o aplicaţie constituie o decizie strategică. Va afecta nu doar întreaga echipă de dezvoltare, ci şi echipa de recrutare. După alegerea unui limbaj de programare, cel mai probabil acesta va fi utilizat ani la rând. Dacă apare necesitatea alegerii unui alt limbaj de programare, acestă situaţie implică eforturi financiare mari şi timp pentru efectuarea modificării. Vor fi persoane care vor afirma că microserviciile soluţionează această problemă; de fapt, conform unei abordări a microserviciilor unui multi-limbaj, se impune plata unui cost continuu. Este un compromis, nu evită problema centrală.
Exemplul 2: Alegerea unui framework reprezintă o decizie strategică. Se aplică acelaşi raţionament de mai sus.
Exemplul 3: Alegerea stilului arhitectural bazat pe microservicii (sau REST sau monolit etc.) constituie o decizie strategică. După scrierea câtorva mii de linii de cod folosind stilul arhitectural ales, costul trecerii la un alt stil va fi ridicat deoarece include: instruirea tuturor membrilor echipei, modificarea sau rescrierea codului existent pentru a-l adapta noii arhitecturii, menţinerea unor stiluri arhitecturale diferite pentru un timp etc.
Deciziile care nu sunt strategice sunt denumite "tactice". Exemplul evident este scrierea unei metode private într-o clasă. Deşi poate afecta anumite persoane, este foarte uşor de modificat. Similar, clasele care nu sunt expuse altor module reprezintă o decizie tactică. Acest articol va utiliza noţiunea de "design software" pentru deciziile tehnice tactice.
De ce este necesar să luăm aceste decizii? Nu se pot produce pur şi simplu? Care este scopul lor?
Se pot lua desigur decizii strategice din mers. Problema este că s-ar putea dovedi foarte ineficiente.
Să presupunem că realizaţi o aplicaţie folosind limbajul de programare favorit. În scurt timp, mai multe persoane se alătură echipei şi fiecare doreşte să scrie cod într-un alt limbaj de programare. Este posibil desigur, însă pot apărea erori, riscuri (în cazul în care programatorul Haskell se îmbolnăveşte, cine va schimba codul Haskell?) şi costuri suplimentare. Este un exemplu extrem, însă arată că anumite decizii afectează mai mult anumite lucruri decât altele. Dacă doriţi să optimizaţi dezvoltarea, aceste decizii se impun a fi luate şi implementate.
Astfel, scopurile arhitecturii software sunt:
Realizarea unui produs care funcţionează în restricţiile de calitate solicitate;
Reducerea costurilor de dezvoltare;
Cel mai dificil lucru este de a lua decizii strategice (şi anume, decizii cu impact pe termen lung) cu informaţii incomplete şi cunoscând faptul că în orice moment contextul se poate modifica.
Glumim adesea spunând că "arhitectura apare atunci când codul intră în contact cu viaţa reală". Codul este clar pentru că oferă acelaşi rezultat în condiţii identice. După dezvoltarea aplicaţiei, încep să apară situaţii neprevăzute: serverele se defectează, utilizatorii descoperă metode ciudate de a folosi aplicaţia, apar atacuri spam şi din partea hackerilor, soluţii care funcţionau pe hârtie şi în medii controlate devin necorespunzătoare în mediul de producţie etc.
Acesta este motivul pentru care arhitectura necesită un anumit tip de mentalitate. O mentalitate suficient de analitică pentru a identifica deficienţele din sistem înainte de apariţia unei probleme, însă care simultan nu este blocată de informaţii incomplete. Una care poate echilibra necesităţi pe termen scurt cu posibilităţi pe termen lung, menţinând scurt timpul de dezvoltare pentru fiecare funcționalitate în timp ce investeşte suficient în flexibilitate pentru viitor. Una care poate prezenta elocvent alegerile tehnice colegilor tehnici şi non-tehnici.
Nu partea tehnică implică dificultăţi, deşi sunt multe de învăţat şi în acest sens. Cea mai dificilă parte a arhitecturii software este reprezentată de mentalitate.
Restricţiile de calitate a arhitecturii software diferă de la produs la produs. De aceea, trebuie exprimate clar şi, în măsura posibilului, cuantificate. Vă prezentăm câteva exemple:
Corectitudinea (importantă în software-ul bancar central, software-ul medical încorporat etc.): identifică părţile sistemului care trebuie să prezinte cât mai puţine deficienţe;
Performanţă: timpul de răspuns la cererile pentru funcţionalitatea X trebuie să fie sub 1s;
Disponibilitate: sistemul va fi disponibil 99,9% din timp (denumit "numărul de 9");
Scalabilitate: sistemul va funcţiona la nivelul de performanţă solicitat chiar şi atunci când există 10.000 cereri/secundă
Rezistenţă: o defecţiune a unui modul nu se va extinde asupra întregului sistem (subset din disponibilitate) ;
Rezistenţa la erori: un calcul eronat într-o parte a sistemului va fi prins într-o altă parte a sistemului;
Deciziile arhitecturale pot avea un impact imens asupra costurilor de dezvoltare. Vă prezentăm câteva exemple:
Folosiţi serviciile sau bibliotecile unui terţ în loc să dezvoltaţi anumite caracteristici;
Respectarea convenţiilor de compatibilitate pentru cod. De exemplu: toate API folosesc REST; nu sunt aruncate excepţii din API etc. ;
Reducerea costului rezolvării greșelilor de dezvoltare printr-o politică de testare automată clară;
Reducerea costului investigării deficienţelor printr-o politică clară de logging și gestionare a erorilor;
O bună euristică constă în faptul că deciziile care facilitează şi clarifică lucrurile, deschizând în același timp opţiuni duc la reducerea costurilor de dezvoltare.
Dezvoltarea unui produs este supusă unor tipuri multiple de risc. Vă prezentăm câteva exemple:
Disponibilitatea dezvoltatorilor: dezvoltarea în Haskell poate fi utilă, însă există puţini dezvoltatori. Pe de altă parte, Java este un limbaj răspândit.
Riscurile echipei: ce se întâmplă dacă o treime din membrii echipei se îmbolnăvesc (sau îşi schimbă locul de muncă)? Pot continua ceilalţi în acelaşi ritm?
Erori umane: ce se întâmplă dacă cineva este foarte obosit şi execută o eroare gravă? Se poate identifica din timp?
Siguranţă: ce se întâmplă dacă un atacator încearcă să sustragă date din sistem? Putem preveni această situaţie? Putem sesiza momentul tentativei? Cum răspundem la un atac finalizat cu succes? (plan de contingență ) ?
O parte din aceste riscuri par a fi parte din activitatea altor persoane (manager de proiect, resurse umane etc.). Este importantă totuși conştientizarea faptului că deciziile tehnice strategice pot afecta și alte aspecte ale activităţii unei companii. Aceste efecte trebuie dezbătute cu persoanele implicate, ideal fiind luarea unei decizii de comun acord.
Securitatea nu este altceva decât un set de riscuri cu impact asupra tuturor dezvoltatorilor. Prevenirea acestor riscuri reprezintă o problemă de instruire, instrucţiuni, chiar design patterns specifice ce se vor utiliza în cod. În plus, implică şi asigurarea utilizării lor în dezvoltare, prin revizuiri periodice.
Lipsa informaţiilor se poate gestiona în mai multe moduri: angajarea unui consultant specializat sau investirea în instruire. În ambele situaţii, rezultatul trebuie să fie un prototip de lucru care face dovada că o anumită caracteristică se poate implementa într-un anumit mod. Dacă problema necesită un timp scurt de studiu, folosirea unui efect de scurtă durată (perioadă limitată pentru realizarea unui prototip, de exemplu două zile) s-a dovedit o bună abordare.
În proiectarea unui software, ce blocuri de construcţie folosim? Blocurile de bază sunt
Module,
Modulele sunt părţi ale sistemului ce se pot înlocui cu alte implementări. Pentru înlocuire, sunt necesare protocoale şi contracte clare. Protocoalele definesc modul în care modulele comunică reciproc, inclusiv răspunsurile corecte la diferite tipuri de cereri. Vă puteţi imagina sistemul software ca un organism viu ale cărui organe sunt modulele, iar protocoalele reprezintă sistemul circulator şi sistemul imunitar.
În acest context, un protocol nu este mecanismul de transport, deşi poate fi construit peste unul (cel mai cunoscut protocol de transport în prezent fiind HTTP, însă există multe altele). Vă prezentăm câteva exemple de elemente ce ar trebui incluse într-un protocol:
Iniţializarea modulului înainte de a apela altă metodă din modul;
Toate solicitările adresate modulului sunt sincrone sau asincrone ;
În cazul unei erori, modulul returnează codurile de eroare / prezintă excepţii / returnează mesaje de eroare;
Această discuție sugerează că un protocol clar merge mână în mână cu un API clar pentru modul.
Există câteva posibilităţi de deployment al unui modul:
Ca namespace într-un pachet mai mare (ex. un Java war/jar, un ansamblu .NET, un C++ lib/dll etc.);
O librărie folosită la execuție ;
Un plugin ;
Fiecare opţiune de deployment prezintă avantaje şi dezavantaje. Pe scurt, cu cât există mai multe pachete care necesită deployment, cu atât devine mai complex deploymentul, monitorizarea, depanarea şi operaţiunile. Cea mai simplă metodă de deployment este monolitul, iar cea mai complexă microserviciile.
Din fericire, există o modalitate de păstrare a opţiunilor deschise şi de a introduce complexitate incremental: începeţi cu un monolit modular şi extrageţi bibliotecile, pluginurile sau serviciile la nevoie.
Luarea deciziilor corecte nu este suficientă. Echipa de dezvoltare şi echipa de conducere trebuie să le cunoască, să le înţeleagă şi să le implementeze.
Cele mai bune moduri de a comunica deciziile echipei de dezvoltare sunt:
Mostre de cod,
Diagrame,
Documente,
O prezentare,
O parte din documentele care ar trebui să fie parte din arhitectură, rareori scrise, sunt:
Design guidelines (modele specifice de utilizat în anumite contexte, de exemplu pentru a preveni problemele de siguranţă sau pentru a accelera dezvoltarea);
O politică de autentificare şi gestiunea erorilor care să se aplice constant tuturor modulelor ;
Politica de testare (ce este automatizat, ce tipuri de teste se folosesc, mostre de cod) ;
Persoane care clarifică utilizatorilor contextul deciziilor de dezvoltare
Ideal ar fi ca echipa de conducere să respecte modelul "trei amici";
O persoană concentrată pe business responsabilă de rezultatele financiare ale produsului;
O persoană responsabilă de produs care să răspundă necesităţilor utilizatorului;
Prezentarea deciziilor în cadrul acestei echipe necesită un limbaj diferit şi un nivel diferit de abstracţie. În timp ce dezvoltatorii pun accent pe motivul şi modul de implementare a deciziilor, liderii sunt responsabili de riscuri, alegeri şi efectele asupra produsului ca afacere
Prin acest articol, s-a încercat prezentarea principalelor idei ale gândirii moderne de arhitectură software. Fiecare punct necesită o dezbatere mai extinsă. Există şi aspecte pe care nu le-am abordat. Sperăm doar ca acest articol să contribuie la clarificarea şi separarea ideilor trecătoare de ideile solide care vor fi utile încă 10 ani de acum înainte. Vă lăsăm pe dvs să decideţi acest lucru. Vă rugăm să contactaţi autorii pentru mai multe informaţii, clarificări sau observaţii. Mulţumim!