Blog

Codice che consuma meno: l’efficienza energetica sta diventando il nuovo standard del software?

- -
Efficient Code

Per molti anni, la qualità del software è stata misurata principalmente attraverso la funzionalità, la sicurezza, la velocità e l’affidabilità. Un’applicazione era considerata valida se svolgeva correttamente il proprio compito, rispondeva rapidamente ed era in grado di gestire un numero crescente di utenti.

Tuttavia, ogni azione eseguita da un sistema digitale richiede risorse. Il processore esegue istruzioni, la memoria archivia dati, i server elaborano richieste e le reti trasportano informazioni. Più risorse utilizza un’applicazione, maggiori possono essere l’infrastruttura e l’energia necessarie per il suo funzionamento.

Questo introduce un nuovo criterio nello sviluppo software: l’efficienza energetica.

Uno studio condotto da GitHub e dallo Yale Program on Climate Change Communication su 1.039 utenti di GitHub ha rilevato che l’80% degli intervistati era interessato a strumenti capaci di aiutarli a scrivere codice più efficiente dal punto di vista energetico. Allo stesso tempo, il 78% desiderava conoscere pratiche migliori per ridurre l’impatto ambientale del software, mentre il 74% era interessato a metodi concreti per misurare tale impatto.

Questi risultati dimostrano che l’interesse esiste già. La sfida consiste nel trasformarlo in una parte misurabile e ripetibile del processo di sviluppo.

L’efficienza del software inizia dall’utilizzo delle risorse

Il software non consuma energia direttamente nello stesso modo di un dispositivo fisico. Determina la quantità di lavoro che deve svolgere l’infrastruttura sulla quale viene eseguito.

Un algoritmo che ripete più volte lo stesso calcolo utilizza una maggiore capacità di elaborazione. Un’applicazione che recupera più dati del necessario aumenta l’utilizzo del database e della rete. Una pagina che carica immagini, video o componenti non necessari richiede un maggiore trasferimento di dati e più lavoro da parte del dispositivo dell’utente.

Nei sistemi di piccole dimensioni, queste differenze possono sembrare insignificanti. Tuttavia, quando un’applicazione viene utilizzata da migliaia o milioni di persone, anche una piccola operazione inefficiente può essere ripetuta su una scala molto ampia.

Per questo motivo, il software energeticamente efficiente non nasce soltanto nei data center o dalla fonte dell’elettricità utilizzata. Inizia anche dalle decisioni prese durante la progettazione e la scrittura del codice.

Un codice più veloce non è automaticamente più sostenibile

La velocità e l’efficienza energetica sono spesso collegate, ma non rappresentano la stessa cosa.

Una funzione che termina più rapidamente può utilizzare meno tempo del processore. Tuttavia, una soluzione più veloce può richiedere più memoria, hardware aggiuntivo o un’elaborazione parallela più intensa. In questo caso, il tempo di esecuzione diminuisce, ma l’utilizzo complessivo delle risorse potrebbe non ridursi.

Anche l’infrastruttura sulla quale viene eseguito il software influisce sul risultato. Lo stesso carico di lavoro può presentare caratteristiche energetiche differenti in base all’hardware, alla posizione del data center, al momento dell’esecuzione e alla fonte dell’elettricità.

Pertanto, un miglioramento non dovrebbe essere automaticamente definito più ecologico soltanto perché il codice è più veloce. Tale affermazione deve essere supportata da misurazioni collegate alla modifica specifica.

Per questo motivo, lo sviluppo di software energeticamente efficiente richiede non soltanto ottimizzazione, ma anche prove.

La misurazione deve diventare parte del processo di sviluppo

Un team software non può migliorare in modo affidabile ciò che non è in grado di misurare.

Prima di introdurre un’ottimizzazione, è necessario stabilire la condizione iniziale. Questa può includere il tempo di esecuzione, l’utilizzo del processore, il consumo di memoria, il numero di richieste al database o la quantità di dati trasferiti attraverso la rete.

