Supposons que vous souhaitiez développer une nouvelle fonctionnalité, mais vous n'êtes pas sûr que les utilisateurs l'aimeront et vous devez avoir un moyen de la masquer sans douleur. Ou supposez que vous travaillez sur une nouvelle fonctionnalité importante et que vous souhaitez éviter les commits de monstres. Ou vous voulez simplement rendre le comportement du site facilement configurable. Comment puis-je résoudre tous ces problèmes, lisez sous le chat.
Le problème
Imaginez que les cycles de développement de votre équipe durent deux semaines, et la mise en œuvre d'une nouvelle fonctionnalité nécessitera 3 mois de développement de la part de l'équipe. À première vue, il existe deux schémas d'action possibles:
- Créez une branche distincte et effectuez tout le travail pendant trois mois, en tirant périodiquement de la branche parente
- Utiliser le concept d'intégration continue ( Continuous Integration ou CI pour faire court ): décomposer la tâche et figer le code en petites portions
Ces deux approches ont leurs avantages et inconvénients évidents:
Utilisation de commutateurs de fonctionnalités pour résoudre des problèmes
Un tel problème se rencontre assez souvent en cours de développement et il existe une solution élégante qui vous permet de tirer le meilleur parti des approches décrites ci-dessus -
basculement ou
changement de fonction .
Essentiellement, un sélecteur de fonctionnalités est un indicateur booléen qui est stocké dans la base de données et contient des informations sur l'activation ou non d'une fonctionnalité. La valeur de cet indicateur peut être récupérée de la base de données par clé. La commodité de l'utilisation des commutateurs de fonctionnalités est qu'ils peuvent être facilement modifiés par un utilisateur professionnel pendant l'exécution via le panneau d'administration sans avoir à redéployer l'application.
Voici un exemple d'utilisation du basculement de fonction en Java:
if (configurationManager.getParameter("is.some.functionality.enabled")) {
Dans l'exemple ci-dessus,
configurationManager est une classe qui vous permet de récupérer la valeur d'un sélecteur de fonctionnalité spécifique de la base de données par sa clé.
En outre, avec l'aide de commutateurs de fonctionnalités, vous pouvez afficher / masquer certains éléments sur le frontend. Pour ce faire, vous devez mettre la valeur de l'indicateur dans Model et la transmettre à View comme indiqué ci-dessous:
@ModelAttribute("isSomeFunctionalityEnabled") public void isSomeFunctionalityEnabled() { return configurationManager.getParameter("is.some.functionality.enabled"); }
Utilisez ensuite la valeur transmise pour rendre tel ou tel code HTML:
<c:choose> <c:when test="${isSomeFunctionalityEnabled}"> <!-- Render some stuff --> </c:when> <c:otherwise> <!-- Render some other stuff --> </c:otherwise> </c:choose>
Types de commutateurs de fonctionnalités
Le concept décrit de l'utilisation de commutateurs de fonctionnalités n'est qu'un cas d'utilisation possible et ces commutateurs de fonctionnalités sont appelés bascules de libération. Au total, 3 types différents de commutateurs de fonctionnalités sont distingués:
- release toggles - vous permet de masquer les fonctionnalités incomplètement implémentées pendant leur développement
- expérience bascule - commutateurs pour les tests A / B
- bascule d'autorisation - interrupteurs marche / arrêt pour divers groupes d'utilisateurs
Ainsi, en utilisant des commutateurs de fonctionnalités, vous pouvez créer deux versions différentes du site sur la même base de code, en utilisant différentes bases de données et différents ensembles de commutateurs de fonctionnalités. Par exemple, sur un site européen, il est logique d'inclure toutes les fonctionnalités liées au RGPD, mais sur un site russe, vous ne pouvez pas le faire.
Problèmes d'utilisation des bascules de fonction
Depuis que je travaille sur un projet où les bascules de fonctionnalités sont activement utilisées, en plus des avantages évidents de les utiliser, j'ai commencé à remarquer des problèmes qui leur sont associés:
- Tester la complexité : lorsqu'une nouvelle version est publiée, les ingénieurs QA testent toutes les fonctionnalités qui y sont incluses et essaient également de les activer et de les désactiver à l'aide de commutateurs de fonctionnalités. Cela nécessite beaucoup de temps supplémentaire, car il est conseillé de tester toutes sortes de combinaisons de drapeaux
- L'apparition d' un code mort : les valeurs de nombreux basculements de fonctionnalités ne changent pas pendant de longues périodes ou ne changent pas du tout, et donc le code écrit pour une valeur d'indicateur différente devient en réalité «mort»
- Pannes de site inattendues : de nombreux commutateurs de fonctionnalités obsolètes ont la malheureuse propriété de casser quelque chose lors de la modification de leur valeur (car personne n'a longtemps vérifié qu'ils fonctionnent). Étant donné que les commutateurs de fonctionnalités sont stockés dans la base de données et peuvent être facilement modifiés par les utilisateurs professionnels à partir du panneau d'administration, des pannes se produisent souvent en raison d'une modification de leur valeur. Les performances des commutateurs de fonctionnalités longtemps inutilisés doivent d'abord être vérifiées dans un environnement de test
Solutions à certains des problèmes décrits
Les actions suivantes peuvent aider à résoudre les problèmes ci-dessus:
- Documentation des commutateurs de fonctionnalités disponibles: afin de comprendre quel effet une bascule de fonctionnalité particulière a et par quelle clé la rechercher dans la base de données, vous devez créer une documentation détaillée avec une description de tous les commutateurs de fonctionnalités.
- Révision périodique des commutateurs de fonctionnalités: pour éviter l'apparition de code mort, supprimez périodiquement les commutateurs de fonctionnalités obsolètes et le code associé
Résumé
Le sélecteur de fonctionnalités est un mécanisme très simple et en même temps puissant qui vous permet d'éviter les commits monstrueux, de modifier facilement les comportements des applications ou d'assembler plusieurs applications différentes sur la même base de code en utilisant différentes configurations de basculement des fonctionnalités.
Cependant, il convient également de se rappeler que ce modèle de développement présente certains inconvénients qui entraînent un code difficile à lire et difficile à maintenir.Par conséquent, une utilisation excessive de ce modèle doit être évitée et documenter périodiquement les commutateurs de fonctionnalités et les révisions pour supprimer ceux qui ne sont pas utilisés et, par conséquent, effacez le projet du code "mort".
Liens utiles