La început, este întotdeauna dificil să te descurci într-un proiect mare și vechi. Evaluarea arhitecturii este una dintre activitățile arhitectului. De obicei, trebuie să lucrezi cu proiecte mari și vechi, iar rezultatele trebuie furnizate într-o săptămână.
Cum să evaluezi un proiect cu 100.000 de linii de cod sau mai mult într-o săptămână, asigurând în același timp rezultate cu adevărat utile pentru client.
Cei mai mulți arhitecți și lideri tehnici s-au confruntat cu evaluări de acest tip pentru proiecte. Acest lucru poate părea un proces semi-formal sau un serviciu separat, așa cum se întâmplă în compania noastră, totuși, majoritatea dintre voi ați avut de-a face cu asta.
Originalul în limba engleză pentru prietenii voștri care nu vorbesc rusă se găsește aici: .
Abordarea în compania noastră
Voi explica cum funcționează acest lucru în compania noastră și cum procedez în astfel de situații, dar puteți modifica această abordare în funcție de nevoile proiectului și companiei voastre.
Există două tipuri de evaluare a arhitecturii.
Internă – de obicei, o facem pentru proiectele interne ale companiei. Orice proiect poate solicita o evaluare a arhitecturii din mai multe motive:
- Echipa crede că proiectul lor este perfect și acest lucru este suspect. Am avut cazuri de acest fel și, de obicei, în astfel de proiecte, lucrurile nu sunt deloc ideale.
- Echipa vrea să-și verifice proiectul și soluțiile.
- Echipa știe că există probleme. Pot chiar să enumere principalele probleme și cauze, dar doresc să obțină o listă completă a problemelor și recomandări pentru îmbunătățirea proiectului.
Externă – este un proces mai formal decât evaluarea internă. Clientul vine întotdeauna doar într-un singur caz, când lucrurile sunt foarte proaste. De obicei, clientul înțelege că există probleme globale, dar nu poate identifica corect cauzele și a le descompune în părțile componente.
Evaluarea arhitecturii pentru un client extern este un caz mai complex. Procesul trebuie să fie mai formal. Proiectele sunt întotdeauna mari și vechi. Acestea au multe probleme, bug-uri și cod imperfect. Raportul final trebuie să fie gata într-o perioadă de câteva săptămâni, cel mult, unde să fie enumerate principalele probleme și recomandări pentru îmbunătățire. Așadar, dacă ne ocupăm de evaluarea externă a proiectului, evaluarea internă va fi o nimica toată. Să luăm în considerare cel mai complicat caz.
Evaluarea arhitecturii proiectului de tip enterprise
Un proiect tipic pentru evaluare este un proiect mare, vechi, de tip enterprise, cu o mulțime de probleme. Clientul vine la noi și ne cere să reparăm proiectul său. Este ca un iceberg, clientul vede doar partea de sus a problemelor sale și nu își dă seama de ceea ce este sub apă (în adâncimea codului).
Problemele pe care clientul le poate reclama și despre care poate fi conștient:
- Probleme de performanță
- Probleme de utilizare a aplicației (Usability)
- Dezvoltare lungă
- Lipsa testelor unitare și altor teste
Probleme despre care clientul probabil că nu bănuieste, dar care pot exista în proiect:
- Probleme de securitate
- Probleme de proiectare
- Arhitectură greșită
- Erori algoritmice
- Tehnologii inadecvate
- Datorie tehnică
- Proces de dezvoltare greșit
Proces formal de evaluare a arhitecturii
Acesta este un proces formal pe care îl respectăm în companie, dar îl puteți adapta în funcție de compania și proiectul dumneavoastră.
Cerere din partea clientului
Clientul cere o evaluare a arhitecturii proiectului actual. Persoana responsabilă din partea noastră colectează informațiile de bază despre proiect și selectează experții necesari. În funcție de proiect, aceștia pot fi diferiți experți.
Solution Architect – persoana principală responsabilă de evaluare și coordonare (și adesea singura).
Experți specifici pe stack – .Net, Java, Python și alți specialiști tehnici în funcție de proiect și tehnologiile utilizate
Experți în cloud – pot fi arhitecți Azure, GCP sau AWS.
Infrastructură – DevOps, administrator de sistem etc.
Alți experți – precum big data, machine learning, performance engineer, expert în securitate, QA lead.
Colectarea informațiilor despre proiect
Ar trebui să colectați cât mai multe informații despre proiect. Puteți folosi diverse tehnici în funcție de situație:
- Chestionare și alte metode de comunicare prin e-mail. Cea mai puțin eficientă metodă.
- Întâlniri online.
- Instrumente speciale pentru schimbul de informații, cum ar fi: Google doc, Confluence, depozite etc.
- Întâlniri "live" la fața locului. Cea mai eficientă și cea mai costisitoare metodă.
Ce trebuie să obținem de la client?
Informații de bază. Despre ce este proiectul. Scopul și valoarea sa. Obiectivele principale și planurile de viitor. Obiectivele și strategiile de afaceri. Problemele principale și rezultatul dorit.
Informații despre proiect. Tehnologia de bază, cadrele de lucru, limbajele de programare. Implementare on-premise sau în cloud. Dacă proiectul este în cloud, ce servicii sunt utilizate. Ce tipare arhitecturale și de design au fost aplicate.
Cerințe non-funcționale. Toate cerințele legate de performanță, disponibilitate, utilizabilitatea sistemului. Cerințe de securitate etc.
Cazuri de utilizare de bază și fluxuri de date.
Acces la codul sursă. Cea mai importantă parte! Este esențial să obțineți acces la repo-uri și documentația despre cum să adunați proiectul.
Acces la infrastructură. Ar fi bine să obțineți acces la infrastructura de stage sau de producție pentru a lucra cu un sistem „live”. Este o mare noroc dacă clientul are instrumente de monitorizare a infrastructurii și performanței. Despre aceste instrumente vom discuta în secțiunea următoare.
Documentație. Dacă clientul are documentație, este un bun început. Poate fi învechită, dar este totuși un bun început. Nu vă încredeți niciodată în documentație – verificați-o cu clientul, pe infrastructura reală și în codul sursă.
Procesul de evaluare a arhitecturii
Cum să gestionați o astfel de cantitate mare de informații într-un interval de timp atât de scurt? În primul rând, repartizați munca pe paralele.
DevOps trebuie să se uite în infrastructură. Tech lead în cod. Inginerul de performanță să verifice metricile de performanță. Specialistul în baze de date ar trebui să aprofundeze structurile de date.
Dar acesta este cazul ideal, când aveți multe resurse. De obicei, evaluarea proiectului se face de una până la trei persoane. Puteți chiar să efectuați evaluarea singuri, ceea ce se întâmplă adesea, dacă aveți cunoștințe și experiență adecvată în toate domeniile proiectului. În acest caz, trebuie să automatizați toate procesele cât mai mult posibil.
Din păcate, va trebui să citiți documentația manual. Cu experiența adecvată, veți putea înțelege rapid calitatea documentației. Ce este adevărat și ce nu corespunde evident realității. Uneori, puteți întâlni o astfel de arhitectură în documentație care nu va funcționa niciodată în viața reală. Acesta este un semnal pentru a vă întreba cum este realizată în realitate în proiect.
Instrumente utile pentru automatizarea evaluării proiectului
Evaluarea codului este un exercițiu simplu. Puteți utiliza analizatori de cod statice care vor arăta probleme de design, performanță și securitate. Iată câteva dintre acestea:
este un instrument excelent pentru arhitect. Îți va oferi o imagine de ansamblu, dependențele între module și zonele potențiale pentru refactoring. Ca toate uneltele bune, costă destul de mult, dar poți profita de un trial gratuit de 30 de zile.
este un instrument clasic. Un instrument pentru analiza statică a codului. Permite identificarea codului de proastă calitate, a bug-urilor și a problemelor de securitate pentru mai mult de 20 de limbaje de programare.
Toți furnizorii de cloud au instrumente pentru monitorizarea infrastructurii. Acest lucru îți va permite să evaluezi corect eficiența infrastructurii din punct de vedere al costurilor și performanței. Pentru AWS, acesta este . Pentru Azure, este simplu .
Monitorizarea suplimentară a performanței și loggingul te va ajuta să identifici problemele de performanță la toate nivelurile. Începând cu baza de date cu interogări ineficiente, backendul și terminând cu frontendul. Chiar dacă clientul nu a instalat aceste instrumente anterior, poți integra rapid aceste soluții în sistemul existent pentru a determina problemele de performanță.
Ca de obicei, instrumentele bune au un preț pe măsură. Pot recomanda câteva instrumente plătite. Desigur, poți folosi open-source, dar vei avea nevoie de mai mult timp pentru asta. Și aceasta ar trebui făcută din timp, nu în timpul evaluării arhitecturii.
este un instrument pentru evaluarea performanței aplicațiilor
este un serviciu cloud pentru monitorizarea sistemelor
Pentru testarea securității există multe instrumente. De data aceasta, îți voi recomanda un instrument gratuit pentru scanarea sistemului.
este un instrument pentru scanarea aplicațiilor web pentru conformitate cu standardele de securitate.
Adunăm totul într-un singur loc.
Pregătim raportul
Începe-ți raportul cu datele strânse de la client. Descrie obiectivele proiectului, constrângerile, cerințele non-funcționale. Apoi, menționează toate datele de intrare, codul sursă, documentația și infrastructura.
Următorul pas. Indicați toate problemele pe care le-ați găsit manual sau cu ajutorul instrumentelor automatizate. Rapoartele mari generate automat ar trebui să fie plasate la sfârșit, în secțiunea anexelor. Aici ar trebui să fie dovezi scurte și concise ale problemelor identificate.
Prioritizați problemele identificate pe o scară de tip error, warning, info. Puteți alege propria scară, dar aceasta este acceptată pe scară largă.
Ca un arhitect adevărat, aveți datoria de a oferi recomandări pentru remedierea problemelor descoperite. Descrieți îmbunătățirile și valoarea pentru afacere pe care le va obține clientul. Cum să arătați valoarea pentru afacere de la pe care le-am discutat anterior.
Pregătiți un roadmap cu iterații mici. Fiecare iterație ar trebui să conțină timpul de realizare, descrierea, numărul de resurse necesare pentru îmbunătățire, valoarea tehnică și valoarea pentru afacere.
Finalizăm evaluarea arhitecturii și furnizăm clientului un raport.
Nu trimiteți niciodată un raport doar prin e-mail. Acesta poate fi fie complet trecut cu vederea, fie citit fără a fi înțeles corespunzător fără explicații adecvate. Pe scurt, comunicarea directă ajută la eliminarea neînțelegerilor între oameni. Ar trebui să stabiliți o întâlnire cu clientul și să discutați despre problemele identificate, punând accent pe cele mai semnificative. Acordați atenție problemelor de care clientul ar putea să nu fie conștient, cum ar fi problemele de securitate, și explicați cum acestea pot afecta afacerea. Prezentați-vă roadmap-ul cu îmbunătățiri și discutați diferite opțiuni mai potrivite pentru client. Acestea pot include timp, resurse și volumul de muncă.
Ca o concluzie a întâlnirii dumneavoastră, trimiteți clientului raportul.
În concluzie
Evaluarea arhitecturii este un proces complex. Pentru a efectua evaluarea corespunzător, trebuie să aveți suficientă experiență și cunoștințe.
Este posibil să oferiți clientului rezultate utile pentru el și afacerea sa în doar o săptămână. Chiar și atunci când lucrați singur.
Din experiența mea, multe îmbunătățiri au fost abandonate pe parcurs, iar uneori nu au început chiar niciodată. Cei care au ales un echilibru dorit, realizând doar o parte din îmbunătățirile cele mai utile pentru afacere cu un minim de efort, au îmbunătățit semnificativ calitatea produsului lor. Cei care nu au făcut nimic, după câțiva ani, ar fi putut chiar să închidă proiectul.
Scopul dumneavoastră este să arătați clientului cele mai mari îmbunătățiri la cel mai mic preț.
Alte articole din secțiune se poate citi în timpul liber.
Vă doresc cod curat și soluții arhitecturale bune.
Grupul nostru de Facebook — .
Sursa: habr.com