Dopo la modifica, le stesse misurazioni devono essere ripetute in condizioni comparabili. In questo modo, il team può comprendere se l’ottimizzazione ha prodotto un miglioramento reale e quali compromessi ha comportato.

Per esempio, sostituire un’operazione di ricerca inefficiente con una struttura dati più adeguata può ridurre il tempo di elaborazione. Tuttavia, se la nuova soluzione utilizza più memoria, questo cambiamento deve essere documentato e valutato.

Una pull request incentrata sull’efficienza dovrebbe mostrare quale problema è stato identificato, quali metriche sono state utilizzate, quale fosse il risultato iniziale e che cosa sia cambiato dopo l’intervento.

In questo modo, l’efficienza non rimane un’affermazione generale. Diventa un risultato tecnico che può essere verificato.

L’inefficienza può nascondersi in diverse parti del sistema

Il consumo non necessario di risorse non è causato soltanto da algoritmi complessi. Può manifestarsi nell’intera architettura di un’applicazione.

Nel codice, i problemi possono essere collegati a calcoli ripetuti, cicli inefficienti, creazione non necessaria di oggetti o processi i cui risultati potrebbero essere memorizzati nella cache e riutilizzati.

Nel livello dei dati, l’applicazione può recuperare più informazioni del necessario, eseguire query senza limiti o contattare più volte il database per ottenere dati che potrebbero essere recuperati insieme.

Nelle comunicazioni di rete, l’inefficienza può derivare da richieste duplicate, dal controllo continuo delle modifiche, dall’assenza di compressione o dal trasferimento di file più grandi di quanto necessario per l’utente.

Anche il frontend può utilizzare risorse inutilmente attraverso rendering ripetuti, il caricamento anticipato di elementi che non vengono visualizzati sullo schermo o l’impiego di formati multimediali troppo pesanti.

Questo significa che l’efficienza energetica non è responsabilità di un solo componente. Deve essere valutata lungo l’intero flusso del sistema.

L’infrastruttura cloud non risolve automaticamente il problema

Il passaggio al cloud può aiutare le organizzazioni a utilizzare un’infrastruttura più flessibile e ad adattare la capacità in base al carico di lavoro. Tuttavia, il cloud non rende automaticamente efficiente un’applicazione.

Se un servizio esegue calcoli non necessari, archivia dati che non vengono utilizzati o mantiene attive risorse in assenza di carico, il problema continua a esistere. Viene semplicemente trasferito dall’infrastruttura locale a quella del fornitore cloud.

L’architettura dovrebbe essere progettata in modo che le risorse vengano attivate quando sono necessarie e ridotte quando non vengono utilizzate. I processi pianificati dovrebbero essere eseguiti con la frequenza appropriata, mentre gli ambienti di test non dovrebbero rimanere attivi senza motivo.

L’efficienza può ridurre contemporaneamente l’utilizzo dell’infrastruttura, la latenza del sistema e i costi operativi. Per questo motivo, il Green Software non dovrebbe essere considerato esclusivamente un’iniziativa ambientale. Può rappresentare anche una buona pratica economica e architetturale.

Anche il processo di sviluppo utilizza energia

L’attenzione si concentra solitamente sull’applicazione finale, ma anche il processo di costruzione e distribuzione utilizza risorse.

Ogni build, test automatizzato, scansione di sicurezza e processo di distribuzione richiede potenza di calcolo. Se una piccola modifica attiva continuamente l’intera suite di test, oppure se diverse pipeline eseguono lo stesso lavoro, il team potrebbe utilizzare più risorse del necessario.

Il miglioramento dei processi CI/CD può includere la memorizzazione nella cache dei risultati intermedi, l’esecuzione dei soli test collegati a una determinata modifica, l’eliminazione delle attività duplicate e la disattivazione dei processi che non producono più valore.

Questo non significa ridurre i controlli che garantiscono la qualità e la sicurezza. L’obiettivo è ottenere le stesse garanzie con una quantità minore di lavoro non necessario.

L’AI può individuare le inefficienze, ma non dovrebbe prendere la decisione finale

