ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
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 47
Abonament PDF

Arhitectură Soft pentru programatori

Leonard Abu-Saa
System Architect
@Arobs



PROGRAMARE


Arhitectura software are un rol foarte important în producerea sistemelor software de succes, însă, cu toate acestea, este neglijată de multe echipe. Rolul de architect software există în fiecare echipă, dar cu toate acestea, în majoritatea cazurilor, "arhitectura" reflectă mai mult un ideal decât realitatea. Multe echipe consideră că nu am nevoie de arhitecți software, deoarece se pot autoorganiza (self-organize), folosindu-se de sintagme de genul "YAGNI", "evolutionary-architecure", "emergent-design".

Ce este Arhitectura Software?

În industria IT termenul "architecture" are multe înțelesuri pentru multe persoane, existând multe definiții pentru ceea ce presupune. Iată câteva exemple: "software design", "the big picture", "plan", "technical direction", "foundations", "abstract view", "non-functional requirements", "standards and goals", etc. . Adevărul este că nu există o singură definiție validă și cuprinzătoare, existând astfel mai multe tipuri de arhitecturi: "application architecture", "software architecture", "it architecture", "platform architecture", "infrastructure application", etc. Ce au toate acestea în comun: Structură și Viziune.

La o prima vedere, noțiunea de "software architecture" ar putea fi definită ca arhitectura produsului software. Dar exista mult mai multe aspecte de luat în calcul pe lângă partea software.

Application architecture

Acesta este termenul cel mai des utilizat de către programatori, deoarece aceștia creează aplicații (desktop, web, mobile, etc). Deci, în acest context, arhitectura reprezintă suma alegerilor cu care va fi construit produsul: limbaje de programare, tehnologiile alese, framework-uri, librarii, API-uri, etc.

System architecture

Noțiunea de System Architecture este cu un nivel mai complexă, gândindu-ne la un sistem software ca fiind compus din mai multe aplicații. Am putea avea o interfață sub forma unei aplicații web, ce are legătură cu un serviciu back-end, care la rândul său are acces la un DB server/sistem. Bineînțeles, toate aceste aplicații rulează pe un suport hardware. Am putea defini în acest context system architecture ca fiind un amestec de software și hardware.

Acestea fiind spuse, combinația System Architecture și Application Architecture ne dă ca rezultat Software Architecture. Însă nu este vorba doar despre software, nu e așa?

Arhitectură vs Design

Arhitectura și designul sunt doi termeni des utilizați pentru a exprima același lucru. Într-adevăr au unele lucruri în comun, dar nu înseamnă același lucru. După cum a spus și Grady Booch: : "All architecture is design but not all design is architecture." - Orice arhitectură este un design, dar nu și orice design este o arhitectură. Ceea ce au totuși in comun este procesul de a lua decizii. De fiecare dată când creăm un design sau o arhitectură, luăm o decizie. Investigăm ce platformă să folosim, ce librării, etc. .

Diferența cheie între aceste decizii este "costul" modificării - cât ne costă să modificăm aspecte în deciziile luate. O decizie arhitecturală este mai importantă decât una de design. Și cum măsurăm importanța unei decizii? Prin totalitatea resurselor alocate: timp și programatori alocați.

Să luăm de exemplu decizia de a scrie o aplicație web în ASP .NET MVC. Care ar fi costul portării acesteia la AngularJS? Bineînțeles că ar dura săptămâni, depinzând de progresul curent al aplicației. Deci aceasta este o decizie arhitecturală.

Dar decizia de a alege între două mecanisme de logging ? Alegem sistemul de log Microsoft Events și apoi vrem să trecem la NLog sau log4Net. Bineînțeles că această modificare poate fi ușor făcută într-o singură zi.

În esență, toate deciziile semnificative sunt "architecture", iar restul sunt "design". Deciziile arhitecturale sunt cele care nu pot fi schimbate într-o singură zi.

