Ci sono molte ottime risposte qui, tutte guidate dall'importante definizione di base resa popolare nel post di Martin Fowler :
Sono frammenti di codice che "[consentono] ai team di modificare il comportamento del sistema senza cambiare codice".
Quindi storicamente li abbiamo pensati come rappresentati dallo pseudo-codice:
if(app_settings["beta-mode"] == "true")
showAwesomeNewGui();
else
sameOldSnoozeFeset();
Questo è un modo totalmente accurato di pensarlo, e sia Matt che Adil lo espandono piacevolmente con una varietà di casi d'uso tattici per la flag delle caratteristiche.
Ma vorrei offrire una definizione rivista che rifletta come la realtà si è evoluta nei sei anni e come è cambiata da quando dotnetdev ha posto la domanda originale. Lavoro per Rollout.io , una piattaforma di flag di funzionalità, quindi ho avuto un posto in prima fila per questa evoluzione.
In poche parole, i flag di funzionalità non sono più solo un modo per attivare e disattivare bit di funzionalità nella tua applicazione. È come rispondere "che cos'è una voce di fattura" dicendo "è una descrizione e un importo in valuta". Vero, ma non funziona nel punto più ampio della fattura stessa.
I flag di funzionalità sono i bit tattici di una soluzione strategica globale nel software moderno. Sono i mezzi con cui rinviare la logica decisionale importante nel codice fino al runtime quando si hanno più informazioni. E, forse la cosa più importante, non si verificano più solo in isolamento, con un singolo controllo per vedere se il numero di versione è maggiore di 2.7 o meno; le organizzazioni che li utilizzano in genere li includono come parte di un approccio al prodotto completo a livello di sistema.
Come altri hanno già detto, Facebook e LinkedIn hanno aperto la strada a questo, ma nel 2018 molte organizzazioni lo stanno facendo. Rimandano le domande sulla logica decisionale per il runtime come parte della strategia di sviluppo, della strategia operativa (o della strategia DevOps, se lo si desidera) e della strategia del prodotto. Ecco alcuni esempi di tali domande.
- Chi dovrebbe vedere la nuova schermata di amministrazione che stiamo lanciando e quando?
- Quale livello di iscrizione è richiesto per sbloccare questo uovo di Pasqua?
- Quando dovremmo passare al nuovo database?
- Dovremmo mettere la foto di un ghepardo o di un'aquila sul pulsante di pagamento per migliorare le conversioni?
Per avere un'applicazione che rimanda un numero significativo di tali decisioni fino al runtime, non è possibile lanciare flag di funzionalità nell'applicazione in modo ad hoc o ti seppellirai in un debito tecnico. Oggigiorno è necessario disporre di una strategia di gestione dei flag di funzionalità completa, che includa alcuni componenti diversi.
- I punti di commutazione vengono utilizzati per cambiare il comportamento per le nuove funzionalità.
- Più punti di commutazione si uniscono per formare un router di commutazione . Un toggle router determina lo stato di una funzionalità.
- Toggle context fornisce al toggle router le informazioni contestuali necessarie (ad esempio, utente specifico).
- Attiva / disattiva configurazione fornisce le informazioni di attivazione / disattivazione del router sull'ambiente.
Quindi, alla fine, cosa sono i flag di funzionalità?
Bene, sono una parte importante di una strategia più ampia per avere un'applicazione adattabile alle esigenze sia tecniche che di mercato.