Në fillim gjithmonë është e vështirë të kuptosh një projekt të madh dhe të vjetër. Vlerësimi i arkitekturës është një nga aktivitetet e arkitektit. Zakonisht duhet të punosh me projekte të mëdha dhe të vjetra, dhe rezultatet duhet të dorëzohen brenda një jave.
Si të vlerësosh një projekt me mbi 100,000 rreshta kodi brenda një jave dhe në të njëjtën kohë të ofrosh rezultate të vërteta të dobishme për klientin.
Shumica e arkitektëve dhe liderëve teknologjikë janë përballur me vlerësime të tilla të projekteve. Kjo mund të duket si një proces gjysmëformal ose si një shërbim i veçantë siç bëhet në kompaninë tonë; në çdo rast, shumica e jush kanë pasur të bëjnë me këtë.
Origjinali në anglisht për miqtë tuaj që nuk flasin rusisht është këtu: .
Qasja në kompaninë tonë
Do t'ju tregoj se si funksionon kjo në kompaninë tonë dhe si veproj në situata të ngjashme, por ju mund ta ndryshoni këtë qasje sipas nevojave të projektit dhe kompanisë suaj.
Ka dy lloje të vlerësimit të arkitekturës.
Brendshëm – ne zakonisht e bëjmë këtë për projekte brenda kompanisë. Çdo projekt mund të kërkojë një vlerësim të arkitekturës për disa arsye:
- Ekipi mendon se projekti i tyre është i përsosur dhe kjo është e dyshimtë. Kemi pasur raste të tilla dhe shpesh në këto projekte, gjërat nuk janë aspak të përsosura.
- Ekipi dëshiron të kontrollojë projektin dhe zgjidhjet e tij.
- Ekipi e di se gjërat janë keq. Ata madje mund të rendisin problemet kryesore dhe arsyet, por dëshirojnë të marrin një listë të plotë të problemeve dhe rekomandimeve për të përmirësuar projektin.
E jashtme është një proces më formal se sa vlerësimi i brendshëm. Klienti vjen gjithmonë vetëm në një rast, kur gjërat janë keq – shumë keq. Zakonisht, klienti e kupton se ka probleme të mëdha, por nuk mund të përcaktojë saktë arsyet dhe t’i ndajë ato në komponentë.
Vlerësimi i arkitekturës për një klient të jashtëm është një rast më i komplikuar. Procesi duhet të jetë më formal. Projektet gjithmonë janë të mëdha dhe të vjetra. Në to ka shumë probleme, defekte dhe kod të keq. Raporti i punës së kryer duhet të jetë gati brenda disa javësh maksimumi, ku duhet të përfshihen problemet kryesore dhe rekomandimet për përmirësim. Prandaj, nëse merremi me vlerësimin e jashtëm të projektit, atëherë ai i brendshmi do të jetë vetëm disa detyra të vogla. Le të shqyrtojmë rastin më të komplikuar.
Vlerësimi i arkitekturës së projektit enterprise
Një projekt tipik për vlerësim është një projekt i madh, i vjetër, enterprise me shumë probleme. Klienti vjen tek ne dhe na kërkon të rregullojmë projektin e tij. Është si me ajsbergun, klienti sheh vetëm majën e problemeve të tij dhe nuk ka idenë për atë që është nën ujë (në thellësi të kodit).
Problemet për të cilat klienti mund të ankohët dhe mund të dijë për to:
- Probleme me performancën
- Probleme me përdorshmërinë e aplikacionit (Usability)
- Zbatim i gjatë
- Mungesa e testeve unitare dhe testeve të tjera
Problemet për të cilat klienti zakonisht nuk ka njohuri, por ato mund të jenë të pranishme në projekt:
- Probleme me sigurinë
- Problemet e dizajnimit
- Arkitekturë e gabuar
- Gabime algoritmike
- Teknologji të papërshtatshme
- Borxhi teknik
- Proces zhvillimi i gabuar
Proces formal i vlerësimit të arkitekturës
Ky është një proces formal, të cilin ne e ndjekim në kompani, por ju mund ta përshtatni atë sipas nevojave të kompanisë dhe projektit tuaj.
Kërkesa nga klienti
Klienti kërkon të vlerësojë arkitekturën e projektit aktual. Njeriu përgjegjës nga ana jonë po mbledh informacionin e nevojshëm rreth projektit dhe po seleksionon ekspertët e nevojshëm. Në varësi të projektit, këta mund të jenë ekspertë të ndryshëm.
Arkitekt Zgjidhjesh – personi kryesor përgjegjës për vlerësimin dhe koordinimin (dhe shpesh herë i vetmi).
Ekspertë të specifikuar stack – .Net, Java, Python dhe specialistë të tjerë teknikë në varësi të projektit dhe teknologjive.
Ekspertë në Cloud – këta mund të jenë arkitektë në Azure, GCP ose AWS.
Infrastruktura – DevOps, Administrator sistemesh, etj.
Ekspertë të tjerë – si big data, machine learning, inxhinierë të performancës, ekspertë të sigurisë, liderë QA.
Mbledhja e informacionit rreth projektit
Ju duhet të mbledhni sa më shumë informacion rreth projektit. Mund të përdorni teknika të ndryshme në varësi të situatës:
- Pyetësorë dhe mënyra të tjera komunikimi përmes postës elektronike. Mënyra më pak efektive.
- Takime online.
- Mjete të veçanta për shkëmbimin e informacionit të tilla si: Google doc, Confluence, repozitorë, etj.
- Takime 'live' në vend. Mënyra më efikase dhe më e shtrenjtë.
Çfarë duhet të marrim nga klienti?
Informacioni bazë. Çfarë është projekti. Qëllimi dhe vlera e tij. Objektivat kryesore dhe planet për të ardhmen. Objektivat e biznesit dhe strategjitë. Problemet kryesore dhe rezultati i dëshiruar.
Informacion rreth projektit. Staka teknologjike, framework-et, gjuhët e programimit. Depojim on-premise ose në re. Nëse projekti është në re, cilat shërbime përdoren. Cilat janë modelet arkitekturore dhe dizajnore që janë aplikuar.
Kërkesat jo funksionale. Të gjitha kërkesat që lidhen me performancën, disponueshmërinë, lehtësinë e përdorimit të sistemit. Kërkesat për siguri etj.
Rasti bazë të përdorimit dhe rrjedha të dhënash.
Q access to source code. Pjesa më e rëndësishme! Ju duhet patjetër të merrni akses në depo dhe dokumentacionin se si të ndërtoni projektin.
Q access to infrastructure. Do të ishte mirë të merrni akses në infrastrukturën stage ose production, për të punuar me sistemin "live". Është një fat i madh nëse klienti ka mjete për monitorimin e infrastrukturës dhe performancës. Për këto mjete do të flasim në seksionin që vjen.
Dokumentacioni. Nëse klienti ka dokumentacion, kjo është një fillim i mirë. Mund të jetë i vjetruar, por është përsëri një fillim i mirë. Kurrë mos e besoni dokumentacionin – verifikoni atë me klientin, në infrastrukturën reale dhe në kodin burimor.
Procesi i vlerësimit të arkitekturës
Si mund ta përballojmë një sasi kaq të madhe informacioni brenda një periudhe kaq të shkurtër? Para së gjithash, ndani punën.
DevOps duhet të shikojë në infrastrukturë. Kryetari i ekipit në kod. Inxhinieri i performancës duhet të shikojë metrikat e performancës. Specialistit të të dhënave i rekomandohet të thellohet në strukturat e të dhënave.
Por ky është rasti ideal, kur keni shumë burime. Zakonisht, vlerësimin e projektit e kryejnë nga një deri në tre persona. Ju madje mund ta bëni vlerësimin vetë, çka shpesh ndodh, nëse keni njohuri dhe përvojë të mjaftueshme në të gjitha fushat e projektit. Në këtë rast, ju duhet të automatizoni të gjitha proceset, sa më shumë që të jetë e mundur.
Fatke, do t'ju duhet të lexoni dokumentacionin manualisht. Nëse keni përvojën e duhur, do të jeni në gjendje ta kuptoni shpejt cilësinë e dokumentacionit. Aty do të gjeni çfarë është e vërtetë dhe çfarë nuk përputhet me realitetin. Ndonjëherë, mund të takoni një arkitekturë në dokumentacion që në realitet nuk do të funksionojë kurrë. Ky është një tregues për t'u menduar, si është bërë në realitet në projekt.
Vegla të dobishme për automatizimin e vlerësimit të projektit
Vlerësimi i kodit është një ushtrim i thjeshtë. Mund të përdorni analizues statik të kodit, të cilat do të tregojnë problemet në dizajn, performancë dhe siguri. Ja disa prej tyre:
– është një vegël e shkëlqyer për arkitektin. Do t'ju tregojë pamjen e përgjithshme, varësitë midis moduleve dhe fushat potenciale për refaktorizim. Si të gjitha veglat e mira, kushton një sasi të mirë parash, por gjithashtu mund të provoni versionin provues për 30 ditë.
– vegël e njohur. Vegël për analizën statike të kodit. Lejon identifikimin e kodit të dobët, gabimeve, dhe problemeve me sigurinë për më shumë se 20 gjuhë programimi.
Të gjithë ofruesit e shërbimeve në cloud kanë mjete për monitorimin e infrastrukturës. Kjo do t'ju ndihmojë të vlerësoni saktësisht efikasitetin e infrastrukturës nga pikëpamja e kostos dhe performancës. Për AWS, kjo është . Për Azure, kjo është thjesht .
Monitorimi shtesë i performancës dhe regjistrimi do të ndihmojnë në gjetjen e problemeve me performancën në të gjitha nivelet. Duke filluar nga baza e të dhënave me kërkesa jo efektive, backend dhe duke përfunduar me frontend. Edhe nëse klienti nuk i ka instaluar këto mjete më parë, mund të integroni me shpejtësi ato në sistemin ekzistues për të identifikuar problemet me performancën.
Si gjithmonë, mjetet e mira kushtojnë. Mund të rekomandoj disa mjete të paguara. Sigurisht, mund të përdorni open-source, por do t'ju duhen më shumë kohë për këtë. Dhe kjo duhet bërë paraprakisht, jo gjatë procesit të vlerësimit të arkitekturës.
– mjet për vlerësimin e performancës së aplikacioneve
– shërbim cloud për monitorimin e sistemeve
Ka për sigurinë ekzistojnë shumë mjete. Këtë herë do t'ju rekomandoj një mjet falas për skanimin e sistemit.
– një mjet për skanimin e aplikacioneve web në përputhje me standardet e sigurisë.
Mblidhen të gjitha në një vend.
Përgatit raportin
Filloni raportin tuaj me të dhënat e mbledhura nga klienti. Përshkruani qëllimet e projektit, kufizimet, kërkesat jo-funksionale. Pas kësaj, vlen të përmenden të gjithë inputet si kodi burimor, dokumentacioni, infrastruktura.
Hapi tjetër. Identifikoni të gjitha problemet që keni gjetur manualisht ose me mjete automatike. Raportet e mëdha të gjeneruara automatikisht vendosini në fund në seksionin e annexe-ve. Këtu duhet të jenë prova të shkurtra dhe të qarta të problemeve të gjetura.
Prioritizoni problemet e gjetura sipas shkallës error, warning, info. Mund të zgjidhni shkallën tuaj, por kjo është e pranuar gjerësisht.
Si një arkitekt i vërtetë, jeni të obliguar të jepni rekomandime për zgjidhjen e problemeve të gjetura. Përshkruani përmirësimet dhe vlerën për biznesin që do të marrë klienti. Si të tregoni vlerën për biznesin nga që diskutonim më parë.
Përgatitni një roadmap me iteracione të vogla. Çdo iteracion duhet të përmbajë kohën për përfundim, përshkrimin, numrin e burimeve të nevojshme për përmirësim, vlerën teknike dhe atë për biznesin.
Përfundojmë vlerësimin e arkitekturës dhe i ofrojmë klientit një raport.
Kurrë mos e dërgoni raportin vetëm me e-mail. Ai mund të mos lexohet fare ose të kuptohet gabimisht pa një shpjegim të duhur. Në përmbledhje – komunikimi i drejtpërdrejtë ndihmon për të eliminuar keqkuptimet midis njerëzve. Duhet t'i caktoni një takim klientit dhe të flisni për problemet e gjetura duke theksuar ato më të rëndësishmet. Duhet të tërhiqni vëmendjen e klientit mbi problemet, për të cilat ai mund të mos ketë qenë në dijeni. Siç janë problemet me sigurinë dhe t'i shpjegoni se si ato mund të ndikojnë në biznesin e tij. Tregoni roadmap-in tuaj me përmirësime dhe diskutoni opsione të ndryshme, më të përshtatshme për klientin. Kjo mund të përfshijë kohën, burimet, volumet e punës.
Pasi të përfundoni takimin, dërgoni klientit raportin tuaj.
Në përfundim
Vlerësimi i arkitekturës është një proces i komplikuar. Për ta realizuar atë siç duhet, ju nevojitet mjaft përvojë dhe njohuri.
Në të vërtetë, është e mundur të ofrosh klientit rezultate të dobishme për të dhe biznesin e tij brenda një javë. Edhe nëse e bën këtë vetëm.
Nga përvoja ime, shumë përmirësime u ndërprenë në mes, dhe ndonjëherë nuk filluan kurrë. Ata që zgjodhën një mesatare dhe bënë vetëm disa përmirësime që ishin maksimalisht të dobishme për biznesin me minimumin e mundit, përmirësuan ndjeshëm cilësinë e produktit të tyre. Ata që nuk bënë asgjë pas disa vitesh mund të mbyllnin projektin.
Qëllimi juaj është të tregoni klientit përmirësime maksimale për një çmim minimal.
Artikuj të tjerë nga kategoria mund të lexohen në kohë të lirë.
Ju uroj kod të pastër dhe zgjidhje të mira arkitekturore.
Grupi ynë në Facebook është - .
Burimi: habr.com