Nei repository di grandi dimensioni, individuare manualmente tutte le opportunità di ottimizzazione può richiedere molto tempo. Gli agenti AI possono essere utilizzati per analizzare il codice, i dati, le comunicazioni di rete e il frontend, evidenziando le operazioni che potrebbero essere ottimizzate.

GitHub ha pubblicato un processo sperimentale che ricerca opportunità per migliorare l’efficienza, esegue i test e può preparare bozze di pull request accompagnate da misurazioni e possibili compromessi. Tuttavia, le modifiche non vengono integrate automaticamente nel codice principale, ma vengono presentate ai responsabili della manutenzione per essere verificate.

Questa distinzione è importante. L’AI può identificare una sezione di codice che appare inefficiente, ma non sempre comprende l’intero contesto aziendale o la motivazione architetturale che la giustifica.

Un’ottimizzazione può migliorare le prestazioni e, contemporaneamente, rendere il codice più complesso. Può ridurre l’utilizzo del processore, ma aumentare il consumo di memoria. Può funzionare correttamente durante i test, ma comportarsi in modo diverso con un carico reale.

Per questo motivo, ogni raccomandazione dell’AI dovrebbe essere trattata come un’ipotesi da verificare, non come una decisione da applicare automaticamente.

L’efficienza deve diventare un criterio architetturale

Le decisioni con l’impatto maggiore vengono generalmente prese prima che sia scritta la maggior parte del codice.

Il modo in cui i servizi vengono suddivisi, il luogo in cui vengono archiviati i dati, il modo in cui i componenti comunicano e i processi eseguiti in tempo reale determinano la quantità di risorse necessarie al sistema durante l’intero ciclo di vita.

Se l’efficienza viene presa in considerazione soltanto dopo il completamento del prodotto, lo spazio disponibile per il cambiamento può essere limitato. Gli interventi successivi possono richiedere la riscrittura di componenti o una modifica dell’architettura.

Per questo motivo, i requisiti relativi al software energeticamente efficiente dovrebbero essere inclusi nelle specifiche, nei criteri di accettazione e nelle decisioni architetturali. Il team dovrebbe definire quali risorse è importante misurare e quale livello di utilizzo è considerato accettabile.

L’efficienza diventa quindi parte del modo in cui il sistema viene progettato, anziché un’ottimizzazione aggiunta alla fine.

Un software efficiente richiede prove, non soltanto dichiarazioni

Per ALSoft, l’efficienza energetica del software dovrebbe essere trattata come un problema ingegneristico che richiede dati verificabili.

Non è sufficiente che un team descriva un’applicazione come sostenibile o rispettosa dell’ambiente. Deve essere chiaro che cosa è stato misurato, che cosa è stato migliorato e quali limiti si applicano alla valutazione.

Come afferma Ermal Beqiri, fondatore di ALSoft:

«Un software efficiente non si costruisce semplicemente scrivendo codice più veloce. È necessario comprendere dove vengono utilizzate le risorse, misurare l’impatto di ogni modifica e scegliere un’architettura che raggiunga lo stesso obiettivo con meno lavoro non necessario. Soltanto allora l’efficienza energetica diventa un autentico standard ingegneristico.»

Lo sviluppo software sta entrando in una fase in cui la funzionalità e le prestazioni non sono più gli unici criteri. I team stanno iniziando a valutare anche quante risorse siano necessarie a un sistema per raggiungere il proprio obiettivo.

Questo non significa che ogni applicazione debba essere ottimizzata fino al più piccolo dettaglio tecnico. Significa che l’utilizzo non necessario del processore, della memoria, della rete e dell’infrastruttura dovrebbe diventare visibile e misurabile.

Se la misurazione dell’efficienza viene integrata nei test, nella revisione del codice e nelle decisioni architetturali, il consumo delle risorse può essere trattato come qualsiasi altro indicatore di qualità.

Il software energeticamente efficiente non è semplicemente un software che consuma meno. È un software che raggiunge il proprio obiettivo utilizzando le risorse in modo più attento, misurabile e ragionato.

Lasciaci un messaggio Ti risponderemo entro 1 giorno lavorativo.