# Cos'è un feature flag? Guida semplice per il dev solo

URL: https://whatshouldibuildnext.com/it/journal/cos-e-un-feature-flag
Type: blog
Locale: it
Published: 2026-10-31
Updated: 2026-11-01

---

> Un feature flag è un if che puoi girare senza rifare il deploy. Ecco i quattro tipi, cosa costano e quando un dev solo dovrebbe evitarli.

Cos'è un feature flag? Un `if` la cui risposta vive fuori dal tuo codice. Spedisci il nuovo percorso di codice spento, poi lo accendi più tardi cambiando un valore in un file di configurazione, in una riga del database o in un servizio di flag, senza nessun redeploy. Questo trucco separa il deploy del codice dal rilascio di una funzione, ed è il motivo per cui un flag è il rollback più economico che avrai mai.

Ho imparato la seconda metà di quella frase nel modo difficile. Il mio primo flag era un booleano in una variabile d'ambiente, acceso un venerdì sera, e me ne sono dimenticato per undici mesi. Non si è rotto niente. Ed è proprio questo il problema, ci arriviamo.

## Come appare un feature flag nel codice?

Più piccolo di quanto suggeriscano le homepage dei vendor. Togli le dashboard e un flag è una lettura più un branch:

`const flags = { newCheckout: false };

if (flags.newCheckout) {
  return renderNewCheckout(user);
}
return renderOldCheckout(user);`Tutto il resto è una domanda su da dove arriva `flags` e su chi può cambiarlo. Una costante nel file è un flag che cambi con un deploy, quindi vanifica lo scopo. Una variabile d'ambiente cambia al riavvio. Una riga nel database cambia in pochi secondi. Un servizio ospitato cambia in pochi secondi e in più ti dà il targeting per utente, un'interfaccia e un log di audit.

Il problema vero, in pratica, è questo: il codice è banale, il ciclo di vita no. Due branch in produzione significano due comportamenti da testare, due percorsi da debuggare alle 2 di notte, e uno dei due è destinato a marcire.

![Interruttore industriale a leva rossa su un pannello di controllo in acciaio, un kill switch](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-11/9ca39f-i1.webp)

## Quali sono i quattro tipi di feature flag e da quale iniziare?

