Hasieran beti da zaila proiektu handi eta zahar bat ulertzea. Arkitektura arkitektoen ebaluazioaren jardueretako bat da. Normalean proiektu handi eta zaharrekin lan egin behar da, eta emaitzak aste batean eman behar dira.
Nola ebaluatu aste batean 100 kode lerro edo gehiagoko proiektu bat bezeroarentzat benetan erabilgarriak diren emaitzak emanez.
Arkitekto eta arduradun tekniko gehienek antzeko proiektuen ebaluazioak topatu dituzte. Prozesu erdi-formal bat edo gure enpresan egiten den bezala zerbitzu bereizi bat izan daiteke, modu batera edo bestera jorratu duzue gehienok.
Errusieraz ez dakiten lagunentzako ingelesezko jatorrizkoa hemen dago: .
Gure enpresaren planteamendua
Gure enpresan nola funtzionatzen duen eta antzeko egoeretan nola jokatzen dudan esango dizut, baina ikuspegi hori erraz alda dezakezu zure proiektuaren eta enpresaren beharren arabera.
Bi arkitektura-ebaluazio mota daude.
Barrualdea β normalean enpresa barruko proiektuetarako egiten dugu. Edozein proiektuk arkitektura ebaluazioa eska dezake hainbat arrazoirengatik:
- Taldeak bere proiektua perfektua dela uste du eta hori susmagarria da. Halako kasuak izan ditugu, eta askotan halako proiektuetan dena ideala izatetik urrun dago.
- Taldeak bere proiektua eta irtenbideak probatu nahi ditu.
- Taldeak badaki gauzak gaizki daudela. Arazo eta kausa nagusiak ere zerrendatu ditzakete, baina arazoen eta proiektua hobetzeko gomendioen zerrenda osoa nahi dute.
Kanpokoa barne-ebaluazioa baino prozesu formalagoa da. Bezeroa kasu batean bakarrik etortzen da beti, dena txarra denean - oso txarra. Normalean bezeroak ulertzen du arazo globalak daudela, baina ezin ditu arrazoiak behar bezala identifikatu eta osagaietan banatu.
Kanpoko bezero baten arkitektura bat ebaluatzea kasu konplexuagoa da. Prozesua formalagoa izan beharko litzateke. Proiektuak beti handiak eta zaharrak dira. Arazo, akats eta kode oker asko dituzte. Egindako lanari buruzko txostena gehienez aste gutxiren buruan prest egon beharko litzateke, arazo nagusiak eta hobetzeko gomendioak jaso behar dituena. Hori dela eta, proiektuaren kanpo-ebaluazioari aurre egiten badiogu, orduan barne-ebaluazioa erraza izango da. Azter dezagun kasurik zailena.
Enpresa proiektuen arkitekturaren ebaluazioa
Ebaluatzeko ohiko proiektu bat arazo asko dituen enpresa-proiektu handi eta zahar bat da. Bezero bat etortzen zaigu eta bere proiektua konpontzeko eskatzen digu. Iceberg batekin bezala da, bezeroak bere arazoen punta baino ez du ikusten eta ez du ideiarik zer dagoen ur azpian (kodearen sakonean).
Bezeroak kexa ditzakeen eta jakitun izan daitezkeen arazoak:
- Errendimendu-arazoak
- Erabilgarritasun arazoak
- Epe luzerako hedapena
- Unitateko eta beste proba batzuen falta
Bezeroak ziurrenik ezagutzen ez dituen arazoak, baina proiektuan egon daitezke:
- Segurtasun arazoak
- Diseinu arazoak
- Arkitektura okerra
- Akats algoritmikoak
- Teknologia desegokiak
- Zor teknikoa
- Garapen prozesu okerra
Arkitektura berrikusteko prozesu formala
Enpresa gisa jarraitzen dugun prozesu formal bat da, baina pertsonalizatu dezakezu zure enpresa eta proiektuaren arabera.
Bezero baten eskaera
Bezeroak egungo proiektuaren arkitektura ebaluatzea eskatzen du. Gure alboko arduradunak proiektuari buruzko oinarrizko informazioa biltzen du eta beharrezko adituak aukeratzen ditu. Proiektuaren arabera, hauek aditu desberdinak izan daitezke.
Soluzio-arkitektoa β ebaluazioaren eta koordinazioaren arduradun nagusia (eta askotan bakarra).
Aditu espezifikoak pilatu β .Net, Java, Python eta beste teknikari batzuk, proiektuaren eta teknologien arabera
Hodeian adituak β hauek Azure, GCP edo AWS hodeiko arkitektoak izan daitezke.
Azpiegitura β DevOps, Sistemaren administratzailea, etab.
Beste aditu batzuk - hala nola, big data, machine learning, errendimendu ingeniaria, segurtasun aditua, QA liderra.
Proiektuari buruzko informazioa biltzea
Proiektuari buruzko ahalik eta informazio gehien bildu behar duzu. Hainbat teknika erabil ditzakezu egoeraren arabera:
- Galdetegiak eta posta bidezko beste komunikazio-metodo batzuk. Modurik eraginkorrena.
- Online bilerak.
- Informazioa trukatzeko tresna bereziak, hala nola: Google doc, Confluence, biltegiak, etab.
- "Zuzenean" bilerak gunean. Modurik eraginkorrena eta garestiena.
Zer lortu behar duzu bezeroarengandik?
Oinarrizko informazioa. Zertan datza proiektua? Bere helburua eta balioa. Etorkizunerako helburu eta plan nagusiak. Negozioaren helburuak eta estrategiak. Arazo nagusiak eta nahi diren emaitzak.
Proiektuaren informazioa. Teknologia pila, markoak, programazio lengoaiak. Inplementazioa lokalean edo hodeian. Proiektua hodeian badago, zer zerbitzu erabiltzen diren. Zein arkitektura eta diseinu eredu erabili ziren.
Baldintza ez-funtzionalak. Sistemaren errendimenduari, erabilgarritasunari eta erabiltzeko erraztasunari lotutako eskakizun guztiak. Segurtasun-baldintzak, etab.
Oinarrizko erabilera-kasuak eta datu-fluxuak.
Iturburu-koderako sarbidea. Zatirik garrantzitsuena! Zalantzarik gabe, proiektua eraikitzeko biltegietara eta dokumentaziorako sarbidea lortu beharko zenuke.
Azpiegituretarako sarbidea. Ondo legoke agertokira edo ekoizpen azpiegiturara sarbidea izatea zuzeneko sistemarekin lan egiteko. Arrakasta handia da bezeroak azpiegiturak eta errendimendua kontrolatzeko tresnak baditu. Tresna horiei buruz hurrengo atalean hitz egingo dugu.
Dokumentazioa. Bezeroak dokumentazioa badu, hasiera ona da. Baliteke zaharkitua egotea, baina hasiera ona da oraindik. Inoiz ez fidatu dokumentazioan - proba ezazu bezeroarekin, benetako azpiegituran eta iturburu-kodean.
Arkitektura Ebaluatzeko Prozesua
Nola prozesatu daiteke informazio kopuru handia hain denbora laburrean? Lehenik eta behin, lana paralelizatu.
DevOps-ek azpiegitura aztertu beharko luke. Teknologia liderra kodean sartu. Errendimendu-ingeniaria errendimendu-neurriak ikusteko. Datu-baseen espezialista batek datu-egituretan sakondu beharko luke.
Baina kasu aproposa da baliabide asko dituzunean. Normalean, batek edo hiru lagunek proiektu bat ebaluatzen dute. Zuk zeuk ere egin dezakezu aurrekontua, eta hori gertatu ohi da proiektuaren arlo guztietan ezagutza eta esperientzia egokiak badituzu. Kasu honetan, prozesu guztiak ahalik eta gehien automatizatu behar dituzu.
Tamalez, eskuz irakurri beharko duzu dokumentazioa. Esperientzia kopuru egokiarekin, dokumentazioaren kalitatea azkar uler dezakezu. Zer den egia eta zer argi eta garbi errealitatearekin bat ez datorrena. Batzuetan, bizitza errealean inoiz funtzionatuko ez duen dokumentazioan ikusiko duzu arkitektura. Hau abiarazlea da proiektuan errealitatean nola egin zen pentsatzeko.
Proiektuen ebaluazioa automatizatzeko tresna erabilgarriak
Kodearen ebaluazioa ariketa sinplea da. Diseinua, errendimendua eta segurtasun-arazoak erakutsiko dizkizuten kode-analisi estatikoak erabil ditzakezu. Hona hemen horietako batzuk:
tresna bikaina da arkitekto batentzat. Irudi orokorra, moduluen arteko menpekotasunak eta birfactorizaziorako balizko eremuak erakutsiko dizkizu. Tresna on guztiak bezala, diru ona kostatzen da, baina 30 eguneko proba bertsioa aprobetxa dezakezu.
- Tresna zahar ona. Kode estatikoa aztertzeko tresna. 20 programazio hizkuntza baino gehiagotan kode txarrak, akatsak eta segurtasun-arazoak identifikatzeko aukera ematen du.
Hodeiko hornitzaile guztiek azpiegiturak kontrolatzeko tresnak dituzte. Horri esker, zure azpiegituraren eraginkortasuna behar bezala ebaluatu ahal izango duzu kostu eta errendimendu aldetik. AWSrentzat hau da . Azurerentzat erraza da .
Errendimenduaren jarraipena eta erregistro gehigarriak maila guztietan errendimendu-arazoak aurkitzen lagunduko du. Kontsulta eraginkorrak dituen datu-base batetik abiatuta, backend-a eta frontend-arekin amaituz. Bezeroak tresna hauek instalatu ez baditu ere, lehendik dagoen sisteman nahiko azkar integra ditzakezu errendimendu-arazoak identifikatzeko.
Beti bezala, tresna onek merezi dute. Ordaindutako tresna pare bat gomenda ditzaket. Noski kode irekia erabil dezakezu, baina denbora gehiago beharko duzu. Eta hori aldez aurretik egin behar da, ez arkitektura ebaluatzeko prozesuan.
β Aplikazioen errendimendua ebaluatzeko tresna
β hodeiko sistemaren jarraipena egiteko zerbitzua
Segurtasun probak egiteko tresna asko daude eskuragarri. Oraingoan doako sistema eskaneatzeko tresna bat gomendatuko dizut.
β Web aplikazioak eskaneatzeko tresna, segurtasun-estandarrak betetzeko.
Bildu dezagun dena osotasunean.
Txostena prestatzea
Hasi zure txostena bezeroarengandik bildu dituzun datuekin. Deskribatu proiektuaren helburuak, mugak, baldintza ez-funtzionalak. Horren ostean, sarrerako datu guztiak aipatu behar dira: iturburu kodea, dokumentazioa, azpiegitura.
Hurrengo urratsa. Zerrendatu eskuz edo tresna automatizatuak erabiliz aurkitu dituzun arazoak. Jarri automatikoki sortutako txosten handiak amaieran aplikazioen atalean. Aurkitutako arazoen froga labur eta laburrak izan behar dira.
Lehenetsi errorean, abisuan, informazio eskalan aurkitutako arazoei. Zure eskala aukeratu dezakezu, baina hau da orokorrean onartutakoa.
Egiazko arkitekto gisa, aurkitutako arazoak zuzentzeko gomendioak ematea zure ardura da. Deskribatu bezeroak jasoko dituen hobekuntzak eta negozio-balioa. Nola erakutsi negozioaren balioa lehen eztabaidatu genuen.
Prestatu ibilbide-orri bat iterazio txikiekin. Iterazio bakoitzak osatzeko denbora, deskribapena, hobetzeko beharrezkoak diren baliabideen kopurua, balio teknikoa eta negozioaren balioa izan behar ditu.
Arkitektura-ebaluazioa osatzen dugu eta bezeroari txosten bat ematen diogu
Inoiz ez bidali txosten bat. Baliteke inola ere ez irakurtzea, edo behar bezala azaldu gabe irakurtzea eta ulertzea. Laburbilduz, zuzeneko komunikazioak pertsonen arteko gaizki-ulertuak kentzen laguntzen du. Bezeroarekin bilera bat antolatu eta aurkitutako arazoei buruz hitz egin beharko zenuke, esanguratsuenetan zentratuz. Merezi du bezeroaren arreta erakartzea agian kontziente ez diren arazoetara. Esaterako, segurtasun arazoak eta negozioan nola eragin dezaketen azaldu. Erakutsi zure bide-orria hobekuntzekin eta eztabaidatu bezeroarentzat egokiagoak diren aukera desberdinak. Hau izan daiteke denbora, baliabideak, lan kopurua.
Zure bileraren laburpen gisa, bidali zure txostena bezeroari.
Ondorioz
Arkitekturaren ebaluazioa prozesu konplexua da. Ebaluazioa behar bezala egiteko esperientzia eta ezagutza nahikoa izan behar da.
Posible da bezeroari berarentzat eta bere negozioarentzat erabilgarriak diren emaitzak eskaintzea astebetean. Nahiz eta bakarrik egin.
Nire esperientzian oinarrituta, hobekuntza asko deskargatu ziren erdian, eta batzuetan ez ziren inoiz hasi. Beraiek urrezko bitartekoa aukeratu zutenek eta negoziorako erabilgarriak ziren hobekuntzen zati bat baino ez zutenek eskulan-kostu minimoekin hobetu zuten beren produktuaren kalitatea. Ezer egin ez zutenek proiektua guztiz itxi ahal izan zuten pare bat urteren buruan.
Zure helburua bezeroari hobekuntzarik handienak erakustea da gutxieneko prezioagatik.
Ataleko beste artikulu batzuk aisialdian irakur dezakezu.
Kode garbia eta erabaki arkitektoniko onak opa dizkizut.
Gure facebook taldea - .
Iturria: www.habr.com