Iš pradžių visada sunku suprasti didelį ir seną projektą. Architektūra yra viena iš architekto vertinimo veiklų. Dažniausiai tenka dirbti su dideliais, senais projektais, o rezultatai turi būti pateikti per savaitę.
Kaip įvertinti 100 XNUMX ar daugiau kodo eilučių projektą per savaitę, tuo pačiu užtikrinant klientui tikrai naudingus rezultatus.
Dauguma architektų ir techninių vadovų susidūrė su panašiais projektų vertinimais. Tai gali atrodyti kaip pusiau formalus procesas arba kaip atskira paslauga, kaip tai daroma mūsų įmonėje, vienaip ar kitaip dauguma iš jūsų yra su tuo susidūrę.
Originalas anglų kalba jūsų rusiškai nekalbantiems draugams yra čia: .
Mūsų įmonės požiūris
Papasakosiu, kaip tai veikia mūsų įmonėje ir kaip elgiuosi panašiose situacijose, tačiau šį požiūrį nesunkiai pakeisite pagal savo projekto ir įmonės poreikius.
Yra du architektūros vertinimo tipai.
Interjeras – dažniausiai tai darome projektams įmonės viduje. Bet kuris projektas gali prašyti architektūros įvertinimo dėl kelių priežasčių:
- Komanda mano, kad jų projektas yra tobulas, ir tai yra įtartina. Tokių atvejų turėjome ir dažnai tokiuose projektuose viskas toli gražu nėra idealu.
- Komanda nori išbandyti savo projektą ir jų sprendimus.
- Komanda žino, kad viskas yra blogai. Jie netgi gali išvardyti pagrindines problemas ir priežastis, bet nori išsamaus problemų sąrašo ir rekomendacijų, kaip tobulinti projektą.
Išorinis yra formalesnis procesas nei vidinis vertinimas. Klientas visada ateina tik vienu atveju, kai viskas blogai – labai blogai. Paprastai klientas supranta, kad yra globalių problemų, tačiau negali teisingai nustatyti priežasčių ir suskaidyti į komponentus.
Išorinio kliento architektūros įvertinimas yra sudėtingesnis atvejis. Procesas turėtų būti formalesnis. Projektai visada dideli ir seni. Jie turi daug problemų, klaidų ir iškreipto kodo. Per kelias savaites turėtų būti parengta atliktų darbų ataskaita, kurioje turi būti nurodytos pagrindinės problemos ir rekomendacijos tobulinti. Todėl, jei užsiimsime išoriniu projekto vertinimu, tai vidinis vertinimas bus gabalėlis. Panagrinėkime sunkiausią atvejį.
Įmonės projekto architektūros vertinimas
Įprastas vertinamas projektas yra didelis, senas, įmonės projektas, turintis daug problemų. Klientas ateina pas mus ir prašo sutvarkyti jo projektą. Tai kaip su ledkalniu, klientas mato tik savo problemų viršūnę ir neįsivaizduoja, kas yra po vandeniu (kodo gelmėse).
Problemos, dėl kurių klientas gali skųstis ir apie kurias gali žinoti:
- Veiklos problemos
- Naudojimo problemos
- Ilgalaikis dislokavimas
- Vieneto ir kitų testų trūkumas
Problemos, kurių klientas greičiausiai nežino, bet gali būti projekte:
- Saugumo problemos
- Dizaino problemos
- Neteisinga architektūra
- Algoritminės klaidos
- Netinkamos technologijos
- Techninė skola
- Neteisingas kūrimo procesas
Oficialus architektūros peržiūros procesas
Tai formalus procesas, kurio laikomės kaip įmonė, tačiau galite jį pritaikyti pagal savo įmonę ir projektą.
Prašymas iš kliento
Užsakovas prašo įvertinti esamo projekto architektūrą. Atsakingas asmuo iš mūsų pusės surenka pagrindinę informaciją apie projektą ir parenka reikiamus ekspertus. Priklausomai nuo projekto, tai gali būti skirtingi ekspertai.
Sprendimo architektas – pagrindinis už vertinimą ir koordinavimą atsakingas asmuo (dažnai ir vienintelis).
Surink konkrečius ekspertus – .Net, Java, Python ir kiti techniniai specialistai, priklausomai nuo projekto ir technologijų
Debesų ekspertai – tai gali būti Azure, GCP arba AWS debesų architektai.
Infrastruktūra – „DevOps“, sistemos administratorius ir kt.
Kiti ekspertai – pavyzdžiui, dideli duomenys, mašininis mokymasis, našumo inžinierius, saugos ekspertas, kokybės užtikrinimo vadovas.
Informacijos apie projektą rinkimas
Turėtumėte surinkti kuo daugiau informacijos apie projektą. Priklausomai nuo situacijos, galite naudoti skirtingus metodus:
- Anketos ir kiti bendravimo būdai paštu. Pats neveiksmingiausias būdas.
- Internetiniai susitikimai.
- Specialūs informacijos mainų įrankiai, tokie kaip: Google doc, Confluence, saugyklos ir kt.
- „Gyvai“ susitikimai vietoje. Veiksmingiausias ir brangiausias būdas.
Ką turėtumėte gauti iš kliento?
Pagrindinė informacija. Apie ką projektas? Jo paskirtis ir vertė. Pagrindiniai ateities tikslai ir planai. Verslo tikslai ir strategijos. Pagrindinės problemos ir norimi rezultatai.
Informacija apie projektą. Technologijų krūva, karkasai, programavimo kalbos. Diegimas vietoje arba debesyje. Jei projektas yra debesyje, kokios paslaugos naudojamos. Kokie architektūriniai ir dizaino modeliai buvo naudojami.
Nefunkciniai reikalavimai. Visi reikalavimai, susiję su sistemos veikimu, prieinamumu ir naudojimo paprastumu. Saugos reikalavimai ir kt.
Pagrindiniai naudojimo atvejai ir duomenų srautai.
Prieiga prie šaltinio kodo. Svarbiausia dalis! Jūs tikrai turėtumėte gauti prieigą prie saugyklų ir dokumentacijos, kaip sukurti projektą.
Prieiga prie infrastruktūros. Būtų malonu turėti prieigą prie scenos ar gamybos infrastruktūros dirbti su gyva sistema. Tai yra didelė sėkmė, jei klientas turi infrastruktūros ir veiklos stebėjimo įrankius. Apie šias priemones kalbėsime kitame skyriuje.
Įrašai. Jei klientas turi dokumentus, tai yra gera pradžia. Tai gali būti pasenusi, bet vis tiek gera pradžia. Niekada nepasitikėkite dokumentacija – išbandykite ją su klientu, realioje infrastruktūroje ir šaltinio kode.
Architektūros vertinimo procesas
Kaip galima apdoroti tokį didelį informacijos kiekį per tokį trumpą laiką? Visų pirma, sulyginkite darbą.
„DevOps“ turėtų pažvelgti į infrastruktūrą. Technika veda į kodą. Našumo inžinierius, norintis peržiūrėti našumo metriką. Duomenų bazės specialistas turėtų gilintis į duomenų struktūras.
Bet tai idealus atvejis, kai turite daug išteklių. Paprastai projektą vertina nuo vieno iki trijų žmonių. Jūs netgi galite atlikti sąmatą patys, o tai dažnai būna, jei turite reikiamų žinių ir patirties visose projekto srityse. Tokiu atveju reikia kiek įmanoma labiau automatizuoti visus procesus.
Deja, dokumentaciją turėsite perskaityti rankiniu būdu. Turėdami pakankamai patirties, galite greitai suprasti dokumentacijos kokybę. Kas yra tiesa, o kas aiškiai nesutampa su tikrove. Kartais dokumentuose galite pamatyti architektūrą, kuri niekada neveiks realiame gyvenime. Tai paskatins jus pagalvoti, kaip tai buvo padaryta iš tikrųjų projekte.
Naudingi įrankiai projektų vertinimui automatizuoti
Kodo įvertinimas yra paprastas pratimas. Galite naudoti statinius kodo analizatorius, kurie parodys dizaino, našumo ir saugos problemas. Štai keletas iš jų:
yra puikus įrankis architektui. Tai parodys jums bendrą vaizdą, modulių priklausomybes ir galimas pertvarkymo sritis. Kaip ir visi geri įrankiai, tai kainuoja gerus pinigus, tačiau galite pasinaudoti 30 dienų bandomąją versiją.
- senas geras įrankis. Statinio kodo analizės įrankis. Leidžia nustatyti blogą kodą, klaidas ir saugos problemas daugiau nei 20 programavimo kalbų.
Visi debesų tiekėjai turi infrastruktūros stebėjimo įrankius. Tai leis tinkamai įvertinti infrastruktūros efektyvumą sąnaudų ir našumo požiūriu. AWS tai yra . „Azure“ tai lengva .
Papildomas našumo stebėjimas ir registravimas padės rasti našumo problemas visais lygiais. Pradedant nuo duomenų bazės su neveiksmingomis užklausomis, backend ir baigiant priekine programa. Net jei klientas šių įrankių anksčiau neįdiegė, galite gana greitai juos integruoti į esamą sistemą, kad nustatytumėte našumo problemas.
Kaip visada, geri įrankiai yra verti. Galiu rekomenduoti porą mokamų priemonių. Žinoma, galite naudoti atvirąjį kodą, tačiau tai užtruks daugiau laiko. Ir tai turėtų būti daroma iš anksto, o ne architektūrinio vertinimo proceso metu.
– programos našumo vertinimo įrankis
– debesų sistemos stebėjimo paslauga
Yra daug įrankių saugumo testavimui. Šį kartą jums rekomenduosiu nemokamą sistemos nuskaitymo įrankį.
– įrankis, skirtas žiniatinklio programoms nuskaityti, kad jos atitiktų saugos standartus.
Sudėkime viską į vieną visumą.
Ataskaitos ruošimas
Pradėkite savo ataskaitą nuo duomenų, kuriuos surinkote iš kliento. Apibūdinkite projekto tikslus, suvaržymus, nefunkcinius reikalavimus. Po to turi būti paminėti visi įvesties duomenys: šaltinio kodas, dokumentacija, infrastruktūra.
Kitas žingsnis. Išvardykite visas problemas, kurias radote rankiniu būdu arba naudodami automatinius įrankius. Įdėkite dideles automatiškai sukurtas ataskaitas programų skilties pabaigoje. Turėtų būti trumpi ir glausti rastų problemų įrodymai.
Suteikite pirmenybę problemoms, randamoms klaidos, įspėjimo, informacijos skalėje. Galite pasirinkti savo skalę, tačiau tai yra visuotinai priimta.
Jūs, kaip tikras architektas, turite pateikti rekomendacijas, kaip išspręsti nustatytas problemas. Apibūdinkite patobulinimus ir verslo vertę, kurią gaus klientas. Kaip parodyti verslo vertę iš aptarėme anksčiau.
Paruoškite planą su nedidelėmis iteracijomis. Kiekvienoje iteracijoje turėtų būti nurodytas laikas, skirtas užbaigti, aprašymas, tobulinimui reikalingų išteklių kiekis, techninė vertė ir verslo vertė.
Atliekame architektūros vertinimą ir pateikiame klientui ataskaitą
Niekada tiesiog nesiųskite ataskaitos. Jis gali būti visai neperskaitytas arba gali būti neperskaitytas ir nesuprastas be tinkamo paaiškinimo. Trumpai tariant, gyvas bendravimas padeda pašalinti nesusipratimus tarp žmonių. Turėtumėte suplanuoti susitikimą su klientu ir pasikalbėti apie nustatytas problemas, sutelkiant dėmesį į svarbiausias. Verta atkreipti kliento dėmesį į problemas, kurių jis galbūt net nežino. Pavyzdžiui, saugumo problemos ir paaiškinkite, kaip jos gali paveikti verslą. Parodykite savo planą su patobulinimais ir aptarkite įvairias klientui tinkamesnes galimybes. Tai gali būti laikas, ištekliai, darbo kiekis.
Kaip susitikimo santrauką nusiųskite savo ataskaitą klientui.
užbaigiant
Architektūros vertinimas yra sudėtingas procesas. Norint tinkamai atlikti vertinimą, reikia turėti pakankamai patirties ir žinių.
Pateikti klientui jam ir jo verslui naudingus rezultatus galima vos per savaitę. Net jei tai darai vienas.
Remiantis mano patirtimi, daugelis patobulinimų buvo atsisiųsta viduryje, o kartais niekada neprasidėjo. Tie, kurie pasirinko sau aukso vidurį ir su minimaliomis darbo sąnaudomis atliko tik dalį verslui naudingiausių patobulinimų, gerokai pagerino savo gaminio kokybę. Tie, kurie nieko nedarė, po poros metų projektą galėjo visiškai uždaryti.
Jūsų tikslas – parodyti klientui maksimalius patobulinimus už mažiausią kainą.
Kiti straipsniai iš skyriaus galite skaityti laisvalaikiu.
Linkiu švaraus kodo ir gerų architektūrinių sprendimų.
Mūsų facebook grupė - .
Šaltinis: www.habr.com