All'inizio è sempre difficile orientarsi in un progetto grande e complesso. L'architecture assessment è una delle attività dell'architetto. Di solito si lavora su progetti grandi e datati e i risultati devono essere presentati entro una settimana.
Come valutare un progetto di oltre 100.000 righe di codice in una settimana fornendo risultati realmente utili per il cliente.
La maggior parte degli architetti e dei leader tecnici si è trovata ad affrontare valutazioni di questo tipo. Questo processo può sembrare informale o essere fornito come un servizio separato, come avviene nella nostra azienda; in ogni caso, molti di voi hanno avuto a che fare con esso.
L'originale in inglese per i vostri amici non di lingua russa è disponibile qui: .
Approccio della nostra azienda
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 architecture assessment.
Interno – di solito lo realizziamo per progetti interni all'azienda. Qualsiasi progetto può richiedere una valutazione dell'architettura per diversi motivi:
- Il team pensa che il loro progetto sia perfetto e questo è sospetto. Abbiamo avuto casi simili e spesso in tali progetti tutto è ben lontano dall'essere ideale.
- Il team vuole verificare il proprio progetto e le proprie soluzioni.
- Il team sa che le cose non vanno bene. Possono persino elencare i principali problemi e le cause, ma desiderano ricevere un elenco completo dei problemi e raccomandazioni per migliorare il progetto.
Esterno – è un processo più formale rispetto a una valutazione interna. Il cliente si rivolge a noi solo quando la situazione è grave – molto grave. Di solito, il cliente ha la consapevolezza di avere problemi globali, ma non riesce a identificare correttamente le cause e suddividerle.
La valutazione dell'architettura per un cliente esterno è un caso più complesso. Il processo deve essere più formale. I progetti sono sempre grandi e datati. Presentano molti problemi, bug e codice mal scritto. Il report del lavoro svolto deve essere pronto entro poche settimane al massimo, includendo i principali problemi e raccomandazioni per miglioramenti. Pertanto, se riusciremo a gestire la valutazione esterna del progetto, quella interna sarà una questione da poco. Analizziamo il caso più complesso.
Valutazione dell'architettura di un progetto enterprise
Un progetto tipico da valutare è un grande, vecchio progetto enterprise con numerosi problemi. Il cliente si rivolge a noi chiedendo di riparare il suo progetto. È come un iceberg, il cliente vede solo la cima dei suoi problemi e non si accorge di ciò che si trova sott'acqua (in profondità nel codice).
Problemi di cui il cliente può lamentarsi e di cui può essere a conoscenza:
- Problemi di prestazioni
- Problemi di usabilità dell'applicazione
- Deployment prolungato
- Mancanza di test unitari e altri 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
È un processo formale che seguiamo in azienda, ma puoi adattarlo alle tue esigenze in base alla tua azienda e al progetto.
Richiesta da parte del cliente
Il cliente richiede una valutazione dell'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 diversi esperti.
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, amministratori di sistema, ecc.
Altri esperti – come big data, machine learning, performance engineer, esperto di sicurezza, QA lead.
Raccolta delle informazioni sul progetto
Dovresti raccogliere quante più informazioni possibili sul progetto. Puoi utilizzare diverse tecniche a seconda della situazione:
- Questionari e altri metodi di comunicazione via email. Il metodo meno efficace.
- Incontri online.
- Strumenti speciali per lo scambio di informazioni come: Google doc, Confluence, repository, ecc.
- Incontri 'di persona'. Il metodo più efficace e costoso.
Cosa bisogna ottenere dal cliente?
Informazioni di base. Di cosa tratta il progetto. Il suo obiettivo e il suo valore. Obiettivi principali e piani futuri. Obiettivi e strategie aziendali. Problemi principali e risultati desiderati.
Informazioni sul progetto. Stack tecnologico, framework, linguaggi di programmazione. Deploy on-premise o cloud. Se il progetto è nel cloud, quali servizi vengono utilizzati. Quali pattern architetturali e di design sono stati applicati.
Requisiti non funzionali. Tutti i requisiti relativi a prestazioni, disponibilità, facilità d'uso del sistema. Requisiti di sicurezza, ecc.
Casi d'uso di base e flussi di dati.
Accesso al codice sorgente. La parte più importante! È fondamentale avere accesso ai repository e alla documentazione su come assemblare il progetto.
Accesso all'infrastruttura. Sarebbe utile avere accesso all'infrastruttura stage o di produzione per lavorare con un sistema 'vivo'. È un grande vantaggio se il cliente dispone di strumenti per il monitoraggio dell'infrastruttura e delle prestazioni. Di questi strumenti parleremo nella prossima sezione.
Documentazione. Se il cliente ha della documentazione, è un buon inizio. Potrebbe essere obsoleta, ma rimane pur sempre un buon punto di partenza. Non fidatevi mai della documentazione: verificate con il cliente, sulla vera infrastruttura e nel codice sorgente.
Processo di valutazione dell'architettura
Come si fa a gestire una così grande quantità di informazioni in così poco tempo? Prima di tutto, parallelizzate il lavoro.
Il DevOps deve esaminare l'infrastruttura. Il team leader deve concentrarsi sul codice. L'ingegnere delle prestazioni deve analizzare le metriche di performance. Il database specialist 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. Potreste anche effettuare la valutazione da soli, il che succede spesso se avete le conoscenze e l'esperienza necessarie in tutte le aree del progetto. In tal caso, dovrete automatizzare tutti i processi il più possibile.
Sfortunatamente, dovrai leggere la documentazione manualmente. Con l'esperienza adeguata, riuscirai a capire rapidamente la qualità della documentazione. Cosa è vero e cosa chiaramente non corrisponde alla realtà. A volte puoi incontrare un'architettura nella documentazione che non funzionerà mai nella vita reale. Questo è un segnale per riflettere su come si realizza effettivamente nel progetto.
Strumenti utili per l'automazione della valutazione del progetto
La valutazione del codice è un esercizio semplice. Puoi utilizzare analizzatori statici di codice, che evidenziano problemi di design, prestazioni e sicurezza. Ecco alcuni di essi:
è un ottimo strumento per l'architetto. Ti mostrerà l'immagine complessiva, la dipendenza tra i moduli e le potenziali aree da rifattorizzare. Come tutti i buoni strumenti, ha un costo adeguato, ma puoi approfittare di una versione di prova di 30 giorni.
è un vecchio buon strumento. Strumento per l'analisi statica del codice. Permette di individuare codice scadente, bug e problemi di sicurezza per oltre 20 linguaggi di programmazione.
Tutti i fornitori di cloud offrono strumenti per il monitoraggio dell'infrastruttura. Questo ti permetterà di valutare correttamente l'efficacia dell'infrastruttura in termini di costo e prestazioni. Per AWS, si tratta di . Per Azure, è semplicemente .
Ulteriore monitoraggio delle prestazioni e logging aiuterà a identificare i problemi di performance a tutti i livelli. Dalla base di dati con query inefficaci, al backend, fino al frontend. Anche se il cliente non ha installato questi strumenti in precedenza, è possibile integrarli rapidamente nel sistema esistente per individuare i problemi di performance.
Come sempre, i buoni strumenti hanno un costo. Posso consigliare un paio di strumenti a pagamento. Certamente, puoi utilizzare soluzioni open-source, ma richiederanno più tempo. E dovresti farlo in anticipo, non durante la valutazione dell'architettura.
– strumento per la valutazione delle prestazioni delle applicazioni
– servizio cloud di monitoraggio dei sistemi
Ci sono molti strumenti per testare la sicurezza. Questa volta ti consiglio uno strumento gratuito per la scansione dei sistemi.
– uno strumento per la scansione delle applicazioni web rispetto 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, i vincoli e i requisiti non funzionali. Successivamente, menziona tutti i dati in ingresso, come il codice sorgente, la documentazione, l'infrastruttura.
Il passo successivo. Elenca tutti i problemi che hai trovato manualmente o utilizzando strumenti automatizzati. Inserisci i lunghi rapporti generati automaticamente alla fine nella sezione allegati. Qui devono esserci prove brevi e concise dei problemi riscontrati.
Dai priorità ai problemi riscontrati su una scala di errori, avvisi, informazioni. Puoi scegliere la tua scala, ma questa è quella comunemente accettata.
Come un vero architetto, sei tenuto a fornire raccomandazioni per risolvere i problemi trovati. Descrivi i miglioramenti e il valore per il business che il cliente potrà ottenere. Come mostrare il valore per il business da di cui abbiamo parlato in precedenza.
Prepara una roadmap con piccole iterazioni. Ogni iterazione deve includere il tempo di esecuzione, la descrizione, il numero di risorse necessarie per il miglioramento, il valore tecnico e il valore per il business.
Concludiamo la valutazione dell'architettura e forniamo al cliente un report
Non inviare mai semplicemente il report via email. Potrebbe non essere mai letto oppure letto senza comprensione senza una spiegazione adeguata. In breve, la comunicazione diretta aiuta a eliminare i malintesi. Dovresti fissare un incontro con il cliente per discutere i problemi riscontrati, evidenziando quelli più significativi. È importante far notare al cliente problemi di cui potrebbe non essere nemmeno a conoscenza, come quelli di sicurezza, e spiegare come possono influenzare il business. Mostra la tua roadmap con le migliorie e discuti le diverse opzioni più adatte per il cliente. Questo potrebbe riguardare tempo, risorse e volume di lavoro.
Come sintesi del tuo incontro, invia al cliente il tuo report.
In conclusione
La valutazione dell'architettura è un processo complesso. Per eseguire una valutazione corretta, è necessario avere esperienza e competenze sufficienti.
È davvero possibile fornire al cliente risultati utili per lui e per la sua azienda in appena una settimana. Anche se lo fai da solo.
Dalla mia esperienza, molti miglioramenti si bloccano a metà strada, e a volte non iniziano neanche. Coloro che scelgono una via di mezzo e implementano solo alcuni miglioramenti davvero utili per il business con il minimo sforzo, riescono a migliorare notevolmente la qualità del loro prodotto. Chi non fa nulla, dopo un paio d'anni potrebbe anche chiudere il progetto.
Il vostro obiettivo è mostrare al cliente il massimo dei miglioramenti al prezzo minimo.
Altri articoli nella sezione puoi leggere con calma.
Ti auguro codice pulito e buone soluzioni architetturali.
Il nostro gruppo Facebook è .
Fonte: habr.com
