All'inizio è sempre difficile orientarsi in un progetto grande e vecchio. La valutazione dell'architettura è una delle attività dell'architetto. Di solito si lavora su grandi progetti obsoleti, e i risultati devono essere forniti entro una settimana.
Come valutare un progetto di 100k e più righe di codice in una settimana, fornendo allo stesso tempo risultati realmente utili per il cliente.
La maggior parte degli architetti e dei team leader ha affrontato stime di questo tipo. Questo può apparire come un processo semi-formale o come un servizio separato come nel nostro caso; in un modo o nell'altro, la maggior parte di voi ha avuto a che fare con questo.
L'originale in inglese per i vostri amici non russofoni si trova qui: .
Il nostro approccio
Vi spiegherò come funziona nella nostra azienda e come mi comporto in situazioni simili, ma potete facilmente adattare questo approccio alle esigenze del vostro progetto e della vostra azienda.
Ci sono due tipi di valutazione dell'architettura.
Interna – di solito la facciamo per progetti all'interno dell'azienda. Qualsiasi progetto può richiedere una valutazione dell'architettura per diversi motivi:
- Il team pensa che il proprio progetto sia perfetto e ciò è sospetto. Abbiamo avuto casi simili e spesso in questi progetti non è affatto così.
- Il team desidera controllare il proprio progetto e le proprie soluzioni.
- Il team sa che ci sono dei problemi. Possono anche elencare i principali problemi e le cause, ma vogliono avere un elenco completo di problemi e raccomandazioni per migliorare il progetto.
Esterno – è un processo più formale rispetto alla valutazione interna. Il cliente si presenta solo in un caso, quando le cose vanno male – molto male. Di solito il cliente comprende che ci sono problemi globali, ma non può identificare correttamente le cause e scomporle.
La valutazione dell'architettura per un cliente esterno è un caso più complesso. Il processo deve essere più formale. I progetti sono sempre grandi e obsoleti. Presentano molti problemi, bug e codice non ottimale. Il report sul lavoro svolto deve essere pronto entro poche settimane al massimo, indicando i principali problemi e raccomandazioni per il miglioramento. Pertanto, se riusciamo a gestire la valutazione esterna del progetto, quella interna sarà un gioco da ragazzi. Consideriamo il caso più difficile.
Valutazione dell'architettura di un progetto enterprise
Un progetto tipico da valutare è un grande progetto enterprise, vecchio e con molte problematiche. Il cliente si rivolge a noi e chiede di riparare il suo progetto. È come un iceberg, il cliente vede solo la punta dei suoi problemi e non si rende conto di ciò che si trova sotto l'acqua (in profondità nel codice).
Problemi di cui il cliente può lamentarsi e di cui può essere a conoscenza:
- Problemi di performance
- Problemi di usabilità dell'applicazione
- Deploy prolungato
- Mancanza di test unitari e di altri tipi di test
Problemi di cui il cliente probabilmente non è a conoscenza, ma che possono essere presenti nel progetto:
- Problemi di sicurezza
- Problemi di progettazione
- Architettura errata
- Errori algoritmici
- Tecnologie inadeguate
- Debito tecnico
- Processo di sviluppo errato
Processo formale di valutazione dell'architettura
Questo è un processo formale che seguiamo in azienda, ma puoi adattarlo alle tue esigenze a seconda della tua azienda e del progetto.
Richiesta da parte del cliente
Il cliente chiede di valutare l'architettura del progetto attuale. La persona responsabile da parte nostra raccoglie informazioni di base sul progetto e seleziona gli esperti necessari. A seconda del progetto, possono essere esperti diversi.
Solution Architect – la persona principale responsabile della valutazione e del coordinamento (e spesso l'unica).
Esperti specifici per stack – .Net, Java, Python e altri specialisti tecnici a seconda del progetto e delle tecnologie
Esperti cloud – possono essere architetti cloud di Azure, GCP o AWS.
Infrastruttura – DevOps, amministratore di sistema, ecc.
Altri esperti – come big data, machine learning, performance engineer, esperto di sicurezza, QA lead.
Raccolta di informazioni sul progetto
Dovresti raccogliere quante più informazioni possibile sul progetto. Puoi utilizzare diverse tecniche a seconda della situazione:
- Questionari e altri modi di comunicare via email. Il modo meno efficace.
- Incontri online.
- Strumenti speciali per la condivisione delle informazioni come: Google doc, Confluence, repository, ecc.
- Incontri 'di persona'. Il modo più efficace e costoso.
Cosa bisogna ottenere dal cliente?
Informazioni di base. Di cosa tratta il progetto. Il suo obiettivo e valore. Obiettivi principali e piani futuri. Obiettivi aziendali e strategie. Problemi principali e risultati desiderati.
Informazioni sul progetto. Stack tecnologico, framework, linguaggi di programmazione. Deployment on-premise o cloud. Se il progetto è in cloud, quali servizi vengono utilizzati? Quali pattern architettonici e di design sono stati applicati.
Requisiti non funzionali. Tutti i requisiti relativi a prestazioni, disponibilità, usabilità del sistema. Requisiti di sicurezza, ecc.
Use case di base e flussi di dati.
Accesso al codice sorgente. La parte più importante! Dovete assolutamente ottenere accesso ai depositi e alla documentazione su come costruire il progetto.
Accesso all'infrastruttura. Sarebbe utile avere accesso all'infrastruttura di staging o produzione per lavorare con un sistema "live". È una grande fortuna se il cliente dispone di strumenti di monitoraggio dell'infrastruttura e delle prestazioni. Parleremo di questi strumenti nella sezione successiva.
Documentazione. Se il cliente ha della documentazione, è un buon inizio. Potrebbe essere obsoleta, ma è comunque un buon inizio. Non fidatevi mai della documentazione – verificate con il cliente, su infrastruttura reale e nel codice sorgente.
Processo di valutazione dell'architettura
Come gestire un così grande volume di informazioni in così poco tempo? Prima di tutto, parallelizzate il lavoro.
Il DevOps dovrebbe esaminare l'infrastruttura. Il team leader dovrebbe guardare il codice. L'ingegnere delle prestazioni dovrebbe analizzare le metriche sulle prestazioni. Lo specialista di database dovrebbe approfondire le strutture dei dati.
Ma questo è il caso ideale, quando si hanno molte risorse. Di solito, la valutazione del progetto viene effettuata da una a tre persone. Potete anche effettuare la valutazione da soli, il che accade spesso, se avete le conoscenze e l'esperienza adeguate in tutti gli ambiti del progetto. In tal caso, dovete automatizzare tutti i processi, per quanto possibile.
Sfortunatamente, dovrete leggere la documentazione manualmente. Con l'esperienza adeguata, sarete in grado di capire rapidamente la qualità della documentazione. Cosa è vero e cosa non corrisponde alla realtà. A volte, potreste incontrare un'architettura nella documentazione che non funzionerà mai nella vita reale. Questo è un segnale per vederci chiaro su come sono stati realizzati i progetti nella realtà.
Strumenti utili per l'automazione della valutazione del progetto
La valutazione del codice è un esercizio semplice. Puoi utilizzare analizzatori statici del codice che evidenziano problemi di design, performance e sicurezza. Ecco alcuni di essi:
è uno strumento eccellente per l'architetto. Ti mostrerà l'immagine complessiva, le dipendenze tra i moduli e le aree potenziali per il refactoring. Come tutti gli strumenti validi, ha un costo significativo, ma puoi usufruire di una versione trial di 30 giorni.
è il vecchio e buon strumento. Uno strumento per l'analisi statica del codice. Permette di identificare codice scadente, bug, problemi di sicurezza per oltre 20 linguaggi di programmazione.
Tutti i fornitori di cloud hanno strumenti per il monitoraggio dell'infrastruttura. Questo ti consentirà di valutare correttamente l'efficacia dell'infrastruttura in termini di costi e prestazioni. Per AWS, questo è . Per Azure è semplicemente .
Un monitoraggio aggiuntivo delle performance e della registrazione aiuterà a individuare problemi di performance a tutti i livelli. Partendo dal database con query inefficienti, al backend, fino al frontend. Anche se il cliente non ha installato questi strumenti in precedenza, puoi integrarli rapidamente nel sistema esistente per identificare problemi di performance.
Come sempre, gli strumenti validi hanno un costo. Posso consigliarti un paio di strumenti a pagamento. Certo, puoi utilizzare strumenti open-source, ma ti richiederanno più tempo. E questo dovrebbe essere fatto in anticipo, non durante la valutazione dell'architettura.
è uno strumento per la valutazione delle performance delle applicazioni
è un servizio cloud di monitoraggio dei sistemi
Esistono numerosi strumenti per il testing della sicurezza. Questa volta ti consiglio uno strumento gratuito per la scansione del sistema.
è uno strumento per la scansione delle applicazioni web per verificarne la conformità agli standard di sicurezza.
Mettiamo tutto insieme.
Prepariamo il rapporto
Inizia il tuo rapporto con i dati raccolti dal cliente. Descrivi gli obiettivi del progetto, le limitazioni e i requisiti non funzionali. Dopo ciò, dovresti menzionare tutti i dati di input, codice sorgente, documentazione, infrastruttura.
Passo successivo. Indica tutti i problemi che hai trovato manualmente o con strumenti automatizzati. Inserisci i grandi rapporti generati automaticamente alla fine nella sezione appendice. Qui dovrebbero essere prove brevi e concise dei problemi trovati.
Prioritizza i problemi trovati su una scala di errore, avviso, informazione. Puoi scegliere la tua scala, ma questa è comunemente accettata.
Come un vero architetto, sei tenuto a fornire raccomandazioni per risolvere i problemi riscontrati. Descrivi i miglioramenti e il valore per l'azienda che il cliente otterrà. Come dimostrare il valore per l'azienda di discusso in precedenza.
Prepara un roadmap con piccole iterazioni. Ogni iterazione dovrebbe contenere il tempo di esecuzione, la descrizione, il numero di risorse necessarie per il miglioramento, il valore tecnico e il valore per l'azienda.
Completiamo la valutazione dell'architettura e forniamo al cliente la relazione
Non inviare mai semplicemente la relazione via email. Potrebbero non leggerla affatto o leggerla e non capirla senza una spiegazione adeguata. In breve, la comunicazione diretta aiuta a risolvere i malintesi tra le persone. Dovresti organizzare un incontro con il cliente e parlare dei problemi riscontrati, ponendo l'accento su quelli più significativi. È importante far notare al cliente problemi di cui potrebbe non essere nemmeno a conoscenza, come problemi di sicurezza, e spiegare come possano influire sul business. Mostra il tuo roadmap con i miglioramenti e discuti le diverse opzioni, più adatte al cliente. Questo può riguardare tempo, risorse e carico di lavoro.
Come sintesi del tuo incontro, invia al cliente il tuo rapporto.
In conclusione
La valutazione dell'architettura è un processo complesso. Per condurre una valutazione adeguata, è necessario avere sufficiente esperienza e conoscenze.
È davvero possibile fornire al cliente risultati utili per lui e per la sua attività in soli sette giorni. Anche se lo fai da solo.
Secondo la mia esperienza, molti miglioramenti sono stati interrotti a metà, e a volte non sono nemmeno stati avviati. Coloro che hanno scelto il giusto equilibrio e hanno implementato solo alcune delle migliorie più utili per l'azienda con il minor spreco di risorse, hanno significativamente migliorato la qualità del loro prodotto. Chi non ha intrapreso alcuna azione, dopo un paio d'anni, potrebbe dover chiudere il progetto.
Il tuo obiettivo è mostrare al cliente i massimi miglioramenti al prezzo minimo.
Altri articoli della sezione puoi leggere nei tuoi momenti di svago.
Ti auguro codice pulito e buone soluzioni architettoniche.
Il nostro gruppo Facebook è — .
Fonte: habr.com
