Conosci il tuo debito… tecnologico?

Il software è stato inizialmente visto come qualcosa che poteva essere scritto una volta e usato molte volte senza mai “rompersi”. Tuttavia, quell’illusione svanì quando iniziarono ad apparire problemi, in ultima analisi causati da uno sviluppo continuo senza i giusti processi di controllo della qualità. Ciò era in genere dovuto a pressioni aziendali incredibili per rilasciare nuovi prodotti e funzionalità in un tempo compresso per essere sul mercato.

Questi problemi hanno portato ad applicazioni software che trasportano un’enorme quantità di problemi che hanno un nome ben preciso:

DEBITO TECNOLOGICO

Una metafora dei difetti latenti introdotti durante l’architettura, la progettazione o lo sviluppo del sistema. La difettosità accumulata quando le organizzazioni adottano queste scorciatoie di progettazione e test, al fine di raggiungere gli obiettivi a breve termine, alla fine rende il software difficile da mantenere. Con l’aumento del debito tecnologico, gli sviluppatori dedicano la maggior parte del loro tempo a correggere bug e a lottare con codice fragile, invece di concentrarsi sul core business e creare nuove funzionalità.

Molte organizzazioni ora stanno scoprendo che il software legacy ha in genere una diminuzione della durata della vita utile; dopo averlo creato e rilasciato, sono costretti a decidere se buttarlo via e ricominciare da zero, o cercare di recuperarlo. Nella maggior parte dei casi, è stato fatto un notevole investimento finanziario nella base di codice, quindi c’è una tremenda pressione per riutilizzarlo. La chiave per ridurre il debito tecnologico consiste nel rifattorizzare i componenti (il processo di ristrutturazione dei componenti di un’applicazione senza modificarne il comportamento esterno) nel tempo, ma gli sviluppatori sono spesso riluttanti a farlo per paura di corrompere le funzionalità esistenti. Uno dei maggiori ostacoli al refactoring è la mancanza di test che caratterizzano il comportamento esistente di un componente.

Questo è un problema crescente in quanto vi sono molte applicazioni distribuite basate su basi di codice legacy che non hanno i testcase necessari. Questo è aggravato quando il codice legacy viene distribuito su una nuova piattaforma o prodotto, poiché la mancanza di artefatti di test significa che il debito tecnologico continua a crescere senza possibilità di “ripagarlo”. C’è un enorme gap di qualità che deve essere affrontato, ma molte aziende non sanno da dove iniziare o non hanno le risorse necessarie per affrontare il problema.

Le preoccupazioni legate al debito tecnologico si moltiplicano per il mondo dell’IoT

L’avvento e la crescente diffusione dell’Internet of Things (IoT), ha portato a rendere più acuto il problema del debito tecnologico. In precedenza, quando i sistemi erano autonomi e con bassa connettività, era possibile mantenere il debito tecnologico relativamente isolato. Tuttavia, con i dispositivi abilitati all’IoT, non solo il numero di sistemi aumenta, ma il debito tecnologico si complica: i problemi tecnici dei singoli dispositivi non sono un problema, ma nel complesso, il problema è molto più evidente.

Per definizione, ogni dispositivo elettronico abilitato a IoT avrà la connettività di rete, il che rende ogni produttore di dispositivi elettronici di fatto nel settore del software in una certa misura. Questo espande la portata della responsabilità in nuove piattaforme e servizi, oltre a introdurre una domanda di comportamento prevedibile, specialmente se la sicurezza degli utenti o dell’ambiente è a rischio. Tuttavia, in un settore estremamente competitivo come l’IoT, il primo vantaggio sul mercato è enorme e gli sviluppatori saranno sottoposti a forti pressioni affinché i prodotti vengano rilasciati rapidamente. Dobbiamo solo guardare all’espansione di Amazon nell’IoT per apprezzare quanto questo sta diventando mainstream.

È stato dimostrato più volte nello sviluppo del software che questo modo di pensare sacrifica la qualità per la velocità. Questo trade-off può essere pericoloso per quanto riguarda molti prodotti compatibili con IoT come auto intelligenti, dispositivi medici e sistemi di sicurezza domestica. Il malfunzionamento di questi sistemi può mettere a rischio la vita.

Quando il punto di vista dei consumatori diventa critico per la sicurezza

