Na začetku je vedno težko razumeti velik in star projekt. Arhitektura je ena izmed dejavnosti ocenjevanja arhitektov. Običajno morate delati z velikimi, starimi projekti, rezultati pa morajo biti dostavljeni v enem tednu.
Kako ovrednotiti projekt s 100 ali več vrsticami kode v enem tednu, hkrati pa zagotoviti rezultate, ki so za stranko resnično uporabni.
Večina arhitektov in tehničnih vodij se je srečala s podobnimi ocenami projektov. To lahko izgleda kot napol formalni postopek ali kot ločena storitev, kot se izvaja v našem podjetju, tako ali drugače se je večina od vas že soočila s tem.
Izvirnik v angleščini za vaše nerusko govoreče prijatelje je tukaj: .
Pristop našega podjetja
Povedal vam bom, kako to poteka v našem podjetju in kako ravnam v podobnih situacijah, vendar lahko ta pristop enostavno spremenite glede na potrebe vašega projekta in podjetja.
Obstajata dve vrsti ocenjevanja arhitekture.
Notranji – običajno to počnemo za projekte znotraj podjetja. Vsak projekt lahko zahteva oceno arhitekture iz več razlogov:
- Ekipa misli, da je njihov projekt popoln in to je sumljivo. Imeli smo takšne primere in pogosto je v takih projektih vse daleč od idealnega.
- Ekipa želi preizkusiti svoj projekt in svoje rešitve.
- Ekipa ve, da so stvari slabe. Lahko celo navedejo glavne težave in vzroke, vendar želijo popoln seznam težav in priporočil za izboljšanje projekta.
Zunanji je bolj formalen postopek kot notranja ocena. Stranka vedno pride samo v enem primeru, ko je vse slabo - zelo slabo. Običajno stranka razume, da obstajajo globalni problemi, vendar ne more pravilno identificirati vzrokov in jih razdeliti na komponente.
Ocenjevanje arhitekture za zunanjega odjemalca je bolj zapleten primer. Postopek bi moral biti bolj formalen. Projekti so vedno veliki in stari. Imajo veliko težav, hroščev in pokvarjene kode. Najkasneje v nekaj tednih naj bi bilo pripravljeno poročilo o opravljenem delu, ki naj bi vključevalo glavne probleme in priporočila za izboljšave. Če se torej ukvarjamo z zunanjo presojo projekta, potem bo notranja presoja mačji kašelj. Razmislimo o najtežjem primeru.
Ocena arhitekture projekta podjetja
Tipičen projekt, ki ga je treba oceniti, je velik, star podjetniški projekt z veliko težavami. K nam pride naročnik in nas prosi, da mu popravimo projekt. Kot pri ledeni gori, klient vidi le vrh svojih težav in nima pojma, kaj je pod vodo (v globini kode).
Težave, o katerih se stranka lahko pritožuje in se jih morda zaveda:
- Težave z zmogljivostjo
- Težave z uporabnostjo
- Dolgoročna uporaba
- Pomanjkanje enotnih in drugih testov
Težave, ki se jih naročnik najverjetneje ne zaveda, lahko pa so prisotne v projektu:
- Varnostne težave
- Težave z zasnovo
- Napačna arhitektura
- Algoritemske napake
- Neprimerne tehnologije
- Tehnični dolg
- Napačen razvojni proces
Formalni postopek pregleda arhitekture
To je uradni postopek, ki mu sledimo kot podjetje, vendar ga lahko prilagodite glede na vaše podjetje in projekt.
Zahteva stranke
Naročnik prosi za oceno arhitekture trenutnega projekta. Odgovorna oseba na naši strani zbere osnovne podatke o projektu in izbere potrebne strokovnjake. Odvisno od projekta so to lahko različni strokovnjaki.
Arhitekt rešitev – glavna oseba, odgovorna za ocenjevanje in koordinacijo (in pogosto edina).
Zložite posebne strokovnjake – .Net, Java, Python in drugi tehnični strokovnjaki, odvisno od projekta in tehnologij
Strokovnjaki za oblake – to so lahko arhitekti oblaka Azure, GCP ali AWS.
Infrastruktura – DevOps, sistemski skrbnik itd.
Drugi strokovnjaki – kot so veliki podatki, strojno učenje, inženir uspešnosti, varnostni strokovnjak, vodja QA.
Zbiranje informacij o projektu
Zbrati morate čim več informacij o projektu. Glede na situacijo lahko uporabite različne tehnike:
- Vprašalniki in drugi načini komunikacije po pošti. Najbolj neučinkovit način.
- Spletna srečanja.
- Posebna orodja za izmenjavo informacij kot so: Google doc, Confluence, repozitoriji itd.
- Srečanja v živo na kraju samem. Najučinkovitejši in najdražji način.
Kaj bi morali dobiti od stranke?
Osnovni podatki. O čem govori projekt? Njegov namen in vrednost. Glavni cilji in načrti za prihodnost. Poslovni cilji in strategije. Glavni problemi in želeni rezultati.
Informacije o projektu. Tehnološki sklad, ogrodja, programski jeziki. Namestitev na mestu uporabe ali v oblaku. Če je projekt v oblaku, katere storitve se uporabljajo. Kateri arhitekturni in oblikovalski vzorci so bili uporabljeni.
Nefunkcionalne zahteve. Vse zahteve v zvezi z zmogljivostjo, razpoložljivostjo in enostavnostjo uporabe sistema. Varnostne zahteve itd.
Osnovni primeri uporabe in podatkovni tokovi.
Dostop do izvorne kode. Najpomembnejši del! Vsekakor bi morali dobiti dostop do repozitorijev in dokumentacije o tem, kako zgraditi projekt.
Dostop do infrastrukture. Lepo bi bilo imeti dostop do odra ali produkcijske infrastrukture za delo s sistemom v živo. Velik uspeh je, če ima naročnik 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 zastarel, vendar je še vedno dober začetek. Nikoli ne zaupajte dokumentaciji – preizkusite jo pri odjemalcu, na resnični infrastrukturi in v izvorni kodi.
Postopek ocenjevanja arhitekture
Kako lahko v tako kratkem času obdelamo tako veliko količino informacij? Najprej vzporedite delo.
DevOps bi moral pogledati infrastrukturo. Tehnični vodnik v kodo. Inženir uspešnosti za ogled meritev uspešnosti. Strokovnjak za baze podatkov bi se moral poglobiti v podatkovne strukture.
Toda to je idealen primer, ko imate veliko sredstev. Običajno projekt ocenjuje ena do tri osebe. Predračun lahko opravite celo sami, kar se pogosto zgodi, če imate ustrezno znanje in izkušnje na vseh področjih projekta. V tem primeru morate vse procese čim bolj avtomatizirati.
Na žalost boste morali dokumentacijo prebrati ročno. S pravo količino izkušenj lahko hitro razumete kakovost dokumentacije. Kaj je res in kaj očitno ne sovpada z realnostjo. Včasih lahko v dokumentaciji vidite arhitekturo, ki v resničnem življenju nikoli ne bo delovala. To je sprožilec, da razmišljate o tem, kako je bilo v projektu izvedeno v resnici.
Uporabna orodja za avtomatsko ocenjevanje projektov
Ocenjevanje kode je preprosta vaja. Uporabite lahko statične analizatorje kode, ki vam bodo pokazali težave z zasnovo, zmogljivostjo in varnostjo. Tukaj je nekaj izmed njih:
je odlično orodje za arhitekta. Pokazal vam bo celotno sliko, odvisnosti med moduli in potencialna področja za preoblikovanje. Kot vsa dobra orodja tudi to stane dober denar, vendar lahko izkoristite 30-dnevno preskusno različico.
- dobro staro orodje. Orodje za analizo statične kode. Omogoča prepoznavanje slabe kode, hroščev in varnostnih težav za več kot 20 programskih jezikov.
Vsi ponudniki oblakov imajo orodja za spremljanje infrastrukture. To vam bo omogočilo, da pravilno ocenite učinkovitost vaše infrastrukture v smislu stroškov in učinkovitosti. Za AWS je to . Za Azure je enostavno .
Dodatno spremljanje zmogljivosti in beleženje bo pomagalo odkriti težave z zmogljivostjo na vseh ravneh. Začenši z bazo podatkov z neučinkovitimi poizvedbami, zaledjem in konča s sprednjim delom. Tudi če odjemalec še ni namestil teh orodij, jih lahko dokaj hitro integrirate v obstoječi sistem, da prepoznate težave z zmogljivostjo.
Kot vedno so dobra orodja vredna tega. Lahko priporočim nekaj plačljivih orodij. Seveda lahko uporabite odprtokodno, vendar vam bo vzelo več časa. In to je treba storiti vnaprej, ne med procesom ocenjevanja arhitekture.
– orodje za ocenjevanje zmogljivosti aplikacije
– storitev spremljanja sistema v oblaku
Za testiranje varnosti je na voljo veliko orodij. Tokrat vam bom priporočil brezplačno orodje za pregledovanje sistema.
– orodje za skeniranje spletnih aplikacij glede skladnosti z varnostnimi standardi.
Sestavimo vse skupaj v eno celoto.
Priprava poročila
Začnite poročilo s podatki, ki ste jih zbrali od stranke. Opišite cilje projekta, omejitve, nefunkcionalne zahteve. Za tem je treba navesti vse vhodne podatke: izvorno kodo, dokumentacijo, infrastrukturo.
Naslednji korak. Navedite morebitne težave, ki ste jih našli ročno ali z avtomatiziranimi orodji. Postavite velika samodejno ustvarjena poročila na koncu v razdelku z aplikacijami. Obstajati morajo kratki in jedrnati dokazi o ugotovljenih težavah.
Dajte prednost težavam, ki so bile ugotovljene na lestvici napak, opozoril in informacij. Lahko si izberete svojo lestvico, vendar je to splošno sprejeta.
Kot pravi arhitekt ste odgovorni zagotoviti priporočila za odpravo ugotovljenih težav. Opišite izboljšave in poslovno vrednost, ki jih bo stranka prejela. Kako prikazati poslovno vrednost iz smo razpravljali prej.
Pripravite načrt z majhnimi ponovitvami. Vsaka ponovitev mora vsebovati čas za dokončanje, opis, količino virov, potrebnih za izboljšavo, tehnično vrednost in poslovno vrednost.
Izdelamo oceno arhitekture in naročniku izdelamo poročilo
Nikoli ne pošljite poročila samo po pošti. Morda se sploh ne prebere ali pa se ne prebere in razume brez ustrezne razlage. Skratka, živa komunikacija pomaga odpraviti nesporazume med ljudmi. Dogovorite se za sestanek s stranko in se pogovorite o ugotovljenih težavah, pri čemer se osredotočite na najpomembnejše. Stranko je vredno opozoriti na težave, ki se jih morda niti ne zaveda. Na primer varnostna vprašanja in pojasnite, kako bi lahko vplivala na poslovanje. Pokažite svoj načrt z izboljšavami in razpravljajte o različnih možnostih, ki so bolj primerne za stranko. To so lahko čas, sredstva, količina dela.
Kot povzetek vašega sestanka pošljite svoje poročilo stranki.
Na koncu
Ocenjevanje arhitekture je kompleksen proces. Za pravilno ocenjevanje morate imeti dovolj izkušenj in znanja.
Stranki je mogoče že v enem tednu zagotoviti rezultate, koristne zanjo in za njeno poslovanje. Tudi če to počneš sam.
Glede na moje izkušnje je bilo veliko izboljšav prenesenih na sredini in se včasih sploh niso začele. Tisti, ki so zase izbrali zlato sredino in z minimalnimi stroški dela naredili le del izboljšav, ki so bile najbolj uporabne za posel, so bistveno izboljšali kakovost svojega izdelka. Tisti, ki niso naredili nič, so lahko po nekaj letih projekt popolnoma zaprli.
Vaš cilj je stranki pokazati največje možne izboljšave za najnižjo ceno.
Drugi članki iz rubrike lahko berete v prostem času.
Želim vam čisto kodo in dobre arhitekturne odločitve.
Naša facebook skupina - .
Vir: www.habr.com