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
