Na početku je uvijek teško razumjeti veliki i stari projekt. Arhitektura je jedna od aktivnosti ocjenjivanja arhitekta. Obično morate raditi s velikim, starim projektima, a rezultati moraju biti isporučeni za tjedan dana.
Kako procijeniti projekt od 100 tisuća ili više redaka koda u tjednu, a da pritom još uvijek daje rezultate koji su zaista korisni klijentu.
Većina arhitekata i tehničkih voditelja susrela se sa sličnim procjenama projekata. Ovo može izgledati kao poluformalni proces ili kao zasebna usluga kao što se radi u našoj tvrtki, na ovaj ili onaj način većina vas se suočila s tim.
Izvornik na engleskom za vaše prijatelje koji ne govore ruski je ovdje: .
Pristup naše tvrtke
Reći ću vam kako to funkcionira u našoj tvrtki i kako ja postupam u sličnim situacijama, no vi možete lako promijeniti ovaj pristup prema potrebama vašeg projekta i tvrtke.
Postoje dvije vrste procjene arhitekture.
Interijer – obično to radimo za projekte unutar tvrtke. Svaki projekt može zahtijevati procjenu arhitekture iz nekoliko razloga:
- Tim misli da je njihov projekt savršen i to je sumnjivo. Imali smo takvih slučajeva, a često je u takvim projektima sve daleko od idealnog.
- Tim želi testirati svoj projekt i svoja rješenja.
- Tim zna da su stvari loše. Oni čak mogu navesti glavne probleme i uzroke, ali žele potpuni popis problema i preporuke za poboljšanje projekta.
Vanjski je formalniji proces od interne procjene. Klijent uvijek dolazi samo u jednom slučaju, kada je sve loše - jako loše. Obično klijent razumije da postoje globalni problemi, ali ne može točno identificirati uzroke i raščlaniti ih na komponente.
Procjena arhitekture za vanjskog klijenta je složeniji slučaj. Proces bi trebao biti formalniji. Projekti su uvijek veliki i stari. Imaju puno problema, grešaka i krivog koda. Za najviše nekoliko tjedana trebalo bi biti spremno izvješće o obavljenom poslu koje bi trebalo sadržavati glavne probleme i preporuke za poboljšanje. Dakle, ako se bavimo vanjskom ocjenom projekta, onda će interna procjena biti piece cake. Razmotrimo najteži slučaj.
Procjena arhitekture projekta poduzeća
Tipičan projekt za ocjenu je veliki, stari, poslovni projekt s puno problema. Dolazi nam klijent i traži da mu sredimo projekt. To je kao sa santom leda, klijent vidi samo vrh svojih problema i nema pojma što je ispod vode (u dubini koda).
Problemi na koje se kupac može žaliti i kojih bi mogao biti svjestan:
- Problemi s izvedbom
- Problemi s upotrebljivošću
- Dugoročna primjena
- Nedostatak jediničnih i drugih testova
Problemi kojih klijent najvjerojatnije nije svjestan, ali mogu biti prisutni u projektu:
- Sigurnosni problemi
- Problemi dizajna
- Pogrešna arhitektura
- Algoritamske greške
- Neprikladne tehnologije
- Tehnički dug
- Pogrešan proces razvoja
Formalni proces pregleda arhitekture
Ovo je formalni proces koji slijedimo kao tvrtka, ali ga možete prilagoditi ovisno o vašoj tvrtki i projektu.
Zahtjev klijenta
Klijent traži procjenu arhitekture trenutnog projekta. Odgovorna osoba s naše strane prikuplja osnovne podatke o projektu i odabire potrebne stručnjake. Ovisno o projektu, to mogu biti različiti stručnjaci.
Arhitekt rješenja – glavna osoba odgovorna za procjenu i koordinaciju (a često i jedina).
Stack specifični stručnjaci – .Net, Java, Python i drugi tehnički stručnjaci ovisno o projektu i tehnologijama
Stručnjaci za oblak – to mogu biti Azure, GCP ili AWS arhitekti oblaka.
Infrastruktura – DevOps, administrator sustava, itd.
Ostali stručnjaci – kao što su veliki podaci, strojno učenje, inženjer izvedbe, sigurnosni stručnjak, QA voditelj.
Prikupljanje informacija o projektu
Trebali biste prikupiti što više informacija o projektu. Možete koristiti različite tehnike ovisno o situaciji:
- Upitnici i drugi načini komunikacije putem pošte. Najneučinkovitiji način.
- Online sastanci.
- Posebni alati za razmjenu informacija kao što su: Google doc, Confluence, repozitoriji itd.
- Sastanci “uživo” na licu mjesta. Najučinkovitiji i najskuplji način.
Što biste trebali dobiti od klijenta?
Osnovne informacije. O čemu se radi u projektu? Njegova svrha i vrijednost. Glavni ciljevi i planovi za budućnost. Poslovni ciljevi i strategije. Glavni problemi i željeni rezultati.
Informacije o projektu. Tehnološki skup, okviri, programski jezici. Lokalna implementacija ili implementacija u oblaku. Ako je projekt u oblaku, koje se usluge koriste. Koji su arhitektonski i dizajnerski uzorci korišteni.
Nefunkcionalni zahtjevi. Svi zahtjevi koji se odnose na performanse, dostupnost i jednostavnost korištenja sustava. Sigurnosni zahtjevi itd.
Osnovni slučajevi uporabe i tokovi podataka.
Pristup izvornom kodu. Najvažniji dio! Svakako biste trebali dobiti pristup repozitoriju i dokumentaciji o izradi projekta.
Pristup infrastrukturi. Bilo bi lijepo imati pristup pozornici ili produkcijskoj infrastrukturi za rad sa sustavom uživo. Veliki je uspjeh ako klijent ima alate za praćenje infrastrukture i performansi. O tim ćemo alatima govoriti u sljedećem odjeljku.
Документация. Ako klijent ima dokumentaciju, to je dobar početak. Možda je zastario, ali je još uvijek dobar početak. Nikada ne vjerujte dokumentaciji - testirajte je s klijentom, na stvarnoj infrastrukturi iu izvornom kodu.
Proces evaluacije arhitekture
Kako se može obraditi toliku količinu informacija u tako kratkom vremenu? Prije svega, paralelizirati rad.
DevOps bi trebao pogledati infrastrukturu. Tehnički uvod u kod. Inženjer izvedbe za pregled metrike izvedbe. Stručnjak za baze podataka trebao bi dublje istražiti strukture podataka.
Ali ovo je idealan slučaj kada imate puno resursa. Obično jedna do tri osobe ocjenjuju projekt. Možete čak i sami napraviti procjenu, što je često slučaj ako imate odgovarajuće znanje i iskustvo u svim područjima projekta. U ovom slučaju morate automatizirati sve procese što je više moguće.
Nažalost, dokumentaciju ćete morati čitati ručno. Uz pravu količinu iskustva, možete brzo shvatiti kvalitetu dokumentacije. Što je istina, a što se očito ne poklapa sa stvarnošću. Ponekad možete vidjeti arhitekturu u dokumentaciji koja nikada neće funkcionirati u stvarnom životu. To vam je okidač za razmišljanje kako je to u stvarnosti urađeno u projektu.
Korisni alati za automatizaciju evaluacije projekta
Evaluacija koda je jednostavna vježba. Možete koristiti statičke analizatore koda koji će vam pokazati dizajn, performanse i sigurnosne probleme. Evo nekoliko njih:
je izvrstan alat za arhitekta. Pokazat će vam širu sliku, ovisnosti između modula i potencijalna područja za refaktoriranje. Kao i svi dobri alati, košta dobro, ali možete iskoristiti 30-dnevnu probnu verziju.
- dobar stari alat. Alat za statičku analizu koda. Omogućuje prepoznavanje lošeg koda, grešaka i sigurnosnih problema za više od 20 programskih jezika.
Svi pružatelji usluga u oblaku imaju alate za praćenje infrastrukture. To će vam omogućiti pravilnu procjenu učinkovitosti vaše infrastrukture u smislu troškova i performansi. Za AWS ovo je . Lako je za Azure .
Dodatno praćenje performansi i bilježenje pomoći će u pronalaženju problema s performansama na svim razinama. Počevši od baze podataka s neučinkovitim upitima, pozadine pa sve do sučelja. Čak i ako klijent prethodno nije instalirao ove alate, možete ih prilično brzo integrirati u postojeći sustav kako biste identificirali probleme s performansama.
Kao i uvijek, dobri alati su vrijedni toga. Mogu preporučiti par alata koji se plaćaju. Naravno, možete koristiti open-source, ali će vam trebati više vremena. I to treba učiniti unaprijed, a ne tijekom procesa arhitektonske procjene.
– alat za procjenu izvedbe aplikacije
– usluga nadzora sustava u oblaku
Dostupni su mnogi alati za testiranje sigurnosti. Ovaj put ću vam preporučiti besplatni alat za skeniranje sustava.
– alat za skeniranje web aplikacija radi usklađenosti sa sigurnosnim standardima.
Spojimo sve u jednu cjelinu.
Priprema izvještaja
Započnite svoje izvješće s podacima koje ste prikupili od klijenta. Opišite ciljeve projekta, ograničenja, nefunkcionalne zahtjeve. Nakon toga treba navesti sve ulazne podatke: izvorni kod, dokumentaciju, infrastrukturu.
Sljedeći korak. Navedite sve probleme koje ste pronašli ručno ili pomoću automatiziranih alata. Postavite velika automatski generirana izvješća na kraju u odjeljak za aplikacije. Treba postojati kratak i jezgrovit dokaz o pronađenim problemima.
Dajte prioritet problemima pronađenim na ljestvici grešaka, upozorenja i informacija. Možete odabrati vlastitu ljestvicu, ali ovo je općeprihvaćena.
Kao pravi arhitekt, vaša je odgovornost dati preporuke za ispravljanje pronađenih problema. Opišite poboljšanja i poslovnu vrijednost koju će kupac dobiti. Kako pokazati poslovnu vrijednost iz razgovarali smo ranije.
Pripremite plan puta s malim ponavljanjima. Svaka iteracija treba sadržavati vrijeme potrebno za dovršetak, opis, količinu resursa potrebnih za poboljšanje, tehničku vrijednost i poslovnu vrijednost.
Završavamo procjenu arhitekture i klijentu dostavljamo izvješće
Nikada nemojte samo poslati izvješće poštom. Možda se uopće ne čita ili se ne može pročitati i razumjeti bez odgovarajućeg objašnjenja. Ukratko, živa komunikacija pomaže u uklanjanju nesporazuma među ljudima. Trebali biste zakazati sastanak s klijentom i razgovarati o pronađenim problemima, fokusirajući se na one najvažnije. Vrijedno je klijentu skrenuti pozornost na probleme kojih možda nije ni svjestan. Kao što su sigurnosna pitanja i objasnite kako bi ona mogla utjecati na poslovanje. Pokažite svoj plan s poboljšanjima i razgovarajte o različitim opcijama koje su prikladnije za klijenta. To može biti vrijeme, resursi, količina posla.
Kao sažetak vašeg sastanka, pošaljite svoje izvješće klijentu.
U zaključku
Vrednovanje arhitekture je složen proces. Za kvalitetnu procjenu potrebno je imati dovoljno iskustva i znanja.
Klijentu je moguće pružiti rezultate korisne za njega i njegovo poslovanje u samo tjedan dana. Čak i ako to radite sami.
Na temelju mog iskustva, mnoga su poboljšanja preuzeta u sredini, a ponekad se nikad nisu pokrenula. Oni koji su za sebe odabrali zlatnu sredinu i napravili samo dio poboljšanja koja su bila najkorisnija za poslovanje uz minimalne troškove rada značajno su poboljšali kvalitetu svog proizvoda. Oni koji nisu radili ništa mogli su nakon par godina potpuno zatvoriti projekt.
Vaš cilj je pokazati klijentu maksimalna poboljšanja za minimalnu cijenu.
Ostali članci iz rubrike možete čitati u slobodno vrijeme.
Želim vam čist kod i dobre arhitektonske odluke.
Naša facebook grupa - .
Izvor: www.habr.com