All’inizio è sempre difficile comprendere un progetto grande e vecchio. L'architettura è una delle attività di valutazione di un architetto. Di solito devi lavorare con progetti vecchi e grandi e i risultati devono essere consegnati entro una settimana.
Come valutare un progetto da 100k o più righe di codice in una settimana fornendo comunque risultati veramente utili al cliente.
La maggior parte degli architetti e dei responsabili tecnici hanno riscontrato valutazioni di progetti simili. Questo può sembrare un processo semi-formale o un servizio separato come viene fatto nella nostra azienda, in un modo o nell'altro la maggior parte di voi ha affrontato questo problema.
L'originale in inglese per i tuoi amici che non parlano russo è qui: .
L'approccio della nostra azienda
Ti racconterò come funziona nella nostra azienda e come mi comporto in situazioni simili, ma puoi facilmente modificare questo approccio in base alle esigenze del tuo progetto e della tua azienda.
Esistono due tipi di valutazione dell'architettura.
interno – di solito lo facciamo 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 del genere e spesso in tali progetti tutto è tutt'altro che ideale.
- Il team vuole testare il proprio progetto e le proprie soluzioni.
- La squadra sa che le cose vanno male. Potrebbero anche elencare i problemi e le cause principali, ma vogliono un elenco completo di problemi e raccomandazioni per migliorare il progetto.
esterno è un processo più formale di una valutazione interna. Il cliente arriva sempre solo in un caso, quando tutto va male, molto male. Di solito il cliente capisce che ci sono problemi globali, ma non riesce a identificare correttamente le cause e scomporle in componenti.
La valutazione di un'architettura per un cliente esterno è un caso più complesso. Il processo dovrebbe essere più formale. I progetti sono sempre grandi e vecchi. Hanno molti problemi, bug e codice storto. Entro poche settimane al massimo dovrebbe essere pronta una relazione sul lavoro svolto, che dovrebbe includere i principali problemi e raccomandazioni per il miglioramento. Pertanto, se ci occupiamo della valutazione esterna del progetto, la valutazione interna sarà un gioco da ragazzi. Consideriamo il caso più difficile.
Valutazione dell'architettura del progetto aziendale
Un tipico progetto da valutare è un grande, vecchio progetto aziendale con molti problemi. Un cliente viene da noi e ci chiede di sistemare il suo progetto. È come con un iceberg, il cliente vede solo la punta dei suoi problemi e non ha idea di cosa ci sia sott'acqua (nelle profondità del codice).
Problemi di cui il cliente può lamentarsi e di cui potrebbe essere a conoscenza:
- Problemi di prestazione
- Problemi di usabilità
- Distribuzione a lungo termine
- Mancanza di unità e altri test
Problemi di cui molto probabilmente il cliente non è a conoscenza, ma che potrebbero essere presenti nel progetto:
- Problemi di sicurezza
- Problemi di progettazione
- Architettura sbagliata
- Errori algoritmici
- Tecnologie inadeguate
- Debito tecnico
- Processo di sviluppo sbagliato
Processo di revisione dell'architettura formale
Questo è un processo formale che seguiamo come azienda, ma puoi personalizzarlo a seconda della tua azienda e del tuo progetto.
Richiesta da un cliente
Il cliente chiede di valutare l'architettura del progetto attuale. La persona responsabile da parte nostra raccoglie le informazioni di base sul progetto e seleziona gli esperti necessari. A seconda del progetto, questi possono essere esperti diversi.
Architetto della soluzione – il principale responsabile della valutazione e del coordinamento (e spesso l’unico).
Impila esperti specifici – .Net, Java, Python e altri specialisti tecnici a seconda del progetto e delle tecnologie
Esperti del cloud – questi possono essere architetti cloud di Azure, GCP o AWS.
Infrastruttura – DevOps, amministratore di sistema, ecc.
Altri esperti – come big data, machine learning, ingegnere delle prestazioni, esperto di sicurezza, responsabile del QA.
Raccolta di 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 mail. Il modo più inefficace.
- Incontri in linea.
- Strumenti speciali per lo scambio di informazioni come: Google doc, Confluence, repository, ecc.
- Incontri “dal vivo” sul posto. Il modo più efficace e più costoso.
Cosa dovresti ottenere dal cliente?
Informazioni di base. Di cosa tratta il progetto? Il suo scopo e valore. Obiettivi principali e progetti per il futuro. Obiettivi e strategie aziendali. Principali problemi e risultati attesi.
Informazioni sul progetto. Stack tecnologico, framework, linguaggi di programmazione. Distribuzione on-premise o cloud. Se il progetto è nel cloud, quali servizi vengono utilizzati. Quali modelli architettonici e di design sono stati utilizzati.
Requisiti non funzionali. Tutti i requisiti relativi alle prestazioni, alla disponibilità e alla 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! Dovresti sicuramente avere accesso ai repository e alla documentazione su come costruire il progetto.
Accesso alle infrastrutture. Sarebbe bello avere accesso al palco o all'infrastruttura di produzione per lavorare con il sistema live. È un grande successo se il cliente dispone di strumenti per monitorare l'infrastruttura e le prestazioni. Parleremo di questi strumenti nella prossima sezione.
Documentazione. Se il cliente dispone della documentazione, questo è un buon inizio. Potrebbe essere obsoleto, ma è comunque un buon inizio. Non fidarti mai della documentazione: testala con il client, sull'infrastruttura reale e nel codice sorgente.
Processo di valutazione dell'architettura
Come è possibile elaborare una così grande quantità di informazioni in così poco tempo? Prima di tutto parallelizzare il lavoro.
DevOps dovrebbe esaminare l'infrastruttura. La tecnologia porta nel codice. Ingegnere delle prestazioni per visualizzare le metriche delle prestazioni. Uno specialista di database dovrebbe scavare più a fondo nelle strutture dei dati.
Ma questo è il caso ideale quando hai molte risorse. In genere, da una a tre persone valutano un progetto. Puoi anche eseguire tu stesso il preventivo, cosa che spesso accade se hai la conoscenza e l'esperienza adeguate in tutte le aree del progetto. In questo caso, è necessario automatizzare il più possibile tutti i processi.
Sfortunatamente, dovrai leggere la documentazione manualmente. Con la giusta dose di esperienza, puoi comprendere rapidamente la qualità della documentazione. Cosa è vero e cosa chiaramente non coincide con la realtà. A volte potresti vedere un'architettura nella documentazione che non funzionerà mai nella vita reale. Questo è uno stimolo per pensare a come è stato fatto nella realtà nel progetto.
Strumenti utili per automatizzare la valutazione dei progetti
La valutazione del codice è un esercizio semplice. Puoi utilizzare analizzatori di codice statici che mostreranno problemi di progettazione, prestazioni e sicurezza. Eccone alcuni:
è un ottimo strumento per un architetto. Ti mostrerà il quadro generale, le dipendenze tra i moduli e le potenziali aree per il refactoring. Come tutti gli strumenti validi, costa bene, ma puoi usufruire di una versione di prova di 30 giorni.
- un buon vecchio strumento. Uno strumento per l'analisi statica del codice. Ti consente di identificare codici errati, bug e problemi di sicurezza per più di 20 linguaggi di programmazione.
Tutti i fornitori di servizi cloud dispongono di strumenti di monitoraggio dell'infrastruttura. Ciò ti consentirà di valutare correttamente l'efficacia della tua infrastruttura in termini di costi e prestazioni. Per AWS questo è . È facile per Azure .
Il monitoraggio e la registrazione aggiuntivi delle prestazioni aiuteranno a individuare i problemi di prestazioni a tutti i livelli. Partendo da un database con query inefficaci, il backend e finendo con il frontend. Anche se il cliente non ha installato questi strumenti in precedenza, è possibile integrarli nel sistema esistente abbastanza rapidamente per identificare i problemi di prestazioni.
Come sempre, vale la pena utilizzare buoni strumenti. Posso consigliare un paio di strumenti a pagamento. Ovviamente puoi usare l'open source ma ti ci vorrà più tempo. E questo dovrebbe essere fatto in anticipo, non durante il processo di valutazione dell'architettura.
– uno strumento per valutare le prestazioni dell'applicazione
– servizio di monitoraggio del sistema cloud
Sono disponibili molti strumenti per i test di sicurezza. Questa volta ti consiglierò 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 in un tutto.
Preparazione di un rapporto
Inizia il tuo report con i dati raccolti dal cliente. Descrivere gli obiettivi del progetto, i vincoli, i requisiti non funzionali. Successivamente, dovrebbero essere menzionati tutti i dati di input: codice sorgente, documentazione, infrastruttura.
Passo successivo. Elenca tutti i problemi riscontrati manualmente o utilizzando strumenti automatizzati. Inserisci i report di grandi dimensioni generati automaticamente alla fine della sezione delle applicazioni. Dovrebbero esserci prove brevi e concise dei problemi riscontrati.
Dare priorità ai problemi riscontrati sulla scala errori, avvisi e informazioni. Puoi scegliere la tua scala, ma questa è quella generalmente accettata.
Come vero architetto, è tua responsabilità fornire consigli per correggere i problemi riscontrati. Descrivi i miglioramenti e il valore aziendale che il cliente riceverà. Come mostrare il valore aziendale da abbiamo discusso in precedenza.
Preparare una tabella di marcia con piccole iterazioni. Ogni iterazione dovrebbe contenere il tempo per il completamento, la descrizione, la quantità di risorse necessarie per il miglioramento, il valore tecnico e il valore aziendale.
Completiamo la valutazione dell'architettura e forniamo al cliente un report
Non limitarti mai a inviare un rapporto. Potrebbe non essere letto affatto, o potrebbe non essere letto e compreso senza un'adeguata spiegazione. In breve, la comunicazione dal vivo aiuta a eliminare le incomprensioni tra le persone. Dovresti fissare un incontro con il cliente e parlare dei problemi riscontrati, concentrandoti su quelli più significativi. Vale la pena attirare l'attenzione del cliente su problemi di cui potrebbe non essere nemmeno a conoscenza. Ad esempio, problemi di sicurezza e spiegare come potrebbero influire sull'azienda. Mostra la tua roadmap con miglioramenti e discuti le diverse opzioni più adatte al cliente. Potrebbe trattarsi di tempo, risorse, quantità di lavoro.
Come riepilogo del tuo incontro, invia il tuo rapporto al cliente.
insomma
La valutazione dell’architettura è un processo complesso. Per condurre una valutazione correttamente è necessario disporre di sufficiente esperienza e conoscenza.
È possibile fornire al cliente risultati utili per lui e per la sua attività in solo una settimana. Anche se lo fai da solo.
In base alla mia esperienza, molti miglioramenti sono stati scaricati a metà e talvolta non sono mai stati avviati. Coloro che hanno scelto per se stessi la via d'oro e hanno apportato solo una parte dei miglioramenti più utili per l'azienda con costi di manodopera minimi hanno migliorato significativamente la qualità del proprio prodotto. Coloro che non hanno fatto nulla dopo un paio d’anni potrebbero chiudere del tutto il progetto.
Il tuo obiettivo è mostrare al cliente i massimi miglioramenti al prezzo minimo.
Altri articoli della sezione puoi leggere a tuo piacimento.
Ti auguro un codice pulito e buone decisioni architettoniche.
Il nostro gruppo Facebook - .
Fonte: habr.com