ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 139
Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 11
Abonament PDF

Arhitectura extransibilă și durabilă (grow form novice to guru)

Levente Veres
Design Lead
@Endava



PROGRAMARE

The dialogue between client and architect is about as intimate as any conversation you can have, because when you"re talking about building a house, you"re talking about dreams. Robert A. M. Stern

THE PHILOSOPHY

În zilele de azi dezvoltarea de aplicații nu se rezumă la dezvoltarea de module, la mentenanţa aplicațiilor dezvoltate acum ani de zile sau la o simplă testare de funcționalitate. "Softiști români" au ajuns la nivelul la care nu numai clientul sau "dezvoltatorul" dorește mai mult, ci și piața dorește ceva mai mult de la "dezvoltatori români". Clientul așteaptă ceva mai prețios decât o executare coordonată, aşteaptă ceva în plus care să îl surprindă chiar și pe el. Desigur, marea majoritate a programatorilor neglijează acest detaliu pe care îl conștientizează doar atunci când devin ei înșiși clienți.

Marea majoritate a dezvoltatorilor nu va fi în stare să sacrifice timp și energie adițională ca să ofere ceva în plus. Motive se găsesc, multe personale cât și financiare sau alegerea stagnării în zona de confort.

Articolul de mai jos este adresat tuturor care doresc să ofere ceva în plus faţă de cerințele standard, totodată să se pregătească pentru a deveni cei mai buni în domeniul IT. Desigur fiecare are la dispoziţie o cale unică și proprie pentru a atinge nivelul de Arhitect, ceea ce necesită experiență de ani de zile.

Pentru a defini un Arhitect, fie el din categoria system-software, solution sau business, aș folosi câteva cuvinte cheie: dreams (vise), reality (realitate), creation (creare), timeless (inexpirabil).

Un arhitect trebuie să ia în considerare ca orice soluție, aplicație creată de el reflectă în realitate visul unui/unor oameni și va fi cât de cât posibil o creație de durată.

În cazul în care v-ați regăsit mai sus vocația, putem trece la următoarele nivele unde vom discuta succint despre unele aspecte din modul în care transformăm un vis în creație reală.

THE SECRET

Care este cheia succesului unei arhitecturi care satisface toate cerințele proiectului? Întrebarea este retorică, dar se poate răspunde la ea. Arhitectura ideală este cea care satisface cele patru criterii de mai sus și este consecventă cu deciziile luate pe durata implementări , totodată nu deviază de la criteriile de bază propuse în primele etape ale arhitecturi.

Deși pare ușor de făcut față celor de mai sus, cu atât e mai greu să menții în echilibru creația din diferite motive cum ar fi decizii manageriale, financiare, schimbări de scopuri sau schimbări de echipe.

THE BUCKET LIST

Pentru a ține totul sub control trebuie să fim conștienți că fără o listă de "to-do" nu prea vom putea fi consecvenți, ceea ce induce ca arhitectura aleasă să nu fie sustenabilă. Desigur această listă are sens numai dacă periodic reluăm și verificăm dacă mai este actual ceea ce am definit inițial, dacă deviația este prea mare e timpul să regândim dacă arhitectura aleasă va fi sau nu prea bună.

O listă de necesitați SMART poate fi următoarea:

A. Colectarea informațiilor

1. Creați o lista de cerințele funcționale.

Exemplu: Dorim o aplicație care face rezervări de bilete de avion.

2. Creați o lista de cerințe non-funcționale

Notă: Dacă nu aveți așa ceva de la client, atunci ARHITECTUL are responsabilitatea de a face o lista exemplificată mai jos, care îi va ajuta și pe dezvoltatori.
Exemplu:
• Soluția noastră în 30 de milisecunde găsește toate biletele disponibile pentru o anumita rută.
• Fiecare interogare de bază de date nu durează mai mult de 10 milisecunde.
• Putem deservi 1000 de utilizatori pe minut.
• Folosim fiecare server de aplicație cu un grad de ocupare maxim 70%.

3. Creați o listă proprie de posibile cerințe (definim cât extensibilă să fie aplicația).

Exemplu: Dorim în viitorul apropiat să deservim aplicațiile mobile prin servicii web(Restful).

4. Creați o lista despre așteptările stakeholder-ilor de la soluția propusă

Exemplu:
• Directorul economic: reducere cu 10% al costurilor de vânzări
• Directorul IT: să reducă nemulțumirea angajaților cu accesul la sistem
• Angajați: clienți să-și poată rezerva foarte rapid biletele.
Notă: lista de mai sus va fi una benefică în final la predarea aplicației când va fi prezentată aplicația. Totodată pe parcursul discuțiilor și al ideilor de implementare vom nevoile diferiților stakeholderi.