Rolul de Software Arhitect

Am vorbit despre arhitectură software, dar nu și despre rolul în sine. În primul rând, rolul de arhitect software nu este un titlu într-o companie. Este un rol. Arhitecții software nu trăiesc izolați în turnuri de fildeș. A fi un arhitect software presupune a avea atât aptitudini tehnice, cât și capacitatea de a relaționa cu restul echipei (technical and soft skills). Un arhitect software introduce control, structură și viziune. De asemenea, ei ar trebui să programeze și să colaboreze cu membrii echipei din care fac parte. Iată un număr de aptitudini de care are nevoie un bun arhitect software: leadership, comunicare, negociere, colaborare, coaching și mentoring, etc. .

Crearea unei arhitecturi "smart"

Cum creăm o arhitectură? De ce unelte avem nevoie? Alegerile sunt multe, dar nu avem nevoie neapărat de un editor pentru diagrame UML. Putem desena diagrame pe table și pe hârtie. Ideea este în esență de a avea un design colaborativ (collaborative design). Aduceți-vă aminte că arhitectura are rolul de a introduce structură și viziune. Vă prezentăm mai jos un număr de exemple cărora le lipsesc aceste două componente:

"The airliner"

"The Eh?"

Este foarte dificil de reprezentat un sistem întreg într-o singură diagramă. Sistemele din prezent sunt foarte complexe, prezentând multe puncte de vedere. O arhitectură deșteaptă prezintă diferite viziuni ce subliniază varii aspecte ale soluției. Încercați să vă imaginați o fotografie panoramică la o rezoluție foarte mare. Daca vreți să observați detaliile, trebui să faceți zoom in. Nu există posibilitatea de a vedea toate detaliile din cel mai înalt punct de observație.

Acesta nu este un set de reguli, ci mai mult niște sugestii ce au fost introduse de Simon Brown în cartea sa "Coding the Architecture". Este modelul "C4": Context, Containers, Components and Classes. Pe măsura ce mărim "imaginea", descoperim mai multe detalii și aspecte ale soluției.

Context

Descrie imaginea de ansamblu (the big picture). Care sunt "actorii", cine folosește sistemul și care sunt părțile componente. Acest tip de diagramă poate fi prezentat persoanelor non-tehnice, cum ar fi managementul superior, având expectanța de a putea fi înțeles de acest grup de persoane.

Containers

În esență, orice poate conține cod sau date este un container. O aplicație web, o aplicație desktop, DB, sistemul de fișiere, etc. pot fi considerate containers. Aici am putea reprezenta tehnologiile high-level alese și felul în care acestea comunică.

Components

Diagrama de componente prezintă tehnologiile high-level alese, interacțiunea între module și alte servicii.

Întrebarea principală pe care ar trebui să ne-o adresăm este: "voi dezvolta (scrie cod) în acest fel?" Acesta este un aspect foarte important deoarece în multe cazuri arhitectura este privită mai mult ca un ideal, decât ca modul în care va arăta sistemul.

Arhitectura Up front

Cât este destul din punctul de vedere al unei arhitecturi? Bineînțeles că nu putem reprezenta întreg sistemul de la început, nefiind indicat deoarece sistemele noi se schimbă des. În acest context, răspunsul este: destul design pentru a introduce structură și pentru a crea o viziune împărtășită de întreaga echipă. Identificați riscurile cheie și prezentați o viziune pentru a merge mai departe.

Încheiere

Încercați să creați puțină arhitectură decât deloc sau toată odată. Fiți mai degrabă pragmatici decât perfecționiști. Creați documente scurte și concise pentru arhitectura voastră, în loc de enciclopedii mari ce nu sunt actualizate și sunt greu de gestionat și citit.

Alegeți mereu simplitatea în detrimentul soluțiilor complexe și "prea arhitecturale".

VIDEO: NUMĂRULUI 126

Sponsori

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