Il flag temporaneo: la feature disattivata che nessuno osa rimuovere

Narratore: Questo episodio usa voci sintetiche. È lunedì mattina. In riunione, il Product Owner chiede di rimuovere un interruttore che dovrebbe disattivare una funzionalità. Nel sistema è presente da così tanto che il team non sa più quale comportamento sia quello normale.

Product Owner: Il cliente vuole semplificare la schermata. Dai dati che abbiamo, la nuova funzionalità sembra già attiva per tutti. La richiesta è: possiamo eliminare il flag? Non riaprire il progetto, proprio eliminare l’interruttore. Io vorrei rispondere sì o no senza convocare una riunione per decidere se serve una riunione.

Senior Developer: L’ho aggiunto io durante un rilascio urgente. Serviva poter tornare indietro senza fare un nuovo deploy. Era una soluzione temporanea, nel senso tecnico del termine: funzionava subito e non aveva una data di rimozione. Nessuno l’ha stabilita. Poi le due varianti nel codice sono cambiate, entrambe. Adesso non saprei indicare quale sia la copia e quale l’originale.

Junior Developer: Chi usa ancora la versione precedente? E dove è documentata la differenza? Ho cercato la configurazione e il flag viene impostato in più punti. Non capisco quale valore prevalga. Inoltre, nella schermata di amministrazione vedo uno stato, ma il comportamento effettivo sembra un altro. Quindi, prima di togliere l’interruttore, dobbiamo capire quale interruttore stiamo guardando?

Product Owner: Per la schermata posso chiedere che mostri il comportamento effettivo. Ma non vorrei trasformare una richiesta semplice in una promessa che non sappiamo mantenere.

Junior Developer: Quindi la schermata non è necessariamente sbagliata: mostra un valore, ma non tutta la decisione. Per capire cosa vede il cliente dobbiamo verificare il comportamento, non solo il flag.

Senior Developer: Esatto. Il valore è vero. È solo una verità parziale, che in un’interfaccia di amministrazione fa sempre un’ottima impressione.

Product Owner: Aspetta: se sembra attiva per tutti, perché la schermata dice altro? Io avevo capito che il flag fosse una scelta semplice. Si mostra o non si mostra. Non sto chiedendo di rifare la funzionalità; vorrei solo che la schermata non presentasse una decisione che, a quanto pare, prende già il sistema da solo.

Senior Developer: La schermata mostra il valore salvato lì. Il sistema controlla anche altri punti. All’epoca ci serviva un modo rapido per riattivare il comportamento vecchio, non una descrizione completa di tutte le decisioni. Non era elegante. Era disponibile prima del rilascio, che in quella settimana era già una qualità architetturale.

Junior Developer: Allora documentiamo i punti in cui viene impostato e confrontiamo lo stato con quello che succede davvero. Se nessuno usa la versione precedente, potremmo spegnerla. Però chi può confermarlo? E quando diciamo che il flag è temporaneo, dove mettiamo la data in cui smette di esserlo? Perché al momento la risposta sembra essere: da parecchio.

Software Architect: Il problema non è soltanto questo interruttore. È che trattiamo i flag come dettagli locali, mentre governano comportamenti diversi. Potremmo gestirli come configurazioni, con un proprietario e una scadenza, e rendere visibili i punti che li impostano. Così la decisione di rimuoverli avrebbe un responsabile e una verifica. È una regola semplice, almeno finché non dobbiamo applicarla al sistema che abbiamo già.

Product Owner: Se assegniamo proprietari e scadenze, per questo flag chi decide che la verifica è conclusa? Vorrei evitare che la data diventi un altro campo compilato per poter salvare.

Junior Developer: Potremmo collegare la scadenza a una decisione verificabile: confrontiamo i risultati, poi qualcuno conferma che il comportamento vecchio non serve più. Altrimenti abbiamo soltanto una data.

Software Architect: Sì. La configurazione dovrebbe rendere visibili anche la verifica richiesta e chi ne risponde. Per questo caso, però, prima dobbiamo capire quali punti impostano il flag.

Product Owner: Mi sembra sensato. Però per togliere un interruttore dobbiamo prima trovare gli altri, assegnare un proprietario e stabilire una scadenza. Posso dire al cliente che la schermata si semplifica. Per la rimozione, invece, devo dire che stiamo avviando una gestione delle configurazioni. È corretto? Perché da fuori sembrava una casella da togliere.

Senior Developer: Prima facciamo la verifica su questo. Se troviamo anche gli altri flag, almeno sapremo che esistono. Non prometterei altro. Ho già visto soluzioni temporanee diventare la mappa del sistema. Questa, almeno, ha una schermata. Anche se la schermata racconta una parte della storia e con una certa sicurezza.

Junior Developer: Ho confrontato i comportamenti. Possiamo disattivare quello più vecchio, ma non cancellare ancora il flag: ci serve per confrontare i risultati. Quindi non è più un interruttore per tornare indietro. È un interruttore per verificare che possiamo averlo tolto. La differenza è chiara. Anche se, da qui, il flag continua a essere acceso.

Senior Developer: È un progresso: prima il flag serviva a tornare indietro, adesso serve a controllare se possiamo andare avanti. Non lo chiamerei ancora rimozione.

Software Architect: La misurazione ci dà un criterio per decidere. Se lo registriamo insieme alla scadenza, almeno la prossima verifica non dovrà ricostruire da capo perché questo interruttore esiste.

Product Owner: Va bene: aggiorno la richiesta. Semplificazione della schermata completata; rimozione del flag pianificata dopo la misurazione. Così il cliente ha una risposta e noi abbiamo una scadenza. Devo solo capire chi è il proprietario della misurazione. Immagino sia il flag, finché non ne troviamo uno più adatto.

Narratore: Dopo la verifica, il team disattiva il comportamento più vecchio senza cancellare il flag. Serve ancora per confrontare i risultati. La richiesta viene aggiornata: semplificazione completata, rimozione pianificata dopo la misurazione. Per ora, l’interruttore resta al suo posto. Ma con un proprietario e una scadenza, almeno in prospettiva.