B. Shape it:"Frizerul prietenul nostru"

1. Slice - Taie pe mărimea potrivita

• Descompune problema în probleme mai mici, funcționalității mari în sub-funcționalități ce pot fi rezolvate.
• altă metodă este descompunerea în module/blocuri ce aduc mai aproape de conceptul OOP.

2. Frizerul ortogonal:

• Să ne orientam către ortogonalitate, adică să modularizăm soluția. Astfel avem posibilitatea de a crea diferite module și interfețe facilitând testatarea și mentenanța produsului.

3. DRY(Don"t Repeat Yourself) - Uscatul

• Cel mai cunoscut acronim legat de ideea: un singur rezultat la o singură problemă. E important să nu încercam să repetăm codurile, modulele, interfețele care au aceeași funcționalitate.

4. Test it: testul cu oglinda

• Testabilitatea soluției este cea mai vitală pentru a susține o arhitectură robustă, dar totuși receptivă la schimbări.
• E important să decidem până la ce nivel dorim să testăm soluția propusă: nivelul micro pentru care vor fi testat fiecare variabilă, metodă sau clasă ori putem să ne orientăm către o testare macro caz în care ne interesează să poată fi testate modulele.

5. FixIt: - un coafor priceput se respectă:

• E bine de creat module care suportă modificările și fix-urile, astfel încât să nu aibă impact asupra altor componente.
• În cazul în care fix-ul aduce modificări asupra mai multor module în același timp, e necesar de revizuit planul inițial, dacă arhitectura chiar corespunde nevoilor noastre.

6. Cost of changes: plata la frizer

• arhitectura robustă trebuie să suporte schimbări continue, dar în același timp prețul schimbărilor trebuie să rămână minim.
• Pentru calculul costului schimbărilor se poate folosi o ecuație simplă care avertizează asupra riscurilor:

Sum( Change[1..n]x Sum(Affected Module[1..m]) ) = Cost of Change

• Unde n,m reprezintă numărul maxim de schimbări și module.
• Fiecare schimbare și modul are valoare 1, desigur dacă modulele sunt mai complexe putem defini pentru fiecare modul un cost specific.
• Costul maxim îl vom obține pentru cazul în care fiecare schimbare are impact asupra fiecărui modul.
• Costul ideal este de 30% din costul maxim, costul optim între 30% și 70%, iar costul critic peste 70% din costul maxim.
Exemplu: în cazul a 3 module , unde Modul3 are cost 3, pentru la 2 schimbări avem următorul cost:

Change1 x (Module 1 + Module 2) + Change2 x (Module1+Module2+Module3) = 1x(1+1) + 1x(1+1+3) =2 +5=7

Cost maxim: Change1(Module1 + Module2 + Module 3) + Change2x(Module1+Module2+Module3)= 1x(1+1+3)+1(1+1+3)=10

Cost Maxim : 10; Cost ideal: 3; Cost critic: 7.

În exemplul dat suntem la limită între costul critic și cel ideal, cea ce ne informează ca ar fi posibil ca arhitectura să fie afectată și să aibă consecințe majore.

C. Focus Point: de reținut

• Să verificam calitatea, metrica, redundanța modulelor și a claselor;
• Să verificăm dacă arhitectura aleasă sau standardele de aliniere (Togaf, ISO etc) se mai mapează pe soluția curentă;
• Să introducem puncte de control pentru validarea soluției si a arhitecturi;
• Să ne amintim de limitele de hardware, rețea si a componentelor integrate;
• Să ținem minte că resursele sunt limitate (bani, dezvoltatori);

D. The Good is the enemy of The Perfect: să tindem la perfecționism

• De fiecare dată să încercăm sa îmbunătățim codul existent.
• Să nu ne lăsăm pradă ideilor: îmbunătățirea nu se plătește, lasă că rezolvam cândva etc.
• Respectă munca ta și a altora.
• Utilizează conceptul "Benefits +1", întotdeauna să aduci ceva în plus față de ce ți s-a cerut.
• PROTOTYPE: crearea de prototipuri ne ajută să fim siguri că suntem pe drumul cel bun
• DESENEZĂ: afișarea grafica a arhitecturii ne aduce beneficiul vizual al unei analize rapide Lista de mai sus se poate completa cu multe altele, astfel încât să fie una foarte complexă și satisfăcătoare, de fiecare dată însă trebuie luat in considerare BENEFICIUL adus prin introducerea noilor complexități.
În următorul număr al revistei TSM vom identifica niște "best practices" pentru a crea arhitecturi accesibile întregii echipe.

NUMĂRUL 138 - Maps & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO