Abbiamo finito? No.
Dobbiamo sempre ricordarci che solo l’utilizzo della piattaforma da parte degli stakeholders e degli utenti può dirci se abbiamo davvero raggiunto gli obiettivi prefissati oppure sono necessari ulteriori sviluppi o delle migliorie oppure ancora ulteriori richieste implementative.
Infatti il primo rilascio ne avvia la manutenzione, così da assicurare che sia garantita la continuità, che eventuali problemi siano gestiti con prontezza e che l’applicazione resti in linea con le necessità aziendali nel corso del tempo.
Ecco perché la manutenzione inizia con la progettazione.
Partiamo dall’inizio ponendoci una serie di domande.
Come vorresti che fosse la soluzione digitale per la tua azienda?
Quali processi va a toccare?
Quali impatti ha sull’operatività?
Qualunque siano le risposte a questa serie di domande, l’ideale è costruire un’architettura che sia scalabile e facilmente manutenibile, a microservizi, evitando quindi gli ambienti monolitici.
E già qui, nonostante siamo solo alle prime righe di codice o addirittura non abbiamo neppure scritto la prima classe, dobbiamo iniziare a pensare alla manutenzione.
Perchè? Così da renderla più semplice e veloce in futuro.
Ma questo non riguarda solo il team di sviluppo e la manutenibilità del codice.
Sarebbe bene coinvolgere in questa fase iniziale anche il team che poi si occuperà della manutenzione.
Cerchiamo di capire il perché di questo approccio.
Innanzitutto, dobbiamo sottolineare che la manutenzione non dovrebbe essere solo reattiva, ma anche preventiva.
Questo poiché così è possibile garantire che la soluzione sia utilizzata senza intoppi e che sia aggiornata a livello tecnologico e applicativo. Apriamo una piccola parentesi a tal proposito: tutti gli aggiornamenti dovrebbero essere calendarizzati e condivisi a priori, così che vengano eseguiti tutti a tempo debito e che i bug vengano addirittura risolti prima che causino vere e proprie complessità, evitando inoltre i momenti più critici per l’azienda e in cui gli SLA si dovrebbero estendere (high availability time frames).
Una progettazione ben strutturata e modulare facilita l’identificazione e l’isolamento dei bug.
Se il codice è organizzato in modo logico, con moduli e classi separati e ben definiti, sarà più facile individuare e risolvere bug o apportare modifiche.
Questo ci porta ad una considerazione ulteriore: un codice pulito e ben organizzato rende più semplice la comprensione da parte di tutto il team di sviluppatori, con beneficio sugli interventi futuri o sul onboarding di nuovi developers.
Durante la progettazione è possibile prevedere e considerare eventuali possibili modifiche o aggiornamenti futuri, in modo da predisporre una serie di interfacce, oppure un sistema a plugin, così che sia semplice in futuro aggiungere delle funzionalità senza riscrivere buona parte della codebase.
Un ulteriore beneficio di una progettazione basata su codice pulito e riutilizzabile, ci permette di avere un ambiente dove i singoli componenti siano testabili in modo indipendente ed isolato e dove sia facile la riproducibilità (e relativa risoluzione) dei bug eventualmente emersi.
Utilizzando una buona progettazione dell’applicativo abbiamo l’opportunità di seguire e conformarci alle best practice di sviluppo software e design pattern riconosciuti a livello globale, come il principio SOLID (Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion), implementazione di unit test e anche test automatizzati e2e.
Tutto questo migliora la manutenibilità del codice nel tempo.
Ritorniamo al fulcro principale, ora. Come ormai sappiamo, le necessità e le esigenze (sia di business che operative) delle organizzazioni evolvono in continuazione: questo ci porta a affermare che tutte le soluzioni dovrebbero essere progettate in questo modo, così da essere scalabili, ed avendo la giusta dose di flessibilità così da consentire le modifiche di manutenzione senza interrompere un servizio.
Tenendo la situazione monitorata, sia con l’utilizzo di tools e strumenti dedicati, ma anche ascoltando il feedback degli utenti finali, si potrà avere una panoramica generale, che va dagli aspetti più tecnologici a quelli dell’esperienza degli utenti, in modo da identificare le vulnerabilità e i problemi prima degli stakeholders, ottenendo in questo modo un vantaggio nella risoluzione.
Questo è essenziale: senza un miglioramento continuo e costante, anche il migliore software sviluppato è destinato a decade, deteriorarsi e diventare obsoleto in poco tempo.
Quando la manutenzione è ben strutturata ed è introdotta nel momento della progettazione e portata avanti con un monitoraggio continuo, è in grado di fornire all’organizzazione feedback quasi istantanei e gestione delle complessità proattive o comunque veloci nell’implementazione.
Questo approccio è fondamentale per migliorare l’applicazione e assicurarsi che evolva insieme all’azienda stessa e consente di definire nel modo più preciso ed efficace il perimetro d’azione della manutenzione. Così facendo la soluzione assicurerà agli utenti nel tempo chiarezza, logica e semplicità di utilizzo.
In conclusione, la progettazione è fondamentale per garantire una buona manutenzione del software. Una progettazione ben strutturata, chiara e testabile semplifica l’individuazione e la risoluzione dei bug, permette modifiche future più agevoli e favorisce la scrittura di codice di qualità. Questi fattori contribuiscono a ridurre i costi e gli sforzi necessari per la manutenzione del software nel lungo periodo.
