Una feature flag consente di separare il rilascio del codice dall’attivazione di una funzionalità. Questa separazione è utile durante la convalida o il coordinamento di una modifica, ma una flag che resta nel sistema senza essere riesaminata può lasciare rami di codice dimenticati e aggiungere complessità a ogni intervento di manutenzione. Ritirarla non significa soltanto cancellare una condizione: occorre decidere quale comportamento mantenere, verificare chi dipende dalla flag e convalidare che la pulizia non modifichi altri flussi.
L’obiettivo pratico è trattare ogni flag temporanea come un elemento dotato di uno scopo, un responsabile e un criterio di uscita. In questo modo, il team può conservare le flag che svolgono ancora una funzione ed eliminare quelle che ormai rappresentano soltanto debito tecnico.
Che tipo di flag hai e a cosa serve
Prima di modificare il codice, individua la funzione della flag. Non tutte dovrebbero essere ritirate con la stessa tempistica e alcune non sono temporanee. Una semplice classificazione aiuta a evitare sia la rimozione prematura sia il mantenimento per inerzia:
- Flag di rilascio: controlla l’accesso a una funzionalità in fase di introduzione. Se il nuovo comportamento è ormai quello scelto per il prodotto e non serve usare la flag per tornare a quello precedente, in genere è candidata alla rimozione.
- Flag di sperimentazione: consente di confrontare varianti o limitare un test. Va riesaminata al termine dell’esperimento e dopo aver deciso quale variante mantenere. Conservare le relative condizioni senza un’ipotesi attiva può lasciare risultati e percorsi ambigui.
- Configurazione permanente: permette di regolare in modo continuativo un comportamento operativo o un’opzione del prodotto. Non è necessariamente debito temporaneo: richiede documentazione, controlli e un responsabile, come qualsiasi configurazione mantenuta.
Possono esserci anche flag di emergenza o operative, che permettono di disattivare una funzione in circostanze specifiche. Non rimuoverle solo perché sono presenti nel sistema da molto tempo: verifica prima se esiste ancora un’esigenza e se un altro meccanismo svolge la stessa funzione. La domanda chiave non è da quanto tempo esiste una flag, ma quale decisione o capacità abilita oggi.
Definisci fin dall’inizio un responsabile e una condizione di ritiro
Il modo più efficace per ridurre l’inventario dimenticato è registrare il ciclo di vita quando si crea la flag. Includi almeno lo scopo, un responsabile identificabile, il comportamento che si prevede di mantenere e una data o un evento per la revisione. La data non deve comportare una rimozione automatica: serve a evitare che la decisione resti senza un responsabile.
Descrivi la condizione di uscita in modo verificabile. Per esempio, il team può concordare di riesaminare la flag al termine di un test, al completamento di una migrazione o dopo aver confermato l’adozione del nuovo comportamento. Evita formule vaghe come «rimuovere quando possibile». Se il criterio dipende da una decisione di prodotto, indica chi deve prenderla e quali informazioni servono.
Una scheda minima può includere:
- Nome e posizione della flag.
- Tipologia e motivo per cui è stata creata.
- Responsabile della decisione e della modifica al codice.
- Utenti, ambienti o servizi potenzialmente interessati.
- Condizione di ritiro e data della revisione.
Se una flag non ha un responsabile, il primo passo non è eliminarla alla cieca. Assegna l’incarico a qualcuno che possa verificarne lo scopo e le dipendenze, oppure sottoponi la decisione al team che mantiene quella parte del prodotto.
Verifica chi dipende dalla flag
Prima di consolidare un percorso, controlla tutti i punti in cui la flag viene valutata o configurata. Una ricerca nel repository può individuare i riferimenti diretti, ma non sempre mostra i consumatori indiretti, le regole conservate fuori dal codice o le differenze tra ambienti. Confronta i risultati con il sistema di configurazione e le procedure del team.
Procedi con ordine:
- Riferimenti nel codice: individua le condizioni, le funzioni di supporto, i test e i componenti che leggono la flag. Cerca anche i nomi precedenti, se è stata rinominata.
- Configurazione per ambiente: verifica se i valori differiscono tra sviluppo, test e produzione. Non presumere che lo stato osservato in un ambiente valga anche per gli altri.
- Ambito degli utenti: accerta se la condizione si applica a tutto il pubblico oppure solo a segmenti, account o ruoli specifici. Un percorso ancora attivo per un gruppo può sfuggire ai test generali.
- Dipendenze esterne: controlla la documentazione operativa, le attività automatizzate e gli altri componenti che leggono o modificano lo stato della flag.
- Utilizzo osservato: se è disponibile la telemetria, verifica se la flag viene valutata e in quale contesto. L’assenza di eventi è significativa solo se la strumentazione copre i flussi rilevanti.
La telemetria fornisce elementi utili, ma non sostituisce la revisione del progetto. Un percorso usato raramente, un ambiente senza traffico o una metrica incompleta possono far credere erroneamente che nessuno dipenda dalla flag.
Elimina i rami alternativi con una modifica controllata
Una volta concordato il comportamento definitivo, semplifica la logica affinché l’applicazione esprima direttamente quella decisione. Se si mantiene la nuova variante, rimuovi il ramo precedente e la condizione che non serve più. Se si sceglie la variante precedente, elimina l’alternativa scartata. Evita di sostituire una vecchia flag con un’altra senza una chiara esigenza operativa: così sposti il debito, non lo risolvi.
Suddividi il lavoro in passaggi comprensibili. Rimuovi prima i riferimenti nel codice e i test che esistevano solo per l’opzione scartata; poi elimina la definizione e i valori di configurazione. Se la flag interessa più servizi o repository, coordina la sequenza per evitare che un aggiornamento lasci dei componenti in attesa di un’opzione non più disponibile. Se non puoi completare tutto con un’unica modifica, documenta le dipendenze ancora da risolvere e assegna un responsabile a ciascuna.
I test devono coprire il comportamento mantenuto, non limitarsi a dimostrare che la flag è scomparsa. Esegui i test pertinenti ai percorsi modificati e aggiungi o aggiorna i casi che dipendevano dalla condizione: autorizzazioni, errori, stati vuoti o differenze tra ambienti, quando sono rilevanti per il sistema. Rivedi la modifica per individuare condizioni ridondanti, codice irraggiungibile e presupposti rimasti senza verifica.
Convalida la chiusura con segnali e documentazione
Prima di considerare conclusa l’attività, verifica che il codice compilato o in esecuzione non consulti più la flag e che la relativa configurazione sia stata rimossa dagli ambienti interessati. Controlla anche che dashboard, avvisi, istruzioni per l’assistenza e documentazione non dicano ancora che qualcuno può modificarla. Se la modifica incide su un flusso visibile, convalida il risultato secondo i criteri abituali del prodotto e osserva i segnali disponibili dopo il rilascio.
Stabilisci in anticipo cosa monitorare e per quanto tempo, in base al rischio della modifica. Può bastare controllare gli errori, il completamento delle attività o le segnalazioni relative al flusso; non inventare una soglia se il team non dispone di un valore di riferimento. Se si verifica una regressione, cerca di capire se dipende dalla decisione funzionale, da una dipendenza non rilevata o dalla rimozione di una protezione operativa.
Se il rischio giustifica una modalità di recupero, decidi esplicitamente quale sarà. Può essere ragionevole conservare per un periodo limitato un’opzione di ripristino documentata; non lo è lasciare la flag a tempo indeterminato senza responsabile né criteri d’uso. Registra la decisione e programma una nuova revisione se il ritiro viene rinviato.
Quando mantenerla e lista di controllo
È opportuno mantenere una flag se continua a controllare una configurazione necessaria, un test ancora in corso o una capacità di risposta senza sostituti. Sono invece segnali che si può ritirare il fatto che la decisione di prodotto sia stata presa, che l’alternativa non venga usata né sia necessaria e che nessun team o processo dipenda da essa. Il fatto che una flag sia sempre attiva è un indizio, non una prova: verifica prima che quello stato valga per tutti gli utenti e gli ambienti pertinenti.
Inserisci la pulizia nelle normali revisioni del team. A ogni revisione del prodotto o attività di manutenzione, cerca flag scadute, senza responsabile, prive di una condizione di uscita o legate a esperimenti conclusi. Dai priorità a quelle che aggiungono ramificazioni ai percorsi più frequenti o rendono più difficili le modifiche future. Una breve lista di controllo evita che la pulizia diventi un’iniziativa separata, destinata a essere rimandata.
- Lo scopo e la tipologia della flag sono chiari?
- Sono documentati un responsabile e una condizione di ritiro?
- Sono stati verificati codice, configurazione, ambienti e consumatori?
- È stato deciso quale comportamento mantenere e sono stati eliminati i rami scartati?
- I test coprono i flussi interessati e sono previsti controlli dei segnali successivi?
- La documentazione e le procedure sono state aggiornate e la configurazione obsoleta è stata rimossa?
Un ritiro eseguito correttamente lascia meno percorsi possibili e rende più visibile la decisione nel codice. Se una risposta della lista resta in sospeso, trasforma l’incertezza in un’attività concreta, con un responsabile e una data di revisione. Così le feature flag temporanee svolgono la loro funzione senza diventare rami nascosti permanenti.