À u principiu hè sempre difficiule di capiscenu un prughjettu grande è vechju. L'architettura hè una di l'attività di una valutazione di l'architettu. Di solitu avete da travaglià cù grandi prughjetti vechji, è i risultati devenu esse mandati in una settimana.
Cumu valutà un prughjettu di 100k o più linee di codice in una settimana mentre furnisce risultati chì sò veramente utili à u cliente.
A maiò parte di l'architetti è i capi tecnichi anu scontru valutazioni di prughjettu simili. Questu pò esse cum'è un prucessu semi-formale o cum'è un serviziu separatu cum'è hè fattu in a nostra cumpagnia, in una manera o l'altra a maiò parte di voi avete trattatu questu.
L'uriginale in inglese per i vostri amichi chì ùn parlanu micca russu hè quì: .
L'approcciu di a nostra cumpagnia
Vi dicu cumu si travaglia in a nostra cumpagnia è cumu agisce in situazioni simili, ma pudete facilmente cambià stu approcciu secondu i bisogni di u vostru prughjettu è cumpagnia.
Ci hè dui tipi di valutazione di l'architettura.
Internu - Di solitu facemu per prughjetti in a cumpagnia. Ogni prughjettu pò dumandà una valutazione di l'architettura per parechje motivi:
- A squadra pensa chì u so prughjettu hè perfettu è questu hè suspettu. Avemu avutu tali casi, è spessu in tali prughjetti tuttu hè luntanu da l'ideale.
- A squadra vole pruvà u so prughjettu è e so suluzioni.
- A squadra sapi chì e cose sò male. Puderanu ancu liste i prublemi principali è e cause, ma volenu una lista completa di prublemi è cunsiglii per migliurà u prugettu.
Esternu hè un prucessu più formale chè una valutazione interna. U cliente vene sempre solu in un casu, quandu tuttu hè male - assai male. Di solitu u cliente capisce chì ci sò prublemi glubale, ma ùn pò micca identificà currettamente i causi è sparghje in cumpunenti.
Evaluà una architettura per un cliente esternu hè un casu più cumplessu. U prucessu deve esse più formale. I prughjetti sò sempre grandi è vechji. Anu assai prublemi, bugs è codice crooked. Un rapportu nantu à u travagliu fattu deve esse prontu in uni pochi di simane massimu, chì deve include i prublemi principali è cunsiglii per migliurà. Dunque, si tratta di a valutazione esterna di u prugettu, allora a valutazione interna serà un pezzu di torta. Fighjemu u casu più difficiule.
Valutazione di l'architettura di u prughjettu di l'impresa
Un prughjettu tipicu per evaluà hè un grande, anticu, prughjettu di l'impresa cù assai prublemi. Un cliente vene à noi è ci dumanda di riparà u so prughjettu. Hè cum'è cù un iceberg, u cliente vede solu a punta di i so prublemi è ùn hà micca idea di ciò chì hè sottu à l'acqua (in a prufundità di u codice).
Prublemi chì u cliente pò lagnà è pò esse cunnisciutu:
- Problemi di rendiment
- Problemi di usabilità
- Impiegazione à longu andà
- Mancanza di unità è altre teste
I prublemi chì u cliente più prubabilmente ùn hè micca cunnisciutu, ma ponu esse prisenti in u prugettu:
- Prublemi di sicurità
- Problemi di disignu
- Architettura sbagliata
- Errori algoritmichi
- Tecnulugie inappropriate
- Debitu tecnicu
- Prucessu di sviluppu sbagliatu
Prucessu formale di rivisione di l'architettura
Questu hè un prucessu formale chì seguitamu cum'è una cumpagnia, ma pudete persunalizà secondu a vostra cumpagnia è u prughjettu.
Richiesta da un cliente
U cliente dumanda à evaluà l'architettura di u prughjettu attuale. A persona rispunsevuli da a nostra parte raccoglie l'infurmazioni basi nantu à u prugettu è selezziunate l'esperti necessarii. Sicondu u prughjettu, questi ponu esse diverse esperti.
Architettu di Soluzione - u principale rispunsevuli di a valutazione è a coordinazione (è spessu l'unicu).
Stack esperti specifichi – .Net, Java, Python, è altri specialisti tecnichi sicondu u prughjettu è e tecnulugia
Esperti in nuvola - questi ponu esse architetti di nuvola Azure, GCP o AWS.
Infrastrutture - DevOps, amministratore di sistema, etc.
Altri esperti - cum'è big data, machine learning, ingegnere di rendiment, espertu di sicurezza, QA lead.
Raccolta infurmazione nantu à u prugettu
Duvete cullà quant'è più infurmazione pussibule nantu à u prugettu. Pudete aduprà diverse tecniche secondu a situazione:
- Questionarii è altri metudi di cumunicazione per mail. U modu più inefficace.
- Reunione in linea.
- Strumenti speciali per u scambiu d'infurmazioni cum'è: Google doc, Confluence, repository, etc.
- Reunione "in diretta" in situ. U modu più efficace è più caru.
Chì duvete ottene da u cliente?
Informazioni basiche. Chì ghjè u prughjettu ? U so scopu è u so valore. Principali scopi è piani per u futuru. Obiettivi è strategie di cummerciale. I prublemi principali è i risultati desiderati.
L'infurmazione di u prughjettu. Pila di tecnulugia, frameworks, linguaggi di prugrammazione. Implementazione on-premise o cloud. Se u prughjettu hè in u nuvulu, chì servizii sò utilizati. Chì mudelli di architettura è di design sò stati utilizati.
Requisiti non-funziunali. Tutti i requisiti riguardanti u rendiment, a dispunibilità è a facilità d'utilizazione di u sistema. Requisiti di sicurità, etc.
Casi d'usu basi è flussi di dati.
Accessu à u codice fonte. A parte più impurtante! Avete bisognu di avè accessu à i repositori è a documentazione nantu à cumu custruisce u prugettu.
Accessu à l'infrastruttura. Saria bellu avè accessu à u palcuscenicu o l'infrastruttura di produzzione per travaglià cù u sistema live. Hè un grande successu se u cliente hà strumenti per monitorà l'infrastruttura è u rendiment. Parleremu di sti strumenti in a sezione dopu.
Documentazione. Se u cliente hà documentazione questu hè un bonu principiu. Pò esse anticu, ma hè sempre un bonu principiu. Ùn fidate mai a documentazione - pruvate cù u cliente, nantu à l'infrastruttura reale è in u codice fonte.
Prucessu di valutazione di l'architettura
Cumu si pò processà una quantità cusì grande di informazioni in un pocu tempu? Prima di tuttu, parallelizà u travagliu.
DevOps deve guardà l'infrastruttura. Tech lead in u codice. Ingegnere di rendiment per vede e metriche di rendiment. Un specialista di basa di dati duverebbe scavà più profondamente in strutture di dati.
Ma questu hè un casu ideale quandu avete assai risorse. Di genere, da una à trè persone valutanu un prughjettu. Pudete ancu cunduce a stima sè stessu, chì hè spessu u casu si avete a cunniscenza è l'experientia propiu in tutti i spazii di u prugettu. In questu casu, avete bisognu di automatizà tutti i prucessi quant'è pussibule.
Sfurtunatamente, vi tuccherà à leghje a ducumentazione manually. Cù u dirittu quantità di sperienza, pudete capisce rapidamente a qualità di a documentazione. Ciò chì hè veru è ciò chì chjaramente ùn coincide micca cù a realità. A volte pudete vede l'architettura in a documentazione chì ùn hà mai travagliatu in a vita reale. Questu hè un trigger per voi per pensà à cumu hè stata fatta in realità in u prugettu.
Strumenti utili per automatizà a valutazione di u prugettu
A valutazione di u codice hè un esercitu simplice. Pudete aduprà analizatori di codice staticu chì vi mostraranu prublemi di cuncepimentu, prestazione è sicurezza. Eccu alcuni di elli:
hè un grande strumentu per un architettu. Vi mostrarà a grande stampa, dipendenze trà i moduli è e aree potenziali per a refactoring. Cum'è tutti i boni strumenti, custa boni soldi, ma pudete prufittà di una versione di prova di 30 ghjorni.
- un bonu vechju strumentu. Un strumentu per l'analisi di codice staticu. Permette di identificà codice male, bug, è prublemi di sicurità per più di 20 lingue di prugrammazione.
Tutti i fornitori di nuvola anu strumenti di monitoraghju di l'infrastruttura. Questu vi permetterà di valutà currettamente l'efficacità di a vostra infrastruttura in termini di costu è prestazione. Per AWS questu hè . Hè faciule per Azure .
U monitoraghju supplementu di u rendiment è u logu aiuterà à truvà prublemi di rendiment à tutti i livelli. Partendu da una basa di dati cù dumande inefficace, u backend è finiscinu cù u frontend. Ancu s'è u cliente ùn hà micca stallatu questi strumenti prima, pudete integrà in u sistema esistente abbastanza rapidamente per identificà prublemi di rendiment.
Cum'è sempre, i boni strumenti valenu a pena. Puderaghju cunsiglià un paru di strumenti pagati. Di sicuru, pudete aduprà open-source, ma vi purterà più tempu. È questu deve esse fattu prima, micca durante u prucessu di valutazione architettonica.
- un strumentu per valutà u rendiment di l'applicazione
- serviziu di surviglianza di u sistema di nuvola
Ci hè parechje strumenti dispunibili per a prova di sicurezza. Sta volta vi ricumanderaghju un strumentu di scanning di sistema gratuitu.
- un strumentu per scansà l'applicazioni web per u rispettu di i normi di sicurità.
Mettimu tuttu inseme in un sanu.
Preparazione di un rapportu
Accuminciate u vostru rapportu cù e dati chì avete cullucatu da u cliente. Descrive i scopi di u prugettu, i limiti, i requisiti non-funzionali. Dopu à quessa, tutti i dati di input deve esse mintuatu: codice fonte, documentazione, infrastruttura.
U prossimu passu. Lista tutti i prublemi chì avete trovu manualmente o utilizendu strumenti automatizati. Pone grandi rapporti generati automaticamente à a fine in a sezione di l'applicazioni. Ci deve esse evidenza breve è succinta di i prublemi truvati.
Priorità i prublemi truvati nantu à l'errore, avvistu, scala d'infurmazioni. Pudete sceglie a vostra propria scala, ma questu hè quellu generalmente accettatu.
Cum'è un veru architettu, hè a vostra rispunsabilità di furnisce cunsiglii per correggerà i prublemi truvati. Descrivite e migliure è u valore cummerciale chì u cliente riceverà. Cumu dimustrà u valore di l'affari da avemu discututu prima.
Preparate una roadmap cù picculi iterazioni. Ogni iterazione duverebbe cuntene u tempu per compie, a descrizzione, a quantità di risorse necessarie per a migliurà, u valore tecnicu è u valore cummerciale.
Cumpitemu a valutazione di l'architettura è furnisce u cliente cun un rapportu
Ùn mai solu mail un rapportu. Pò esse micca lettu à tuttu, o ùn pò micca esse lettu è capitu senza spiegazione curretta. In breve, a cumunicazione in diretta aiuta à eliminà i malintesi trà e persone. Duvete pianificà una reunione cù u cliente è parlà di i prublemi truvati, cuncintrali nantu à i più significativi. Hè vale a pena attirà l'attenzione di u cliente à i prublemi chì ùn puderebbe ancu esse cuscenti. Cum'è e prublemi di sicurezza è spiegà cumu puderanu impactà l'affari. Mostra u vostru roadmap cù migliorie è discute diverse opzioni chì sò più adattati per u cliente. Questu pò esse tempu, risorse, quantità di travagliu.
Cum'è un riassuntu di a vostra riunione, mandate u vostru rapportu à u cliente.
In cunclusioni
A valutazione di l'architettura hè un prucessu cumplessu. Per fà a valutazione bè, avete bisognu di avè abbastanza sperienza è cunniscenza.
Hè pussibule furnisce u cliente risultati utili per ellu è a so attività in solu una settimana. Ancu s'è vo fate solu.
Basatu nantu à a mo sperienza, parechji migliuramentu sò stati scaricati in u mezu, è qualchì volta ùn anu mai cuminciatu. Quelli chì anu sceltu u mediu d'oru per elli stessi è anu fattu solu una parte di e migliuramentu chì eranu più utili per l'affari cù costi di travagliu minimu hà migliuratu significativamente a qualità di u so pruduttu. Quelli chì ùn anu fattu nunda puderanu chjude u prugettu in tuttu dopu un paru d'anni.
U vostru scopu hè di dimustrà u cliente megliu megliurà per u prezzu minimu.
Altri articuli di a rùbbrica pudete leghje à u vostru piacè.
Vogliu u codice pulito è e boni decisioni architettoniche.
U nostru gruppu Facebook - .
Source: www.habr.com