La [tassonomia dei feature toggle di Martin Fowler](https://martinfowler.com/articles/feature-toggles.html) è ancora il modo più pulito per ordinarli, e l'asse utile è per quanto tempo ciascun tipo dovrebbe vivere.

**Release flag** nascondono lavoro incompleto o rischioso. Sono transitori: una o due settimane, poi si cancellano. È quello che ti serve per primo.

**Ops flag** sono kill switch. Avvolgi una funzionalità pesante o fragile (un widget di raccomandazioni, una chiamata a un servizio esterno) così puoi spegnerla sotto carico senza deploy. La maggior parte è di breve durata, alcuni restano per sempre e va bene così.

**Experiment flag** dividono gli utenti in coorti per i test A/B. Vivono quanto serve per ottenere un risultato statisticamente significativo, quindi da ore a settimane, e hanno bisogno di traffico reale per avere senso.

**Permission flag** limitano le funzioni per piano o per account: il tier Pro, il gruppo beta. Possono durare anni, e a quel punto non sono davvero più flag. Sono diritti di accesso e meritano un modello dati vero.

Se sei un dev solo con 40 utenti, ti servono release flag e forse un kill switch. Gli experiment flag su 40 utenti producono rumore, non dati. Aspetta finché non sai nominare la metrica e la dimensione del campione.

## Quale problema risolvono i flag che branch e deploy non risolvono?

Tre cose, e solo tre meritano attenzione.

**Spedire lavoro incompleto in sicurezza.** I branch che restano aperti a lungo fanno male, perché il merge diventa una piccola guerra. Un flag ti permette di fare merge su main ogni giorno con il nuovo codice spento. È il motore dello sviluppo trunk-based, dove tutti committano su un solo branch e i flag portano le parti incomplete.

**Rollout graduale.** Accendi la funzione per te, poi per l'1% degli utenti, poi per il 10%, poi per tutti. Fowler descrive la scelta di una coorte canary di circa l'1% prendendo l'ID utente modulo 100. Se qualcosa va storto, il raggio d'impatto sono poche persone invece di tutta la tua base.

**Annullare in fretta.** Fare rollback di un deploy significa una build, una pipeline e un po' di coraggio. Girare un flag significa una modifica. Nelle giornate storte la differenza è tra qualche minuto di dolore e un'ora.

Niente di tutto questo richiede un fornitore il primo giorno. Tutto richiede disciplina.

## Ti serve LaunchDarkly, o un file JSON basta?

Un file JSON o una tabella di database va bene finché non si verifica una di queste condizioni: un non-sviluppatore deve poter girare i flag, ti servono rollout in percentuale o targeting per utente, ti serve una traccia di chi ha cambiato cosa, oppure più servizi leggono gli stessi flag.

Ecco la scala approssimativa che salirei, in ordine:

- 
**Costanti e variabili d'ambiente.** Costo zero. Va bene per il primo release flag di un side project.

- 
**Una tabella `flags` o un file JSON letto a runtime.** Dieci righe di codice, toggle istantanei, nessun fornitore. Questo porta un progetto solo parecchio lontano.

- 
**Un servizio di flag open source o ospitato.** Quando vuoi regole di targeting, rollout graduali e un'interfaccia che può usare qualcun altro.

- 
**Una piattaforma enterprise.** Quando entrano in gioco compliance, approvazioni e decine di ingegneri.

I servizi ospitati coprono i passi 3 e 4. LaunchDarkly è il riferimento storico, con il targeting e la governance più profondi e un prezzo che lo riflette.

Statsig unisce flag, esperimenti e analytics di prodotto, ed è sensato se hai intenzione di misurare cosa ha fatto il flag, non solo di accenderlo e spegnerlo.

Salta entrambi se la tua squadra sei tu. Una tabella con tre colonne batte una dashboard che apri due volte a trimestre. Scegli un servizio solo quando la versione manuale ti è costata qualcosa di preciso, tipo una modifica notturna alla config di produzione di cui poi ti sei pentito.

Un'assicurazione da conoscere: [OpenFeature](https://openfeature.dev/docs/reference/intro) è un progetto CNCF in incubazione che definisce un'API neutrale rispetto ai fornitori per valutare i flag, con SDK per Node.js, Python, Go, Java, .NET e client web, tra gli altri. Programmi contro l'interfaccia standard e cambi il provider sotto. Se sospetti che il tuo primo setup ti starà stretto, passare da OpenFeature trasforma quel cambio in una modifica di configurazione.

![Quaderno con checkbox disegnate a mano e frecce su una scrivania da dev di notte](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-11/f90753-i2.webp)

## Come aggiungi il primo flag senza fare disastri?

Parti da un singolo release flag e da qualche regola base. È la versione che avrei voluto seguire io.

**Dagli il nome della funzione, non del meccanismo.** `new-checkout-flow` ti dice cosa si rompe se è sbagliato. `flag_47` non ti dice niente tra sei mesi.

**Parti da spento, e fa' in modo che spento significhi comportamento vecchio.** La convenzione "spento uguale legacy, acceso uguale nuovo" è ciò che ti permette di ragionare sul sistema sotto pressione. Se la rompi, ogni flag diventa un puzzle.

**Valuta in un solo punto.** Fowler chiama la soluzione inversione del toggle: invece di spargere `if (flags.x)` in venti file, decidi una volta, vicino al bordo del sistema, e passi il risultato dentro. Un solo punto di decisione significa un solo posto dove cambiare e un solo posto dove testare.

**Scrivi il ticket di rimozione nel momento in cui crei il flag.** Mettilo nel backlog con una data. Fowler suggerisce anche date di scadenza sui toggle di breve durata, e perfino test che falliscono quando un flag supera la sua data. Un flag senza ticket di rimozione è un prestito senza piano di rimborso.

**Logga ogni valutazione che conta.** Quando un utente segnala un bug, vuoi sapere da quale lato del flag si trovava. Se non puoi rispondere, il flag è un passivo.

Sui test è dove la gente esagera. Non serve testare ogni combinazione di flag, perché la maggior parte non interagisce con le altre. Testa la configurazione che ti aspetti in produzione, testa il fallback con il flag spento, e facoltativamente fai un passaggio con tutto acceso per intercettare la deriva.

## Qual è il costo reale dei feature flag di cui nessuno parla?

Ogni flag raddoppia un percorso di codice. Dieci flag indipendenti sono, in teoria, 1.024 combinazioni, e anche se non le testerai mai tutte, in produzione potresti incappare in una che nessuno aveva previsto.

Il costo più doloroso sono i flag morti. Il rollout finisce, tutti sono sul nuovo comportamento, il flag resta al 100%, e il ramo vecchio resta nel repo come codice che nessuno osa cancellare. Sei mesi dopo nessuno ricorda se spegnerlo sia sicuro.

La versione famosa di questo è Knight Capital, agosto 2012. Un vecchio flag che un tempo attivava una funzione di trading ritirata è stato riutilizzato per codice nuovo. Uno degli otto server non ha ricevuto il deploy e girava ancora il codice vecchio. In 45 minuti la società ha perso circa $440 milioni secondo il proprio 10-Q trimestrale, cifra che report successivi portano vicino a $460 milioni. Quella è una società di trading con soldi veri e ingegneri veri, quindi non ti dirò che il tuo side project è più sicuro. La lezione si scala giù bene: non riutilizzare mai un nome di flag, e cancella i flag morti prima che diventino archeologia.

![Fila di chiavi di ottone appese a dei ganci, alcune arrugginite e altre lucide, come vecchi flag lasciati nel codice](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-11/967554-i3.webp)

La cornice di Fowler è quella che tengo a mente: tratta i flag come inventario con un costo di mantenimento. Alcuni team limitano il numero di flag attivi e chiedono di rimuoverne uno prima di aggiungerne un altro. Per un dev solo, un tetto fisso di cinque basta e avanza.

## Quando conviene saltare del tutto i feature flag?

Più spesso di quanto ammettano i vendor.

Saltali quando la funzione è piccola, la modifica si annulla facilmente con git e il deploy richiede due minuti. Un flag aggiunge un branch, una fonte di configurazione e una cosa da dimenticare. Se un revert è più veloce di un flip del flag, il flag è teatro.

Saltali quando non hai ancora utenti. Un rollout graduale verso zero persone è solo un ritardo. Spedisci, guarda i log, correggi.

Saltali per le migrazioni di database che un toggle non può annullare. Un flag può nascondere una nuova colonna nell'interfaccia, ma non può ripristinare una tabella cancellata. Le modifiche allo schema richiedono un piano expand-and-contract tutto loro, con o senza flag.

Vale la pena quando la modifica tocca pagamenti o autenticazione, quando vuoi fare merge ogni giorno con lavoro incompleto, o quando una dipendenza esterna potrebbe cadere e vuoi un kill switch.

## Cosa tenere d'occhio con un flag attivo, e cosa fare già questa settimana

Un flag controlla l'esposizione, e l'esposizione serve solo se vedi cosa succede dopo. Accendere una funzione per il 10% degli utenti senza guardare tassi di errore e latenza è testa o croce con qualche passaggio in più.

Prima del primo rollout, assicurati di poter rispondere a tre domande in meno di un minuto: sono aumentati gli errori nella coorte con il flag, la latenza è peggiorata, è cambiato qualcosa a valle? Il monitoraggio di uptime e la ricerca nei log coprono gran parte del problema per un prodotto piccolo, e uno strumento come Better Stack mette monitor, status page e log in un solo posto, con un piano gratuito.

La regola che seguo ora: un flag vale quanto l'allarme collegato. Senza, stai accendendo cose al buio.

Quindi questa settimana: scegli una cosa incompleta che hai paura di fare merge. Mettila dietro un booleano letto da una tabella o da un file JSON, di default spento, e fanne merge su main oggi stesso. Scrivi il ticket di rimozione prima di chiudere l'editor, con una data tra due settimane.

Poi accendila solo per te e usala per un giorno. Se regge, allargala. Se no, spegnila: hai perso solo un minuto.

In quale flag del tuo codice l'interruttore è al 100% da più di un mese? Quella è la tua prima cancellazione.

## FAQ

### Cos'è un feature flag in parole semplici?

Un feature flag è un condizionale nel codice il cui valore on/off è salvato fuori dal codice, in un file di configurazione, in un database o in un servizio di flag. Puoi cambiarlo a runtime, quindi una funzione può essere spedita spenta e rilasciata più tardi senza un altro deploy.

### Feature flag e feature toggle sono la stessa cosa?

Sì. Feature flag, feature toggle, feature switch e release toggle descrivono la stessa tecnica. I team scelgono un termine per abitudine, e gli strumenti li usano come sinonimi.

### Quali sono i tipi principali di feature flag?

Se ne usano comunemente quattro: i release flag per nascondere lavoro incompleto, gli ops flag (kill switch) per spegnere funzioni rischiose, gli experiment flag per i test A/B e i permission flag per limitare le funzioni per piano o account.

### Serve uno strumento a pagamento per i feature flag in un side project?

Di solito no. Una costante, una variabile d'ambiente, un file JSON o una tabella di database coprono un progetto solo. Passa a un servizio ospitato quando i non-sviluppatori devono girare i flag, o quando ti servono rollout in percentuale, targeting e un log di audit.

### Quanto deve vivere un feature flag?

I release flag dovrebbero durare una o due settimane, poi vanno cancellati insieme al vecchio percorso di codice. Gli ops kill switch possono restare più a lungo. I permission flag possono durare anni, ma sono di fatto diritti di accesso e meritano un modello dati vero.

### Qual è il rischio più grande dei feature flag?

I flag morti. Ogni flag aggiunge un percorso di codice che va testato, e un flag lasciato al 100% lascia codice morto che nessuno osa rimuovere. La perdita di circa 440 milioni di dollari di Knight Capital nel 2012 ha coinvolto un vecchio flag riutilizzato. Scrivi il ticket di rimozione quando crei il flag.