Na začetku je vedno težko razumeti velik in star projekt. Architecture assessment je ena izmed dejavnosti arhitekta. Običajno je treba delati z velikimi, starimi projekti, rezultati pa morajo biti dostavljeni v enem tednu.
Kako oceniti projekt z več kot 100 tisoč vrsticami kode v enem tednu in hkrati zagotoviti resnično koristne rezultate za stranko?
Večina arhitektov in vodij ekip se je srečala s podobnimi ocenami projektov. To je lahko videti kot polformalni postopek ali kot ločena storitev, kot je to urejeno v naši družbi; tako ali tako je večina od vas imela s tem izkušnje.
Izvirnik v angleščini za vaše nerusko govoreče prijatelje je tukaj: .
Pristop v naši družbi
Povedal vam bom, kako to deluje v naši družbi in kako ravnam v takšnih situacijah, vendar lahko ta pristop enostavno prilagodite potrebam vašega projekta in podjetja.
Obstajata dve vrsti architecture assessment.
Notranji – običajno ga izvajamo za projekte znotraj družbe. Vsak projekt lahko zaprosi za oceno arhitekture iz več razlogov:
- Ekipa meni, da je njihov projekt popoln, kar je sumljivo. Imeli smo takšne primere, in večinoma v takšnih projektih vse ni tako idealno.
- Ekipa želi preveriti svoj projekt in svoje rešitve.
- Ekipa ve, da je vse slabo. Morda lahko naštejejo glavne težave in vzroke, vendar želijo dobiti popoln seznam težav ter priporočila za izboljšave projekta.
Zunanji – to je bolj formalen postopek kot notranja ocena. Stranka pride vedno samo v enem primeru, ko je vse slabo – zelo slabo. Običajno stranka razume, da so globalne težave, vendar ne more pravilno opredeliti vzrokov in razdeliti na sestavne dele.
Ocena arhitekture za zunanjo stranko je bolj zapleten primer. Postopek mora biti bolj formalen. Projekti so vedno veliki in stari. V njih je veliko težav, napak in slabo napisanega kode. Poročilo o opravljenem delu mora biti pripravljeno v nekaj tednih največ, kjer morajo biti glavne težave in priporočila za izboljšanje. Zato, če se spoprijemo z zunanjo oceno projekta, bo notranja ocena le mala malenkost. Poglejmo najbolj zapleten primer.
Ocena arhitekture podjetniškega projekta
Tipičan projekt za procjenu je veliki, stari, enterprise projekt s brojnim problemima. Klijent dolazi kod nas i traži da popravimo njegov projekt. To je poput ledenjaka, klijent vidi samo vrh svojih problema i ne sluti što se nalazi ispod površine (u dubini koda).
Problemi na koje se klijent može požaliti i za koje može znati:
- Problemi s performansama
- Problemi s upotrebljivošću aplikacije (Usability)
- Dugotrajna implementacija
- Nedostatak unit i drugih testova
Problemi o kojima klijent vjerojatno nije svjestan, ali mogu postojati u projektu:
- Problemi s sigurnošću
- Problemi s dizajnom
- Netačna arhitektura
- Algoritamske greške
- Neodgovarajuće tehnologije
- Tehnički dug
- Pogrešan proces razvoja
Formalni proces ocjenjivanja arhitekture
To je formalni proces kojeg se pridržavamo u tvrtki, ali ga možete prilagoditi prema svojoj tvrtki i projektu.
Zahtjev od klijenta
Klijent traži procjenu arhitekture trenutnog projekta. Odgovorna osoba s naše strane prikuplja osnovne informacije o projektu i bira potrebne stručnjake. Ovisno o projektu, to mogu biti različiti stručnjaci.
Solution Architect – glavna osoba odgovorna za procjenu i koordinaciju (i često jedina).
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 – poput 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 različite tehnike ovisno o situaciji:
- Anketni upitnici i druge metode komunikacije putem e-maila. Najmanje učinkovita metoda.
- Online sastanci.
- Specijalni alati za razmjenu informacija, poput: Google doc, Confluence, repozitoriji itd.
- „Živi“ sastanci na licu mjesta. Najučinkovitija i najskuplja metoda.
Što trebate 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 ishod.
Informacije o projektu. Tehnološki sklad, okviri, programski jeziki. On-premise ali oblačna implementacija. Če je projekt v oblaku, katere storitve se uporabljajo. Kateri arhitekturni in dizajni vzorci so bili uporabljeni.
Ne funkcionalne zahteve. Vse zahteve, povezane z zmogljivostjo, dostopnostjo, uporabnostjo sistema. Zahteve glede varnosti itd.
Osnovni uporabniški scenariji in podatkovni tokovi.
Dostop do izvorne kode. Najpomembnejši del! Obvezno morate pridobiti dostop do skladišč in dokumentacije, kako zgraditi projekt.
Dostop do infrastrukture. Dobro bi bilo pridobiti dostop do stage ali produkcijske infrastrukture, da delate s »živo« sistemom. To je velika sreča, če ima stranka orodja za spremljanje infrastrukture in zmogljivosti. O teh orodjih bomo govorili v naslednjem razdelku.
Dokumentacija. Če ima stranka dokumentacijo, je to dober začetek. Morda je zastarela, a je vseeno dober začetek. Nikoli ne verjemite dokumentaciji – preverite jo s stranko, na realni infrastrukturi in v izvorni kodi.
Postopek ocenjevanja arhitekture
Kako obdelati tako veliko količino informacij v tako kratkem času? Predvsem razporedite delo.
DevOps naj si ogleda infrastrukturo. Tehnični vodja v kodo. Inženir zmogljivosti naj si ogleda metrike po zmogljivosti. Specialist za baze podatkov naj poglobi strukture podatkov.
Toda to je idealen primer, ko imate veliko virov. Običajno oceno projekta izvede od enega do treh ljudi. Ocenite lahko celo sami, kar se pogosto zgodi, če imate ustrezno znanje in izkušnje na vseh področjih projekta. V tem primeru morate avtomatizirati vse procese, kolikor je le mogoče.
Žal boste morali dokumentacijo prebrati ročno. Ob ustreznih izkušnjah boste lahko precej hitro razumeli kakovost dokumentacije. Kaj je res, in kaj očitno ne ustreza dejanskosti. Včasih lahko naletite na arhitekturo v dokumentaciji, ki nikoli ne bo delovala v resničnem svetu. To je sprožilec, da razmislite, kako je v resnici narejeno v projektu.
Koristna orodja za avtomatizacijo ocene projekta
Ocena kode je preprosta naloga. Uporabite lahko statične analizatorje kode, ki bodo pokazali težave z oblikovanjem, zmogljivostjo in varnostjo. Tu je nekaj izmed njih:
je odlično orodje za arhitekta. Pokaže vam celotno sliko, odvisnosti med moduli in potencialna področja za refaktoring. Kot pri vseh dobrih orodjih ima svojo ceno, a hkrati lahko izkoristite 30-dnevno preizkušnjo.
je staro znano orodje. Orodje za statično analizo kode. Omogoča odkrivanje slabe kode, napak in varnostnih težav za več kot 20 programskih jezikov.
Vsi oblačni ponudniki imajo orodja za spremljanje infrastrukture. To vam omogoča pravilno oceno učinkovitosti infrastrukture z vidika stroškov in zmogljivosti. Za AWS je to . Za Azure je preprosto .
Dodatno spremljanje zmogljivosti in beleženje bo pomagalo pri iskanju težav z zmogljivostjo na vseh ravneh. Začne se pri podatkovnih bazah z neučinkovitimi poizvedbami, backendu in konča pri frontend-u. Tudi če kupec teh orodij prej ni namestil, jih lahko razmeroma hitro integrirate v obstoječi sistem, da določite težave z zmogljivostjo.
Kot vedno, dobra orodja nekaj stanejo. Lahko priporočim nekaj plačljivih orodij. Seveda lahko uporabite odprtokodna, a za to potrebujete več časa. To naj bo opravljeno vnaprej, ne pa med oceno arhitekture.
orodje za oceno zmogljivosti aplikacij
oblačna storitev za spremljanje sistemov
Za testiranje varnosti je veliko orodij. Tokrat vam priporočam brezplačno orodje za skeniranje sistema.
je orodje za skeniranje spletnih aplikacij glede skladnosti z varnostnimi standardi.
Združujemo vse v celoto.
Pripravljamo poročilo
Začnite svoje poročilo s podatki, zbranimi od stranke. Opisujte cilje projekta, omejitve in nefunkcionalne zahteve. Po tem je treba omeniti vse vhodne podatke, izvorno kodo, dokumentacijo in infrastrukturo.
Nadaljni korak. Določite vse težave, ki ste jih odkrili ročno ali s pomočjo avtomatiziranih orodij. Obsežne avtomatsko generirane poročila postavite na konec v razdelek prilog. Tukaj morajo biti kratki in jedrnati dokazi o ugotovljenih težavah.
Prioritizirajte odkrite težave po lestvici napaka, opozorilo, informacija. Izbrati lahko svojo lestvico, vendar je ta splošno sprejeta.
Kot pravi arhitekt morate zagotoviti priporočila za reševanje ugotovljenih težav. Opisujte izboljšave in vrednost za poslovanje, ki jo bo stranka pridobila. Kako prikazati vrednost za poslovanje od smo se pogovarjali prej.
Pripravite načrt z majhnimi iteracijami. Vsaka iteracija naj vsebuje čas za izvedbo, opis, število virov potrebnih za izboljšanje, tehnično vrednost in vrednost za poslovanje.
Zaključujemo oceno arhitekture in predajamo stranki poročilo.
Nikoli ne pošiljajte poročila zgolj po pošti. Morda ga sploh ne bodo prebrali ali ga preberete in ne razumejo brez ustreznega pojasnila. Krajša komunikacija pomaga odpraviti nesporazume med ljudmi. Sklicati se morate na sestanek s stranko in govoriti o ugotovljenih težavah, pri čemer poudarite najpomembnejše. Vredni pa je opozoriti stranko na težave, za katere morda sploh ni vedela. Takšne kot so težave s varnostjo in razložite, kako lahko vplivajo na poslovanje. Prikazujte svojo načrt z izboljšavami in razpravljajte o različnih možnostih, ki so bolj primerne za stranko. To lahko vključuje čas, vire, obseg dela.
Kot povzetek vašega sestanka pošljite stranki svoje poročilo.
Na záver
Ocena arhitekture je zapleten postopek. Da bi oceno izvedli pravilno, morate imeti dovolj izkušenj in znanja.
To je mogoče — zagotoviti stranki koristne rezultate za njega in njegovo podjetje v vsega enem tednu. Tudi če to počnete sami.
Glede na moje izkušnje so se mnoge izboljšave ustavile na pol poti, včasih pa tudi nikoli niso začele. Tisti, ki so izbrali zlato sredino in izvedli le del izboljšav, ki so bile maksimalno koristne za poslovanje z minimalnimi napori, so znatno izboljšali kakovost svojega izdelka. Tisti, ki niso storili ničesar, so čez nekaj let lahko celo zaprli projekt.
Vaša cilj je pokazati kupcu maksimalna poboljšanja po minimalnoj cijeni.
Drugi članci iz sekcije može se pročitati u slobodno vrijeme.
Želim vam čist kod i dobra arhitektonska rešenja.
Naša facebook grupa — .
Izvor: habr.com
