Na početku je uvijek teško snaći se u velikom i starom projektu. Architecture assessment je jedna od aktivnosti arhitekta. Obično se radi s velikim, starim projektima, a rezultate treba dostaviti unutar tjedan dana.
Kako ocijeniti projekt od 100k ili više linija koda u tjedan dana i pritom pružiti doista korisne rezultate za klijenta?
Većina arhitekata i tehničkih lidera se susrela s takvim ocjenama projekta. To može izgledati kao poluformalni proces ili kao posebna usluga, kao što je to u našoj tvrtki. Tako ili inače, većina vas se s time susrela.
Izvorni tekst na engleskom jeziku za vaše ne-rusko govoreće prijatelje nalazi se ovdje: .
Pristup u našoj tvrtki
Ispričat ću vam kako to funkcionira u našoj tvrtki i kako ja postupam u sličnim situacijama, ali možete lako prilagoditi ovaj pristup prema potrebama vašeg projekta i tvrtke.
Postoje dvije vrste architecture assessment.
Interni – obično ga radimo za projekte unutar tvrtke. Bilo koji projekt može zatražiti ocjenu arhitekture iz nekoliko razloga:
- Tim misli da je njihov projekt savršen i to je sumnjivo. Imali smo takvih slučajeva i često u takvim projektima nije sve savršeno.
- Tim želi provjeriti svoj projekt i svoja rješenja.
- Tim zna da nije dobro. Čak mogu navesti glavne probleme i razloge, ali žele dobiti potpuni popis problema i preporuka za poboljšanje projekta.
Vanjski – ovo je formalniji proces od unutarnje ocjene. Klijent dolazi uvijek samo u jednom slučaju, kada je sve loše – vrlo loše. Obično klijent shvaća da postoje globalni problemi, ali ne može točno odrediti uzroke i razložiti ih.
Ocjena arhitekture za vanjskog klijenta je složeniji slučaj. Proces mora biti formalniji. Projekti su uvijek veliki i stari. Imaju mnogo problema, bugova i lošeg koda. Izvještaj o provedenom radu mora biti spreman unutar nekoliko tjedana, gdje bi trebali biti glavni problemi i preporuke za poboljšanje. Stoga, ako se obrađujemo s vanjskom ocjenom projekta, unutarnja će biti samo sitnica. Razmotrimo najteži slučaj.
Ocjena arhitekture enterprise projekta
Tipičan projekt za ocjenu je velika, stara, enterprise projekt s brojnim problemima. Klijent se obraća nama i traži da popravimo njegov projekt. To je poput ledenjaka, klijent vidi samo vrh svojih problema i ne shvaća što se nalazi ispod vode (u dubini koda).
Problemi na koje se klijent može požaliti i koje može biti svjestan:
- Problemi s performansama
- Problemi s uporabom aplikacije (Usability)
- Dugotrajan proces implementacije
- Nedostatak unit i drugih testova
Problemi o kojima klijent vjerojatno nije svjestan, ali mogu biti prisutni u projektu:
- Sigurnosni problemi
- Problemi dizajna
- Netačna arhitektura
- Algoritamske greške
- Neprimjerene tehnologije
- Tehnički dug
- Pogrešan proces razvoja
Formalni proces ocjene arhitekture
To je formalni proces kojem se pridržavamo u tvrtki, ali ga možete prilagoditi prema sebi, ovisno o vašoj tvrtki i projektu.
Zahtev od klijenta
Klijent traži da ocijenimo arhitekturu trenutnog projekta. Odgovorna osoba s naše strane prikuplja osnovne informacije o projektu i odabire potrebne stručnjake. Ovisno o projektu, to mogu biti različiti stručnjaci.
Solution Architect – glavni čovjek odgovoran za ocjenu i koordinaciju (i često jedini).
Stack specific experts – .Net, Java, Python i drugi tehnički stručnjaci ovisno o projektu i tehnologijama
Cloud experts – to mogu biti Azure, GCP ili AWS cloud arhitekti.
Infrastructure – DevOps, sistemski administrator itd.
Ostali stručnjaci – kao što su big data, machine learning, performance engineer, security expert, QA lead.
Prikupljanje informacija o projektu
Trebate prikupiti što više informacija o projektu. Možete koristiti razne tehnike ovisno o situaciji:
- Anketni upitnici i drugi načini komunikacije putem e-pošte. Najmanje učinkovita metoda.
- Online sastanci.
- Specijalni alati za razmjenu informacija kao što su: Google doc, Confluence, repozitoriji itd.
- „Živi“ sastanci na licu mjesta. Najefikasnija i najskuplja metoda.
Što trebate dobiti od klijenta?
Osnovne informacije. O čemu se radi u projektu. Njegov cilj i vrijednost. Ključne svrhe i planovi za budućnost. Poslovni ciljevi i strategije. Glavni problemi i željeni rezultat.
Informacije o projektu. Tehnološki stog, okviri, programski jezici. On-premise ili oblačna implementacija. Ako je projekt u oblaku, koje se usluge koriste. Koji arhitektonski i dizajnerski obrasci su primijenjeni.
Nefunkcionalni zahtjevi. Svi zahtjevi povezani s performansama, dostupnošću, lakom upotrebom sustava. Zahtjevi sigurnosti itd.
Osnovni use case-ovi i tokovi podataka.
Pristup izvornoj kodu. Najvažniji dio! Obavezno trebate dobiti pristup repozitorijima i dokumentaciji o tome kako sastaviti projekt.
Pristup infrastrukturi. Bilo bi dobro dobiti pristup stage ili produkcijskoj infrastrukturi, kako biste radili s 'živim' sustavom. Velika je sreća ako klijent ima alate za praćenje infrastrukture i performansi. O tim alatima ćemo razgovarati u sljedećem odjeljku.
Dokumentacija. Ako klijent ima dokumentaciju, to je dobar početak. Možda je zastarjela, ali i dalje je dobar početak. Nikada ne vjerujte dokumentaciji – provjeravajte je s klijentom, na stvarnoj infrastrukturi i u izvornom kodu.
Proces procjene arhitekture
Kako obraditi toliki broj informacija u tako kratkom vremenskom razdoblju? Prije svega, paralelizirajte rad.
DevOps bi trebao pogledati u infrastrukturu. Tehnički lider u kod. Inženjer performansi treba provjeriti metrike izvedbe. Stručnjaku za baze podataka se preporučuje dublje istražiti strukture podataka.
Ali to je idealan slučaj kada imate mnogo resursa. Obično procjenu projekta provodi jedna do tri osobe. Možete čak izvršiti procjenu i sami, što se često događa, ako imate odgovarajuće znanje i iskustvo u svim područjima projekta. U tom slučaju trebate automatizirati sve procese koliko god je to moguće.
Nažalost, dokumentaciju ćete morati pročitati ručno. Uz odgovarajuće iskustvo, brzo možete razumjeti kvalitetu dokumentacije. Što je istina, a što očito ne odgovara stvarnosti. Ponekad možete naići na arhitekturu u dokumentaciji koja nikada neće raditi u stvarnom životu. To je okidač za vas da razmislite o tome kako je to zapravo napravljeno u projektu.
Korisni alati za automatizaciju procjene projekta
Procjena koda je jednostavna vježba. Možete koristiti statičke analize koda koje će pokazati probleme s dizajnom, izvedbom i sigurnošću. Evo nekoliko njih:
je odličan alat za arhitekte. Prikazat će vam cjelokupnu sliku, ovisnost između modula i potencijalna područja za refaktoriranje. Kao i svi dobri alati, košta dobar novac, ali možete isprobati besplatnu verziju od 30 dana.
je stari dobri alat. Alat za statičku analizu koda. Omogućava identifikaciju lošeg koda, grešaka, problema sa sigurnošću za više od 20 programskih jezika.
Svi cloud pružatelji imaju alate za praćenje infrastrukture. To će vam omogućiti pravilno procijeniti učinkovitost infrastrukture s aspekta troškova i performansi. Za AWS to je . Za Azure jednostavno .
Dodatno praćenje performansi i logiranje pomoći će pronaći probleme s performansama na svim razinama. Počevši od baza podataka s neučinkovitim upitima, backend-a, pa sve do frontend-a. Čak i ako klijent nije ranije instalirao ove alate, možete ih prilično brzo integrirati u postojeći sustav kako biste odredili probleme s performansama.
Kao i uvijek, dobri alati koštaju. Mogu preporučiti nekoliko plaćenih alata. Naravno, možete koristiti open-source, ali će vam biti potrebno više vremena za to. I to treba učiniti unaprijed, a ne tijekom procjene arhitekture.
je alat za procjenu performansi aplikacija
je cloud usluga za praćenje sustava
Za testiranje sigurnosti postoje mnogi alati. Ovaj put ću vam preporučiti besplatan alat za skeniranje sustava.
je alat za skeniranje web aplikacija radi usklađenosti sa sigurnosnim standardima.
Sve okupljamo na jedno mjesto.
Pripremamo izvještaj
Započnite svoj izvještaj s podacima prikupljenim od klijenta. Opišite ciljeve projekta, ograničenja, nefunkcionalne zahtjeve. Nakon toga treba spomenuti sve ulazne podatke: izvorni kod, dokumentaciju, infrastrukturu.
Sljedeći korak. Navedite sve probleme koje ste pronašli ručno ili uz pomoć automatiziranih alata. Velike automatski generirane izvještaje stavite na kraj u odjeljak priloga. Ovdje treba biti kratkih i sažetih dokaza pronađenih problema.
Prioritizirajte pronađene probleme prema skali error, warning, info. Možete odabrati svoju skalu, ali ovo je općenito prihvaćeno.
Kao pravi arhitekt, obavezni ste pružiti preporuke za rješavanje pronađenih problema. Opišite poboljšanja i vrijednost za poslovanje koju će klijent dobiti. Kako prikazati vrijednost za poslovanje od o kojoj smo ranije razgovarali.
Pripremite roadmap s malim iteracijama. Svaka iteracija treba sadržavati vrijeme za izvršenje, opis, količinu potrebnih resursa za poboljšanje, tehničku vrijednost i vrijednost za poslovanje.
Završavamo procjenu arhitekture i pružamo klijentu izvještaj.
Nikada ne šaljite izvještaj samo putem e-pošte. Mogu ga ili uopće ne pročitati ili pročitati i ne razumjeti bez odgovarajućeg objašnjenja. Ukratko – živa komunikacija pomaže eliminirati nesporazume među ljudima. Trebali biste zakazati sastanak s klijentom i objasniti pronađene probleme, s naglaskom na najznačajnije. Treba obratiti pažnju klijentu na probleme o kojima možda nije ni znao. Kao što su problemi sa sigurnošću i objasniti kako mogu utjecati na poslovanje. Prikazujte svoj roadmap s poboljšanjima i raspravite različite opcije, koje su prikladnije za klijenta. To može biti vrijeme, resursi, opseg radova.
Kao zaključak vašeg sastanka, pošaljite klijentu svoj izvještaj.
Za kraj
Procjena arhitekture je složen proces. Da biste ispravno proveli procjenu, trebate imati dovoljno iskustva i znanja.
To je stvarno – pružiti klijentu korisne rezultate za njega i njegovo poslovanje u samo tjedan dana. Čak i ako to radite sami.
Iz mog iskustva, mnoge su se poboljšanja obustavljale na sredini, a ponekad tako nikada nisu ni počinjale. Oni koji su birali zlatnu sredinu i radili samo dio poboljšanja najkorisnijih za poslovanje s minimalnim saznanjima, značajno su poboljšali kvalitetu svog proizvoda. Oni koji ništa nisu radili nakon nekoliko godina mogli su potpuno zatvoriti projekt.
Vaš cilj je pokazati klijentu maksimalna poboljšanja za minimalnu cijenu.
Ostali članci iz odjela možete pročitati u slobodno vrijeme.
Želim vam čisti kod i dobra arhitektonska rješenja.
Naša Facebook grupa — .
Izvor: habr.com
