Në fillim është gjithmonë e vështirë të kuptosh një projekt të madh dhe të vjetër. Arkitektura është një nga aktivitetet e një vlerësimi arkitekt. Zakonisht ju duhet të punoni me projekte të mëdha, të vjetra dhe rezultatet duhet të jepen brenda një jave.
Si të vlerësoni një projekt prej 100 mijë ose më shumë rreshtash kodi në një javë, ndërkohë që jepni ende rezultate që janë vërtet të dobishme për klientin.
Shumica e arkitektëve dhe drejtuesve teknikë kanë hasur në vlerësime të ngjashme të projektit. Ky mund të duket si një proces gjysmë formal ose si një shërbim i veçantë siç bëhet në kompaninë tonë, në një mënyrë ose në një tjetër shumica prej jush e keni trajtuar këtë.
Origjinali në anglisht për miqtë tuaj që nuk flasin rusisht është këtu: .
Qasja e kompanisë sonë
Unë do t'ju tregoj se si funksionon në kompaninë tonë dhe si veproj unë në situata të ngjashme, por ju lehtë mund ta ndryshoni këtë qasje sipas nevojave të projektit dhe kompanisë suaj.
Ekzistojnë dy lloje të vlerësimit të arkitekturës.
Brendshme – zakonisht e bëjmë 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ë projekte të tilla gjithçka është larg idealit.
- Ekipi dëshiron të testojë projektin dhe zgjidhjet e tyre.
- Skuadra e di se gjërat janë të këqija. Ata madje mund të rendisin problemet dhe shkaqet kryesore, por duan një listë të plotë të problemeve dhe rekomandime për përmirësimin e projektit.
E jashtme është një proces më formal sesa një vlerësim i brendshëm. Klienti vjen gjithmonë vetëm në një rast, kur gjithçka është keq - shumë keq. Zakonisht klienti e kupton që ka probleme globale, por nuk mund t'i identifikojë saktë shkaqet dhe t'i ndajë ato në komponentë.
Vlerësimi i një arkitekture për një klient të jashtëm është një rast më kompleks. Procesi duhet të jetë më formal. Projektet janë gjithmonë të mëdha dhe të vjetra. Ata kanë shumë probleme, gabime dhe kod të shtrembër. Një raport për punën e bërë duhet të jetë gati brenda maksimumit disa javësh, i cili duhet të përfshijë problemet kryesore dhe rekomandimet për përmirësim. Prandaj, nëse do të merremi me vlerësimin e jashtëm të projektit, atëherë vlerësimi i brendshëm do të jetë një copë tortë. Le të shqyrtojmë rastin më të vështirë.
Vlerësimi i arkitekturës së projektit të ndërmarrjes
Një projekt tipik për t'u vlerësuar është një projekt i madh, i vjetër, sipërmarrës me shumë probleme. Një klient vjen tek ne dhe na kërkon të rregullojmë projektin e tij. Është si me një ajsberg, klienti sheh vetëm majën e problemeve të tij dhe nuk e ka idenë se çfarë ka nën ujë (në thellësitë e kodit).
Problemet për të cilat klienti mund të ankohet dhe mund të jetë i vetëdijshëm:
- Çështjet e Performancës
- Probleme të përdorshmërisë
- Shpërndarja afatgjatë
- Mungesa e njësisë dhe testeve të tjera
Problemet për të cilat klienti ka shumë të ngjarë të mos jetë në dijeni, por ato mund të jenë të pranishme në projekt:
- Problemet e sigurisë
- Problemet e projektimit
- Arkitekturë e gabuar
- Gabimet algoritmike
- Teknologjitë e papërshtatshme
- Borxhi teknik
- Procesi i gabuar i zhvillimit
Procesi i rishikimit të arkitekturës formale
Ky është një proces formal që ne e ndjekim si kompani, por ju mund ta personalizoni në varësi të kompanisë dhe projektit tuaj.
Kërkesë nga një klient
Klienti kërkon të vlerësojë arkitekturën e projektit aktual. Personi përgjegjës nga ana jonë mbledh informacionin bazë për projektin dhe zgjedh ekspertët e nevojshëm. Në varësi të projektit, këta mund të jenë ekspertë të ndryshëm.
Arkitekt i zgjidhjeve – personi kryesor përgjegjës për vlerësimin dhe koordinimin (dhe shpesh i vetmi).
Mblidhni ekspertë të veçantë – .Net, Java, Python dhe specialistë të tjerë teknikë në varësi të projektit dhe teknologjive
Ekspertët e reve – këta mund të jenë arkitektë cloud Azure, GCP ose AWS.
Infrastrukturë – DevOps, administratori i sistemit, etj.
Ekspertë të tjerë – të tilla si të dhënat e mëdha, mësimi i makinerive, inxhinieri i performancës, eksperti i sigurisë, drejtuesi i QA.
Mbledhja e informacionit rreth projektit
Ju duhet të mbledhni sa më shumë informacion që të jetë e mundur për projektin. Mund të përdorni teknika të ndryshme në varësi të situatës:
- Pyetësorët dhe metodat e tjera të komunikimit me postë. Mënyra më joefektive.
- Takimet online.
- Mjete speciale për shkëmbimin e informacionit si: Google doc, Confluence, depo, etj.
- Takime "live" në vend. Mënyra më efektive dhe më e shtrenjtë.
Çfarë duhet të merrni nga klienti?
Informata themelore. Për çfarë bëhet fjalë projekti? Qëllimi dhe vlera e tij. Synimet dhe planet kryesore për të ardhmen. Qëllimet dhe strategjitë e biznesit. Problemet kryesore dhe rezultatet e dëshiruara.
Informacioni i projektit. Stack teknologjie, korniza, gjuhë programimi. Vendosja në premisë ose në renë kompjuterike. Nëse projekti është në re, cilat shërbime përdoren. Cilat modele arkitekturore dhe dizajni janë përdorur.
Kërkesat jofunksionale. Të gjitha kërkesat që lidhen me performancën, disponueshmërinë dhe lehtësinë e përdorimit të sistemit. Kërkesat e sigurisë, etj.
Rastet bazë të përdorimit dhe rrjedhat e të dhënave.
Qasja në kodin burimor. Pjesa më e rëndësishme! Duhet patjetër të keni akses në depot dhe dokumentacionin se si të ndërtoni projektin.
Qasja në infrastrukturë. Do të ishte mirë të kishim akses në skenën ose infrastrukturën e prodhimit për të punuar me sistemin live. Është një sukses i madh nëse klienti ka mjete për monitorimin e infrastrukturës dhe performancës. Ne do të flasim për këto mjete në pjesën tjetër.
Records. Nëse klienti ka dokumentacion, ky është një fillim i mirë. Mund të jetë e vjetëruar, por është ende një fillim i mirë. Asnjëherë mos i besoni dokumentacionit - testojeni atë me klientin, në infrastrukturën reale dhe në kodin burimor.
Procesi i Vlerësimit të Arkitekturës
Si mund të përpunohet një sasi kaq e madhe informacioni në një kohë kaq të shkurtër? Para së gjithash, paralelizoni punën.
DevOps duhet të shikojë infrastrukturën. Drejtimi teknik në kod. Inxhinier i performancës për të parë matjet e performancës. Një specialist i bazës së të dhënave duhet të gërmojë më thellë në strukturat e të dhënave.
Por ky është një rast ideal kur keni shumë burime. Në mënyrë tipike, një deri në tre persona vlerësojnë një projekt. Ju madje mund ta bëni vetë vlerësimin, gjë që ndodh shpesh nëse keni njohuritë dhe përvojën e duhur 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.
Fatkeqësisht, do t'ju duhet të lexoni dokumentacionin me dorë. Me përvojën e duhur, ju mund të kuptoni shpejt cilësinë e dokumentacionit. Çfarë është e vërtetë dhe çfarë nuk përputhet qartë me realitetin. Ndonjëherë mund të shihni arkitekturë në dokumentacion që nuk do të funksionojë kurrë në jetën reale. Kjo është një shkas që ju të mendoni se si është bërë në realitet në projekt.
Mjete të dobishme për të automatizuar vlerësimin e projektit
Vlerësimi i kodit është një ushtrim i thjeshtë. Ju mund të përdorni analizues të kodit statik që do t'ju tregojnë çështjet e dizajnit, performancës dhe sigurisë. Këtu janë disa prej tyre:
është një mjet i madh për një arkitekt. Ai do t'ju tregojë pamjen e madhe, varësitë midis moduleve dhe zonave të mundshme për rifaktorim. Si të gjitha mjetet e mira, kushton shumë para, por ju mund të përfitoni nga një version provë 30-ditore.
- një mjet i mirë i vjetër. Një mjet për analizën statike të kodit. Ju lejon të identifikoni kodin e keq, gabimet dhe problemet e sigurisë për më shumë se 20 gjuhë programimi.
Të gjithë ofruesit e cloud kanë mjete monitorimi të infrastrukturës. Kjo do t'ju lejojë të vlerësoni siç duhet efektivitetin e infrastrukturës suaj për sa i përket kostos dhe performancës. Për AWS kjo është . Është e lehtë për Azure .
Monitorimi dhe regjistrimi shtesë i performancës do të ndihmojnë në gjetjen e problemeve të performancës në të gjitha nivelet. Duke filluar nga një bazë të dhënash me pyetje joefektive, backend dhe duke përfunduar me frontend. Edhe nëse klienti nuk i ka instaluar më parë këto mjete, ju mund t'i integroni ato në sistemin ekzistues mjaft shpejt për të identifikuar problemet e performancës.
Si gjithmonë, mjetet e mira ia vlen. Unë mund të rekomandoj disa mjete me pagesë. Sigurisht që mund të përdorni burim të hapur, por do t'ju marrë më shumë kohë. Dhe kjo duhet të bëhet përpara, jo gjatë procesit të vlerësimit arkitektonik.
– një mjet për vlerësimin e performancës së aplikacionit
– shërbimi i monitorimit të sistemit cloud
Ka shumë mjete në dispozicion për testimin e sigurisë. Këtë herë unë do t'ju rekomandoj një mjet falas për skanimin e sistemit.
– një mjet për skanimin e aplikacioneve në ueb për pajtueshmërinë me standardet e sigurisë.
Le të bashkojmë gjithçka në një tërësi.
Përgatitja e një raporti
Filloni raportin tuaj me të dhënat që keni mbledhur nga klienti. Përshkruani qëllimet e projektit, kufizimet, kërkesat jofunksionale. Pas kësaj, duhet të përmenden të gjitha të dhënat hyrëse: kodi burimor, dokumentacioni, infrastruktura.
Hapi tjeter. Rendisni çdo problem që keni gjetur me dorë ose duke përdorur mjete të automatizuara. Vendosni raporte të mëdha të krijuara automatikisht në fund në seksionin e aplikacioneve. Duhet të ketë prova të shkurtra dhe të përmbledhura të problemeve të gjetura.
Jepini përparësi problemeve të gjetura në shkallën e gabimit, paralajmërimit, informacionit. Ju mund të zgjidhni shkallën tuaj, por kjo është ajo e pranuar përgjithësisht.
Si një arkitekt i vërtetë, është përgjegjësia juaj të jepni rekomandime për të korrigjuar problemet e gjetura. Përshkruani përmirësimet dhe vlerën e biznesit që klienti do të marrë. Si të tregoni vlerën e biznesit nga kemi diskutuar më herët.
Përgatitni një udhërrëfyes me përsëritje të vogla. Çdo përsëritje duhet të përmbajë kohë për të përfunduar, përshkrimin, sasinë e burimeve të nevojshme për përmirësim, vlerën teknike dhe vlerën e biznesit.
Ne përfundojmë vlerësimin e arkitekturës dhe i ofrojmë klientit një raport
Asnjëherë mos dërgoni vetëm një raport me postë. Mund të mos lexohet fare, ose mund të mos lexohet dhe kuptohet pa shpjegimin e duhur. Me pak fjalë, komunikimi i drejtpërdrejtë ndihmon në eliminimin e keqkuptimeve mes njerëzve. Ju duhet të planifikoni një takim me klientin dhe të flisni për problemet e gjetura, duke u fokusuar në ato më të rëndësishmet. Vlen të tërhiqet vëmendja e klientit për problemet që ai mund të mos jetë në dijeni. Të tilla si çështjet e sigurisë dhe shpjegoni se si ato mund të ndikojnë në biznes. Tregoni udhërrëfyesin tuaj me përmirësime dhe diskutoni opsione të ndryshme që janë më të përshtatshme për klientin. Kjo mund të jetë koha, burimet, sasia e punës.
Si një përmbledhje e takimit tuaj, dërgoni raportin tuaj te klienti.
Në përfundim
Vlerësimi i arkitekturës është një proces kompleks. Për të kryer vlerësimin si duhet duhet të keni përvojë dhe njohuri të mjaftueshme.
Është e mundur t'i siguroni klientit rezultate të dobishme për të dhe biznesin e tij në vetëm një javë. Edhe nëse e bëni vetëm.
Bazuar në përvojën time, shumë përmirësime u shkarkuan në mes dhe ndonjëherë nuk filluan kurrë. Ata që zgjodhën mesataren e artë për veten e tyre dhe bënë vetëm një pjesë të përmirësimeve që ishin më të dobishme për biznesin me kosto minimale të punës, përmirësonin ndjeshëm cilësinë e produktit të tyre. Ata që nuk bënë asgjë mund ta mbyllnin projektin fare pas disa vitesh.
Qëllimi juaj është t'i tregoni klientit përmirësime maksimale për çmimin minimal.
Artikuj të tjerë nga seksioni ju mund të lexoni në kohën tuaj të lirë.
Ju uroj kod të pastër dhe vendime të mira arkitekturore.
Grupi ynë në facebook - .
Burimi: www.habr.com