“In locale stampo i log in questo formato e in produzione in quest’altro modo” e qui che mi venuto in mente che praticamente tutti stiamo già usando le feature flag, senza neanche accorgerci.
Da quando hai una variabile che cambia il tipo di ambiente, che sia locale, staging o produzione, e che fa cambiare il comportamento del tuo applicativo, ecco che l’hai già implementato.
Era stato un AHA moment, perché all’inizio mi dicevo: “A volte ho problemi a tenere branch separati con le feature da implementare solo perché devo aspettare che sia tutto pronto (sia codice che per altre persone), ma nello stesso tempo poi avrò dei conflitti…” e avevo sentito e letto della comodità delle feature flag, ma non ero ancora riuscito a implementarle.
Cosi si può anche non avere altri branch per ogni implementazione, perché ogni volta che vogliamo iniziare a implementare qualcosa di nuovo ci basta inserirla disabilitata e continuare il nostro lavoro fino a che ci troviamo con la nuova feature completata e pronta per la produzione.
Qualche contro
Uno dei principali contro di questo approccio è che, se vuoi coprire tutte le casistiche che hai nel codice con le feature flag, se ne lasci troppe, potresti trovarti una moltitudine di test simili.
Per esempio, se una funzione ne avrà una, dovrai fare 2 test, ma se ha già 2 arriverai ad averne 4 di test per coprire tutte le casistiche e così esponenzialmente.
Questo problema è facilmente risolvibile facendo refactoring quando quella feature è stabile e in produzione, quindi che non verrà tolta subito.
Al che si potrò togliere le condizioni che la disabilitano e tenerlo come se fosse stabile.
Uno svantaggio, ma che non è un problema, è che è meno facile vedere la feature nel suo complesso come se fosse stata in un branch separato e, con una merge request, vedere in cambiamenti.
Questo, in sè, non è un grosso problema, che si può ovviare in alcuni modi.
Se si sta vedendo una serie di commit in fila, si può fare la differenza tra il commit.
Ma se voglio sapere a che feature è legata un commit senza vedere il codice?
Qui penso che viene in aiuto il crosslinking che praticamente tutti i sistemi di git platform ( github, gitlab, …) che si hanno.
Per esempio, si può aprire un issue con la feature che si vuole sviluppare e, ogni commit che si sta facendo per essa, si aggiunge nel commento del commit il codice.
Questo ci permette anche si andare a rivedere i passi e scrivere qualche info in più, ma anche a correggere il codice di altre commit e referenziarli.
Quando non ha senso usarlo?
Una delle idee che mi vengono è quando si vuole sperimentare un approccio, facendo anche vedere a qualcun altro che cosa si è fatto, ma senza mandarlo in produzione.
E quindi credo che sia utile aprire una branch, ma nello stesso tempo è importante eliminarla quando non sarà più utile perchè se no poi si lascia una serie di diramazioni che, quando un altra persona prenderà il progetto, userà più risorse mentali per capire la situazione.
Conclusione
A volte la soluzione più comoda per una situazione può produrre altri problemi in contesti diversi.
Se questa modalità è svantaggiosa per un progetto open source in cui le persone che contribuiscono non stanno lavorando tutti i giorni al progetto, in casi come progetti aziendali questa condizione è diversa e ci si ritrova rallentati.
Quindi, come sempre, dipende dall’ambiente in cui ci si trova.