C’è stato anche uno spostamento guidato dall’IoT che ha portato a una nuova generazione di software che in precedenza non aveva requisiti di sicurezza, ma ora lo ha. Ad esempio, mentre entriamo nell’era delle auto connesse e autonome, i sistemi di frenata automatica di emergenza sono controllati da un software che alimenta telecamere, radar, sensori di prossimità e altro ancora che devono funzionare in modo impeccabile per fermare in sicurezza un veicolo se un guidatore è lento a rispondere. Anche la telecamera incorporata precedentemente utilizzata per l’assistenza del conducente (parcheggio ad esempio) farà ora parte di questo sistema di sicurezza. Poiché questi sistemi basati su software migrano da applicazioni di livello consumer a importanti per la sicurezza, i software difettosi presentano gravi conseguenze. La qualità non è più un’opzione – è una necessità.

Caratterizzazione del comportamento del software

Una mancanza di test adeguati in genere significa che un’applicazione software non può essere facilmente cambiata poiché le modifiche possono spesso compromettere seriamente la funzionalità esistente. Di conseguenza, quando uno sviluppatore modifica un’unità di codice e quindi alcune funzionalità esistenti vengono compromesse, lo sviluppatore deve capire se il software originale è stato scritto in modo errato, se manca un requisito che non era stato adeguatamente acquisito in origine – o se era dovuto a una modifica che ha introdotto.

Il Baseline Test, noto anche come test di caratterizzazione, è utile per basi di codice legacy che hanno testcase insufficienti o inadeguati. È molto improbabile che i proprietari di un’applicazione distribuita, senza test adeguati, risalgano mai all’inizio e costruiscano tutti i casi di test richiesti. Tuttavia, poiché l’applicazione è stata utilizzata per un certo periodo di tempo, è possibile utilizzare il codice sorgente esistente come base per creare scenari di test utilizzando la generazione di casi di test automatici per fornire rapidamente una serie di test che catturano e caratterizzano il comportamento dell’applicazione esistente.

Sebbene questi test non dimostrino la correttezza del codice, comunque incapsulano l’applicazione oggi ed il suo comportamento. Ciò è estremamente utile perché è possibile costruire automaticamente una suite di regressione completa che consente di convalidare modifiche, aggiornamenti e modifiche future per garantire che non corrompano la funzionalità esistente. Di conseguenza, la completezza del test delle applicazioni legacy è migliorata e il refactoring può essere fatto con sicurezza che il comportamento dell’applicazione non è regredito.

Saldare il debito tecnologico?

Una volta che il comportamento del software è stato caratterizzato attraverso i test di base, uno sviluppatore può iniziare a fare aggiornamenti e modifiche al codice. Per automatizzare ulteriormente i processi di integrazione e test continui, è possibile utilizzare l’analisi dell’impatto (Change-Impact Analysis) sotto forma Change-Based Testing (CBT) per eseguire solo l’insieme di casi di test sono impattati dalle modifiche del codice sull’integrità dell’intero sistema. Non è raro che un’azienda richieda settimane per eseguire tutti i suoi casi di test, ma con l’approccio CBT, uno sviluppatore può modificare il codice e ottenere feedback sull’impatto sull’intera applicazione in pochi minuti. Di conseguenza, gli sviluppatori sono in grado di apportare modifiche rapide e incrementali al software, sapendo di avere i casi di test necessari per verificare immediatamente il nuovo comportamento esistente del software.

Sono anche in grado di fare ulteriori analisi se qualcosa si è rotto, se è da risolvere, se è stato introdotto un errore, è stata rimossa una capacità che in realtà dovrebbe esserci, o se c’è un bug che dovrebbe essere sistemanto perché potrebbe avere altre ramificazioni.

Figura 1 – Ciclo di riduzione del debito tecnologico

Come vediamo nella Figura 1, il Baselining formalizza ciò che un’applicazione fa oggi, il che consente di convalidare le modifiche future per garantire che la funzionalità esistente non venga corrotta. Il Change-Base Test può essere utilizzato per eseguire solo il set minimo di casi di test necessari per mostrare l’effetto delle modifiche. Ciò consente ai testcase di essere integrati in una piattaforma di Continuous Integration/Continuous Testing come Jenkins, senza introdurre un sovraccarico significativo nel tempo di test per le modifiche al codice.

Conclusione

In un mondo abilitato all’Internet of Things, una grande quantità di codice legacy si farà strada su percorsi critici nelle nuove applicazioni. Senza i corretti metodi di qualità del software esistente per garantire l’integrità di questo codice legacy, la sicurezza complessiva del sistema potrebbe essere compromessa.

Il Baselining può aiutare a ridurre il debito tecnologico nelle basi di codice esistenti e consentire agli sviluppatori di effettuare il refactoring e migliorare con sicurezza. Ciò in definitiva consente ai proprietari di applicazioni legacy di estrarre più valore.

Ulteriori letture

Se questa strategia è interessante per te o la tua azienda, ecco ulteriore materiale di lettura: