Në fillim gjithmonë është e vështirë të krijosh një kuptim të qartë nga një projekt i madh dhe i vjetër. Vlerësimi i arkitekturës është një nga aktivitete e arkitektit. Zakonisht na duhet të punojmë me projekte të mëdha e të vjetra, dhe rezultatet duhet t'i dorëzojmë brenda një jave.
Si të vlerësojmë një projekt me 100,000 rreshta kodi dhe më shumë brenda një jave, duke ofruar njëkohësisht rezultate të vërteta të dobishme për klientin.
Shumica e arkitektëve dhe liderëve teknikë janë përballur me vlerësime të ngjashme projektesh. Kjo mund të duket si një proces gjysmëformal ose si një shërbim i veçantë siç është bërë në kompaninë tonë, por si ndodhi, shumica e jush kanë pasur përvojë me këtë.
Origjinali në anglisht për miqtë tuaj që nuk flasin rusisht ndodhet këtu: .
Qasja në kompaninë tonë
Do t'ju tregoj se si funksionon kjo në kompaninë tonë dhe si veproj unë në raste të tilla, por ju mund të ndryshoni lehtësisht këtë qasje sipas nevojave të projektit dhe kompanisë suaj.
Ka dy lloje të vlerësimit të arkitekturës.
I 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:
- Ekipa mendon se projekti i tyre është perfekt dhe kjo është e dyshimtë. Kemi pasur raste të tilla dhe shpesh në këto projekte gjithçka nuk është aspak perfekte.
- Ekipa dëshiron të kontrollojë projektin e saj dhe zgjidhjet e saj.
- Ekipa e di se gjithçka është 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 përmirësimin e projektit.
I jashtëm – është një proces më formalisht, sesa vlerësimi i brendshëm. Klienti vjen gjithmonë vetëm në një rast, kur gjithçka është keq – shumë keq. Zakonisht klienti kupton se ka probleme globale, por nuk mund të përcaktojë saktësisht arsyet dhe t'i ndajë ato në elemente të veçanta.
Vlerësimi i arkitekturës për një klient të jashtëm është një rast më kompleks. Processi duhet të jetë më formal. Projektet gjithmonë janë të mëdha dhe të vjetra. Në to ka shumë probleme, gabime dhe kod të deformuar. Raporti i punës së kryer duhet të jetë i gatshëm brenda disa javësh maksimum, ku duhet të shqyrtohen problemet kryesore dhe rekomandimet për përmirësim. Prandaj, nëse ne e kuptojmë vlerësimin e jashtëm të projektit, atëherë vlerësimi i brendshëm do të përbëjë një copë të vogël. Le të shqyrtojmë rastin më të vështirë.
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 kërkon të rregullojmë projektin e tij. Kjo është si me një ajsberg, klienti sheh vetëm majën e problemeve të tij dhe nuk e kupton se çfarë ndodhet nën ujë (në thellësinë e kodit).
Problemet, për të cilat klienti mund të ankohet dhe mund t'i dijë:
- Problemet me performancën
- Problemet me përdorimin e aplikacionit (Usability)
- Deployment i gjatë
- Mungesa e testeve unitare dhe testeve të tjera
Problemet, për të cilat klienti ndoshta nuk është në dijeni, por ato mund të jenë të pranishme në projekt:
- Problemet me sigurinë
- Problemet e dizajnit
- Arkitektura e gabuar
- Gabime algoritmike
- Teknologjitë e papërshtatshme
- Borxhi teknik
- Procesi i gabuar i zhvillimit
Një proces formal vlerësimi të arkitekturës
Ky është një proces formal, të cilin ne e ndjekim në kompaninë tonë, 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. Personi përgjegjës nga ana jonë mbledh informacionin bazë mbi projektin dhe përzgjedh ekspertët e nevojshëm. Në varësi të projektit, këta mund të jenë ekspertë të ndryshëm.
Arkitektët e Zgjidhjeve – personi kryesor përgjegjës për vlerësimin dhe koordinimin (dhe shpesh herë unik).
Ekspertët specifikë të Stack – .Net, Java, Python, dhe specialistë të tjerë teknikë në varësi të projektit dhe teknologjive
Ekspertët e Cloud – mund të jenë arkitektë cloud të Azure, GCP ose AWS.
Infrastruktura – DevOps, Administrator sistemi, etj.
Ekspertë të tjerë – si big data, machine learning, inxhinierë të performancës, ekspertë të sigurisë, lider të QA.
Mblidhni informacionin mbi projektin
Duhet të mbledhni sa më shumë informacion rreth projektit. Mund të përdorni teknika të ndryshme në varësi të situatës:
- Anketat dhe mënyra të tjera komunikimi me email. Mënyra më pak efektive.
- Takimet online.
- Instrumente speciale për shkëmbyer informacion si: Google doc, Confluence, repozitorët, etj.
- Takimet 'live' në vend. Mënyra më efektive dhe më e shtrenjta.
Çfarë duhet të marrim nga klienti?
Informacioni bazë. Për çfarë është projekti. Qëllimi dhe vlera e tij. Qëllimet kryesore dhe planet për të ardhmen. Qëllimet dhe strategjitë biznesore. Problemet kryesore dhe rezultati i dëshiruar.
Informacioni mbi projektin. Tekstuarin teknologjik, kornizë, gjuhë programuese. Deployim on-premise ose në re. Nëse projekti është në re, cilat shërbime përdoren. Cilat modele arkitekturore dhe dizajni janë përdorur.
Kërkesat jo funksionale. Të gjitha kërkesat që lidhen me performancën, disponueshmërinë, përdorshmërinë e sistemit. Kërkesat e sigurisë etj.
Rastet bazë të përdorimit dhe rrjedhat e të dhënave.
Qアクセスのソースコーツト. Pjesa më e rëndësishme! Sigurohuni të merrni akses në depozitë dhe dokumentacionin se si të ndërtoni projektin.
Qアクセスのインフラ. 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. Do të flasim për këto mjete në seksionin pasues.
Dokumentacioni. Nëse klienti ka dokumentacion, kjo është një fillim i mirë. Ajo mund të jetë e vjetruar, por është ende një fillim i mirë. Mos besoni kurrë dokumentacionin - kontrolloni atë me klientin, në infrastrukturën reale dhe në kodin burim.
Procesi i vlerësimit të arkitekturës
Si të trajtoni një sasi kaq të madhe informacioni brenda një kohe kaq të shkurtër? Para së gjithash, bëni punën paralel.
DevOps duhet të shikojë në infrastrukturë. Lideri teknik në kod. Inxhinieri i performancës të kontrollojë metrikat e performancës. Specialistët për bazat e të dhënave duhet të kërkojnë më në thellësi strukturat e të dhënave.
Por ky është rasti ideal, kur keni shumë burime. Zakonisht, vlerësimi i projektit bëhet nga një deri në tre persona. Ju madje mund të bëni vlerësimin vetë, që shpesh ndodh, nëse keni njohuri dhe përvojë të mjaftueshme në të gjitha fushat e projektit. Në këtë rast, ju nevojitet të automatizoni të gjitha proceset sa më shumë të jetë e mundur.
Për fat të keq, do t'ju duhet të lexoni dokumentacionin manualisht. Nëse keni përvojën e duhur, do të jeni në gjendje të kuptoni shpejt cilësinë e dokumentacionit. Çfarë është e vërtetë dhe çfarë nuk përputhet qartë me realitetin. Ndonjëherë mund të takoni një arkitekturë në dokumentacion që asnjëherë nuk do të funksionojë në jetën reale. Kjo është një shkak për t'u menduar, si është realizuar në të vërtetë në projekt.
Mjete të dobishme për automatizimin e vlerësimit të projektit
Vlerësimi i kodit është një ushtrim i thjeshtë. Mund të përdorni analizatorë statikë të kodit që do të tregojnë problemet e dizajnit, performancës dhe sigurisë. Këtu janë disa prej tyre:
është një mjet i shkëlqyer për arkitektin. Ai do t'ju tregojë pamjen e përgjithshme, varësinë midis moduleve dhe zonat e mundshme për refaktorizim. Siç i përket të gjitha mjeteve të mira, kushton para të mira, megjithatë mund të shfrytëzoni një version provë 30-ditor.
është mjeti i njohur. Një mjet për analizën statike të kodit. Lejon të identifikoni kodin e dobët, defektet, problemet e sigurisë për më shumë se 20 gjuhë programimi.
Të gjithë ofruesit e cloud kanë mjete për monitorimin e infrastrukturës. Kjo do t'ju ndihmojë të vlerësoni saktë efikasitetin e infrastrukturës nga pikëpamja e kostos dhe performancës. Për AWS, kjo është . Për Azure, ajo thjesht është .
Monitorimi i mëtejshëm i performancës dhe logjistikës do të ndihmojë në gjetjen e problemeve të performancës në të gjithë nivelet. Duke filluar nga baza e të dhënave me kërkesa joefikase, backend dhe deri në frontend. Edhe nëse klienti nuk ka instaluar këto mjete më parë, mund të integroni ato mjaft shpejt në sistemin ekzistues për të identifikuar problemet e performancës.
Si gjithmonë, mjetet e mira kushtojnë. Mund të rekomandoj disa mjete me pagesë. Sigurisht, mund të përdorni ato open-source, por do t'ju duhen më shumë kohë për këtë. Dhe kjo duhet bërë paraprakisht, e jo gjatë vlerësimit të arkitekturës.
është një mjet për vlerësimin e performancës së aplikacioneve
është një shërbim cloud për monitorimin e sistemeve
Për testimin e sigurisë ka shumë mjete. Këtë herë do t'ju rekomandoj një mjet falas për skanimin e sistemit.
është një mjet për skanimin e aplikacioneve web në përputhje me standardet e sigurisë.
Mblidhni gjithçka në një tërësi.
Përgatitni 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, përmendni të gjitha të dhënat hyrëse: kodi burimor, dokumentacionin, infrastrukturën.
Hapi tjetër. Shkruani të gjitha problemet që keni gjetur manualisht ose me ndihmën e mjeteve automatike. Raportet e mëdha të gjeneruara automatikisht duhet të vendosen në fund në seksionin e aplikacioneve. Këtu duhet të jenë prova të shkurtra dhe përmbledhëse 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ë, ju jeni të detyruar të ofroni rekomandime për zgjidhjen e problemeve të gjetura. Përshkruani përmirësimet dhe vlerën për biznesin që do të merrte klienti. Si të tregohet vlera për biznesin nga që diskutuam më parë.
Përgatitni një roadmap me iteracione të vogla. Çdo iteracion duhet të përmbajë kohën e realizimit, përshkrimin, numrin e burimeve të nevojshme për përmirësim, vlerën teknike dhe vlerën për biznesin.
Kemi përfunduar vlerësimin e arkitekturës dhe i ofrojmë klientit një raport.
Kurrë mos e dërgoni thjesht raportin me email. Ai mund të mos lexohet fare ose të lexohet dhe të mos kuptohet pa një shpjegim të duhur. Në përmbledhje - komunikimi në jetën reale ndihmon në eliminimin e keqkuptimeve midis njerëzve. Ju duhet të caktoni një takim me klientin dhe të flisni për problemet e gjetura, duke u përqendruar në ato më të rëndësishmet. Duhet t'i drejtoni vëmendjen klientit për problemet për të cilat ai mund të mos ketë qenë në dijeni. Të tilla si problemet me sigurinë dhe të shpjegoni se si ato mund të ndikojnë në biznes. Tregoni roadmap tuaj me përmirësime dhe diskutoni opsione të ndryshme që i përshtaten më mirë klientit. Kjo mund të jetë koha, burimet, volume punësh.
Në përfundim të takimit tuaj, dërgoni klientit raportin tuaj.
Në përfundim
Vlerësimi i arkitekturës është një proces kompleks. Për ta kryer atë siç duhet, ju nevojitet mjaft përvojë dhe njohuri.
Është e mundur të ofroni klientit rezultate të dobishme për të dhe biznesin e tij brenda një jave. Edhe nëse e bëni këtë vetëm.
Nga përvoja ime, shumica e përmirësimeve janë bllokuar në gjysmë të rrugës, dhe ndonjëherë kurrë nuk kanë filluar. Ata që zgjodhën të ndjekin një mesatare të zbatonin vetëm disa përmirësime maksimale që ishin të dobishme për biznesin me minimumin e përpjekjeve, ndjeshëm përmirësuan cilësinë e produktit të tyre. Ata që nuk bënë asgjë, pas disa viteve mund të kishin mbyllur projektin.
Qëllimi juaj është të tregoni klientit përmirësime maksimale për një çmim minimal.
Artikuj të tjerë nga kjo kategori mund të lexoni në kohën tuaj të lirë.
Ju uroj një kod të pastër dhe zgjidhje të mira arkitekturore.
Grupi ynë në Facebook — .
Burimi: habr.com
