ABONAMENTE VIDEO REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 55
Abonament PDF

Bazele arhitecturii software moderne

Alexandru Bolboacă
Agile Coach and Trainer, with a focus on technical practices
@Mozaic Works
PROGRAMARE

Prezentul articol are drept scop să răspundă la o serie de întrebări fundamentale despre arhitectura software. Răspunsurile au fost inspirate din:

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ă!

Ce este arhitectura software?

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:

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.

Care este scopul arhitecturii software?

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:

Care sunt dificultăţile unei arhitecturi software?

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.

Care sunt restricţiile de calitate ale arhitecturii software?

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:

Cum poate reduce arhitectura software costurile de dezvoltare?

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;

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.

Cum poate preveni arhitectura software riscurile?

Dezvoltarea unui produs este supusă unor tipuri multiple de risc. Vă prezentăm câteva exemple:

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.

Ce sunt blocurile de construcţie ale arhitecturii software?

În proiectarea unui software, ce blocuri de construcţie folosim? Blocurile de bază sunt

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:

Această discuție sugerează că un protocol clar merge mână în mână cu un API clar pentru modul.

Ce se poate spune despre deployment?

Există câteva posibilităţi de deployment al unui modul:

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.

Cum se comunică arhitectura?

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:

O parte din documentele care ar trebui să fie parte din arhitectură, rareori scrise, sunt:

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

Concluzie

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!

Conferință

Sponsori

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • Globant
  • Colors in projects