Quatre feature flags, et le temps qu’ils vivent
Une classification qui n’est pas de moi, et la question qu’elle laisse ouverte : à quelle date le flag disparaît. Faute de réponse écrite, il devient une pièce du produit.
Le signe de ce site est un interrupteur, ce qui m’oblige à une certaine rigueur sur le sujet. Martin Fowler a classé les feature flags (il écrit feature toggles) en quatre familles ; la classification est à lui, et je ne la reprends pas pour l’améliorer, mais parce qu’elle sert à poser la question qu’elle n’aborde qu’au passage, celle de la durée de vie.
- Release flag : il cache du code inachevé dans une version déjà publiée. Il doit mourir à la fin du développement.
- Experiment flag : il envoie deux populations sur deux chemins pour comparer. Il doit mourir avec la mesure, dont la durée se décide d’avance.
- Ops flag : il coupe une fonction coûteuse quand le système souffre. Il vit aussi longtemps que le système.
- Permission flag : il ouvre une fonction à certains comptes. Il vit aussi longtemps que le produit, parce que ce n’est pas un flag : c’est une règle métier.
L’ordre de la liste n’est pas décoratif : elle va de la plus éphémère à la plus permanente. Les deux premières doivent disparaître, les deux dernières sont faites pour rester. Confondre les deux moitiés est l’erreur ordinaire, et elle se commet toujours dans le même sens : on traite un flag temporaire comme s’il était acquis.
Chaque flag double le nombre de chemins possibles dans le code ; deux flags le quadruplent. Le coût n’est pas dans la condition elle-même, trois lignes, mais dans ce qu’on cesse de tester, c’est-à-dire les combinaisons. Un release flag oublié après la livraison laisse derrière elle un chemin que personne n’emprunte, que personne ne teste, et que personne n’ose retirer parce que plus personne ne sait à quoi il servait.
Tout flag des deux premières familles naît avec une date de retrait écrite au même endroit que le code, et non dans un billet de suivi qu’on referme. Passée cette date, il se retire ou se justifie ; il n’y a pas de troisième issue. C’est une contrainte pénible, et c’est la seule que j’aie vue tenir plus d’un trimestre.
Cet article ne dit rien de l’outillage : les services qui pilotent des flags à distance, leurs tableaux de bord, leur facturation. Ils règlent la distribution du réglage, pas sa disparition, et c’est la disparition qui pose problème. Sur un système tenu par une seule personne, un fichier de configuration et une date suffisent, et j’aurais du mal à justifier davantage.