La început este întotdeauna dificil să înțelegi un proiect mare și vechi. Arhitectura este una dintre activitățile evaluării unui arhitect. De obicei trebuie să lucrezi cu proiecte mari, vechi, iar rezultatele trebuie să fie livrate într-o săptămână.
Cum să evaluezi un proiect de 100 sau mai multe linii de cod într-o săptămână, oferind în același timp rezultate care sunt cu adevărat utile clientului.
Majoritatea arhitecților și a liderilor tehnici au întâlnit evaluări similare de proiecte. Acesta poate părea ca un proces semi-formal sau ca un serviciu separat, așa cum se face în compania noastră, într-un fel sau altul majoritatea dintre voi v-ați ocupat de asta.
Originalul în engleză pentru prietenii tăi care nu vorbesc rusă este aici: .
Abordarea companiei noastre
Îți voi spune cum funcționează în compania noastră și cum acționez eu în situații similare, dar poți schimba cu ușurință această abordare în funcție de nevoile proiectului și companiei tale.
Există două tipuri de evaluare a arhitecturii.
Interior – de obicei o facem pentru proiecte din cadrul 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 astfel de cazuri și de multe ori în astfel de proiecte totul este departe de a fi ideal.
- Echipa vrea să-și testeze proiectul și soluțiile.
- Echipa știe că lucrurile stau rău. Ei pot chiar enumera principalele probleme și cauze, dar doresc o listă completă de probleme și recomandări pentru îmbunătățirea proiectului.
Extern este un proces mai formal decât o evaluare internă. Clientul vine întotdeauna doar într-un caz, când totul este rău - foarte rău. De obicei, clientul înțelege că există probleme globale, dar nu poate identifica corect cauzele și le descompune în componente.
Evaluarea unei arhitecturi pentru un client extern este un caz mai complex. Procesul ar trebui să fie mai formal. Proiectele sunt mereu mari și vechi. Au o mulțime de probleme, bug-uri și cod strâmb. Un raport despre munca depusă ar trebui să fie gata în maximum câteva săptămâni, care să includă principalele probleme și recomandări de îmbunătățire. Prin urmare, dacă ne ocupăm de evaluarea externă a proiectului, atunci evaluarea internă va fi ușor. Să luăm în considerare cel mai dificil caz.
Evaluarea arhitecturii proiectelor de întreprindere
Un proiect tipic de evaluat este un proiect mare, vechi, de întreprindere, cu multe probleme. Un client vine la noi și ne cere să-i reparăm proiectul. Este ca la un aisberg, clientul vede doar vârful problemelor sale și habar nu are ce se află sub apă (în adâncurile codului).
Probleme de care clientul se poate plânge și de care poate fi conștient:
- Probleme de performanta
- Probleme de utilizare
- Desfășurare pe termen lung
- Lipsa testelor unitare și a altor teste
Probleme de care clientul cel mai probabil nu le cunoaște, dar care pot fi prezente în proiect:
- Probleme de siguranță
- Probleme de proiectare
- Arhitectură greșită
- Erori algoritmice
- Tehnologii neadecvate
- Datoria tehnică
- Proces de dezvoltare greșit
Procesul formal de revizuire a arhitecturii
Acesta este un proces formal pe care îl urmăm ca companie, dar îl puteți personaliza în funcție de companie și proiect.
Solicitare de la un client
Clientul cere evaluarea arhitecturii proiectului curent. Persoana responsabilă de partea noastră colectează informații de bază despre proiect și selectează experții necesari. În funcție de proiect, aceștia pot fi experți diferiți.
Arhitect soluție – persoana principală responsabilă de evaluare și coordonare (și adesea singura).
Stivuiți experți specifici – .Net, Java, Python, și alți specialiști tehnici în funcție de proiect și tehnologii
Experți în cloud – aceștia pot fi arhitecți în cloud Azure, GCP sau AWS.
Infrastructură – DevOps, administrator de sistem etc.
Alți experți – cum ar fi big data, machine learning, inginer de performanță, expert în securitate, lider QA.
Colectarea de informații despre proiect
Ar trebui să colectați cât mai multe informații despre proiect. Puteți folosi diferite tehnici în funcție de situație:
- Chestionare și alte metode de comunicare prin poștă. Cel mai ineficient mod.
- Întâlniri online.
- Instrumente speciale pentru schimbul de informații precum: Google doc, Confluence, depozite etc.
- Întâlniri „live” la fața locului. Cel mai eficient și mai scump mod.
Ce ar trebui să obțineți de la client?
Informatii de baza. Despre ce este proiectul? Scopul și valoarea sa. Principalele obiective și planuri pentru viitor. Obiective și strategii de afaceri. Principalele probleme și rezultatele dorite.
Informatii despre proiect. Stack de tehnologie, cadre, limbaje de programare. Implementare on-premise sau cloud. Dacă proiectul este în cloud, ce servicii sunt folosite. Ce modele arhitecturale și de design au fost folosite.
Cerințe nefuncționale. Toate cerințele legate de performanță, disponibilitate și ușurință de utilizare a sistemului. Cerințe de siguranță etc.
Cazuri de utilizare de bază și fluxuri de date.
Acces la codul sursă. Cea mai importantă parte! Cu siguranță ar trebui să obțineți acces la arhivele și documentația despre cum să construiți proiectul.
Acces la infrastructură. Ar fi bine să ai acces la scenă sau la infrastructura de producție pentru a lucra cu sistemul live. Este un mare succes dacă clientul are instrumente de monitorizare a infrastructurii și performanței. Despre aceste instrumente vom vorbi în secțiunea următoare.
Documentație. Dacă clientul are documente, acesta este un început bun. Poate fi depășit, dar este încă un început bun. Nu aveți încredere niciodată în documentație - testați-o cu clientul, pe infrastructura reală și în codul sursă.
Procesul de evaluare a arhitecturii
Cum se poate procesa o cantitate atât de mare de informații într-un timp atât de scurt? În primul rând, paralelizați lucrarea.
DevOps ar trebui să se uite la infrastructură. Conducător tehnic în cod. Inginer de performanță pentru a vedea valorile de performanță. Un specialist în baze de date ar trebui să aprofundeze structurile de date.
Dar acesta este un caz ideal când ai multe resurse. De obicei, una până la trei persoane evaluează un proiect. Puteți chiar să efectuați singur estimarea, ceea ce este adesea cazul dacă aveți cunoștințele și experiența corespunzătoare în toate domeniile proiectului. În acest caz, trebuie să automatizați cât mai mult posibil toate procesele.
Din păcate, va trebui să citiți manual documentația. Cu cantitatea potrivită de experiență, puteți înțelege rapid calitatea documentației. Ce este adevărat și ceea ce clar nu coincide cu realitatea. Uneori s-ar putea să vedeți arhitectură în documentație care nu va funcționa niciodată în viața reală. Acesta este un declanșator pentru a vă gândi la modul în care a fost realizat în realitate în proiect.
Instrumente utile pentru automatizarea evaluării proiectelor
Evaluarea codului este un exercițiu simplu. Puteți utiliza analizoare de cod statice care vă vor arăta probleme de design, performanță și securitate. Iată câteva dintre ele:
este un instrument excelent pentru un arhitect. Vă va arăta imaginea de ansamblu, dependențele dintre module și zonele potențiale pentru refactorizare. Ca toate instrumentele bune, costă bani buni, dar puteți profita de o versiune de încercare de 30 de zile.
- un instrument vechi bun. Un instrument pentru analiza codului static. Vă permite să identificați codul prost, erorile și problemele de securitate pentru mai mult de 20 de limbaje de programare.
Toți furnizorii de cloud au instrumente de monitorizare a infrastructurii. Acest lucru vă va permite să evaluați corect eficiența infrastructurii dvs. în termeni de cost și performanță. Pentru AWS aceasta este . Este ușor pentru Azure .
Monitorizarea și înregistrarea suplimentară a performanței vor ajuta la identificarea problemelor de performanță la toate nivelurile. Pornind de la o bază de date cu interogări ineficiente, backend și terminând cu frontend. Chiar dacă clientul nu a instalat anterior aceste instrumente, le puteți integra în sistemul existent destul de rapid pentru a identifica problemele de performanță.
Ca întotdeauna, instrumentele bune merită. Pot recomanda câteva instrumente plătite. Desigur, puteți folosi open-source, dar vă va lua mai mult timp. Și acest lucru ar trebui făcut dinainte, nu în timpul procesului de evaluare arhitecturală.
– un instrument pentru evaluarea performanței aplicației
– serviciu de monitorizare a sistemului cloud
Există multe instrumente disponibile pentru testarea securității. De data aceasta vă voi recomanda un instrument gratuit de scanare a sistemului.
– un instrument pentru scanarea aplicațiilor web pentru conformitatea cu standardele de securitate.
Să punem totul împreună într-un singur întreg.
Întocmirea unui raport
Începeți raportul cu datele pe care le-ați colectat de la client. Descrieți obiectivele proiectului, constrângerile, cerințele nefuncționale. După aceasta, trebuie menționate toate datele de intrare: cod sursă, documentație, infrastructură.
Urmatorul pas. Enumerați orice probleme pe care le-ați găsit manual sau folosind instrumente automate. Plasați rapoarte mari generate automat la sfârșit în secțiunea de aplicații. Ar trebui să existe dovezi scurte și succinte ale problemelor găsite.
Prioritizează problemele găsite pe eroare, avertizare, scară de informații. Îți poți alege propria scară, dar aceasta este cea general acceptată.
Ca un adevărat arhitect, este responsabilitatea dumneavoastră să oferiți recomandări pentru a corecta problemele constatate. Descrieți îmbunătățirile și valoarea de afaceri pe care le va primi clientul. Cum să arăți valoarea afacerii din am discutat mai devreme.
Pregătiți o foaie de parcurs cu mici iterații. Fiecare iterație ar trebui să conțină timp de finalizare, descriere, cantitatea de resurse necesare pentru îmbunătățire, valoare tehnică și valoarea de afaceri.
Finalizăm evaluarea arhitecturii și oferim clientului un raport
Nu trimiteți niciodată un raport prin e-mail. Este posibil să nu fie citit deloc sau să nu fie citit și înțeles fără o explicație adecvată. Pe scurt, comunicarea live ajută la eliminarea neînțelegerilor dintre oameni. Ar trebui să programați o întâlnire cu clientul și să discutați despre problemele găsite, concentrându-vă pe cele mai semnificative. Merită să atragem atenția clientului asupra unor probleme de care s-ar putea să nu fie conștient. Cum ar fi problemele de securitate și explicați cum ar putea avea impact asupra afacerii. Arată-ți foaia de parcurs cu îmbunătățiri și discută diferite opțiuni care sunt mai potrivite pentru client. Acesta ar putea fi timpul, resursele, cantitatea de muncă.
Ca un rezumat al întâlnirii dvs., trimiteți raportul dvs. clientului.
în concluzie
Evaluarea arhitecturii este un proces complex. Pentru a efectua evaluarea în mod corespunzător, trebuie să aveți suficientă experiență și cunoștințe.
Este posibil să oferi clientului rezultate utile pentru el și afacerea lui în doar o săptămână. Chiar dacă o faci singur.
Pe baza experienței mele, multe îmbunătățiri au fost descărcate la mijloc și uneori nu au început niciodată. Cei care au ales mijlocul de aur pentru ei înșiși și au făcut doar o parte din îmbunătățirile care au fost cele mai utile pentru afacere cu costuri minime de muncă și-au îmbunătățit semnificativ calitatea produsului. Cei care nu au făcut nimic au putut închide proiectul cu totul după câțiva ani.
Scopul tău este să arăți clientului îmbunătățiri maxime la prețul minim.
Alte articole din sectiune poti citi la indemana ta.
Vă doresc cod curat și decizii arhitecturale bune.
Grupul nostru de facebook - .
Sursa: www.habr.com