Vue.js vs React.js : quel Framework pour son projet ?

Comparaison entre Vue.js et React.js, deux géants du développement web. Performance, apprentissage, modularité : quel Framework pour votre projet ?

À l'ère du développement web, choisir le bon Framework frontend peut définir le succès de votre projet. Aujourd'hui, plongeons dans le débat Vue.js vs React.js. Quel géant du JavaScript convient le mieux à votre vision ? C'est la question à laquelle nous répondrons dans cette comparaison détaillée. Explorez les fondamentaux, découvrez les différences clés, et faites un choix éclairé pour votre prochaine aventure digitale.

Les fondamentaux de Vue.js et React.js

Entamons notre exploration en mettant en lumière les caractéristiques distinctives de Vue.js et React.js, deux incontournables du développement JavaScript.

Vue.js : une approche progressive

Vue.js se démarque par son approche incrémentielle. Son système de composants facilite l'intégration avec des projets existants, offrant une simplicité appréciée. L'outil Vue CLI permet un démarrage rapide, un atout pour les projets de toutes envergures.

La partie écrite en HTML propose une balise div avec l'id app, qui est la zone d'application que Vue.js cible.

À l'intérieur de cette balise, nous avons un bouton avec un événement @click qui déclenche la méthode showMessage() lorsque le bouton est cliqué. Le paragraphe avec la directive v-if  s'affiche uniquement lorsque la propriété messageVisible est true.

Enfin, la partie script JavaScript est écrite en Vue.js. Elle créée une nouvelle instance de Vue avec les données et les méthodes nécessaires. Lorsque le bouton est cliqué, la méthode showMessage() est appelée pour rendre le message visible.

En résumé, ce code Vue.js crée une application basique avec un bouton qui, une fois cliqué, fait apparaître un message dans un paragraphe. La logique de rendu conditionnel est gérée par les propriétés réactives de Vue.js (messageVisible, dans ce cas).

React.js : la puissance du Virtual DOM

React.js brille avec le concept de Virtual DOM, améliorant significativement les performances. Sa flexibilité s'étend au-delà des applications web, permettant le développement d'applications mobiles avec React Native. Create React App offre, quant à lui, une entrée en matière rapide pour les nouveaux projets.

Une image contenant texte, capture d’écran, logiciel, ordinateurDescription générée automatiquement

Dans cet exemple, nous utilisons la fonction useState() de React pour déclarer et initialiser l'état du composant fonction App. Sa syntaxe est simplifiée grâce à l'utilisation d’une fonction fléchée.

Pour des projets réels, il serait préférable d'utiliser des outils comme Create React App ou Nextjs pour une configuration plus complète et une structure de dossier organisée.

Comparaison directe

Plongeons maintenant dans une analyse détaillée des différences clés entre Vue.js et React.js, mettant en lumière les points qui pourraient orienter votre choix.

Performance et DOM virtuel

En matière de performances, Vue.js excelle avec son système de rendu réactif. React.js, quant à lui, mise sur la puissance du Virtual DOM pour des applications fluides et réactives. Un point crucial à considérer selon les exigences de votre projet.

Facilité d'apprentissage et courbe d'apprentissage

Vue.js se distingue par sa courbe d'apprentissage douce, idéale pour les débutants. À l'inverse, React.js offre une courbe d'apprentissage plus prononcée, mais son écosystème robuste attire les développeurs expérimentés. Un choix à faire en fonction de votre équipe et de vos délais.

Composants et modularité

Vue.js brille avec son système de composants intuitif, favorisant la réutilisabilité. React.js propose également une approche modulaire, mais dans un écosystème plus vaste. Choisissez en fonction de la complexité de votre application et de vos besoins en modularité.

Choisir en fonction de vos besoins

Maintenant que nous avons disséqué les différences, concentrons-nous sur la prise de décision. Comment choisir entre Vue.js et React.js en fonction de vos besoins spécifiques ? C'est ce que nous allons explorer dans cette section.

Vue.js excelle dans le développement d'applications web, offrant simplicité et efficacité. À l'inverse, React.js élargit son spectre en permettant également le développement d'applications mobiles grâce à React Native. La nature de votre projet guidera ce choix crucial.

Vue.js se distingue par sa simplicité d'intégration avec HTML et CSS, facilitant la transition pour les développeurs. React.js adopte une approche JSX, plus proche du JavaScript pur. La préférence pour l'une ou l'autre dépendra de votre équipe et de vos préférences de codage.

Communautés actives et support

Entrons maintenant dans le monde des communautés, un aspect essentiel pour le succès continu d'un Framework. Voyons comment Vue.js et React.js se positionnent en termes de soutien et de ressources.

La communauté Vue.js connaît une croissance significative. Des forums actifs, des tutoriels, et un soutien en ligne abondant font de Vue.js une option attrayante pour ceux qui apprécient une communauté en pleine expansion.

Vue.js dispose d'un forum officiel où les développeurs de tous niveaux peuvent poser des questions, partager leurs expériences et discuter des meilleures pratiques. La communauté est connue pour être accueillante et réactive.

Les meetups et les conférences dédiés à Vue.js sont organisés régulièrement dans le monde entier. Ils offrent une excellente occasion de rencontrer d'autres développeurs, de partager des idées et d'en apprendre davantage sur les nouvelles fonctionnalités et les meilleures pratiques.

La documentation officielle de Vue.js est très complète et bien organisée. Elle propose des guides, des exemples concrets et une référence exhaustive pour aider les développeurs à comprendre et à utiliser Vue.js de manière efficace.

Vue Mastery propose des cours en ligne avancés pour les développeurs Vue.js de tous niveaux. Ces cours couvrent une variété de sujets, de l'apprentissage des bases à des sujets avancés tels que la gestion d'état avancée.

React.js, avec l'une des plus grandes communautés, offre une richesse de ressources et de forums de discussion. La stabilité et la maturité de la communauté React.js en font un choix rassurant pour ceux qui recherchent une base solide de soutien.

Le répertoire GitHub de React est un centre actif de collaboration. Les développeurs peuvent signaler des problèmes, proposer des fonctionnalités, et contribuer directement au développement du Framework.

Reactiflux est une communauté React sur Discord où les développeurs peuvent discuter en temps réel, poser des questions et partager leurs expériences.

La documentation officielle de React est exhaustive et mise à jour régulièrement. Elle couvre tout, de l'installation à des sujets avancés tels que les Hooks, les Context API, et la gestion d'état.

La communauté React est très active sur Stack Overflow. Les développeurs peuvent poser des questions et obtenir des réponses rapides de la part de la communauté.

Nos conseils pour optimiser votre choix

Nous arrivons à la phase cruciale de la prise de décision. Comment optimiser votre choix entre Vue.js et React.js ? Découvrons des conseils pratiques pour guider cette étape.

Vue.js se démarque par son accent sur une expérience utilisateur fluide. Ses fonctionnalités réactives et sa simplicité d'utilisation en font un choix idéal pour des applications offrant une expérience utilisateur exceptionnelle.

Quel que soit le choix, misez sur la qualité. Évitez des refontes coûteuses en privilégiant la qualité dès le début. Des applications bien conçues offrent une base solide pour le succès à long terme, que vous optiez pour Vue.js ou React.js.

En fin de compte, le choix entre Vue.js et React.js est personnel, dépendant de vos besoins spécifiques, de la nature de votre projet, et de vos préférences. Dans la prochaine section, rappelons l'essentiel de cette comparaison et offrons une vision claire pour vous aider à faire le choix éclairé qui propulsera votre projet vers le succès.

En conclusion, le choix entre Vue.js et React.js est une décision cruciale, dépendante de la nature unique de votre projet. Que vous soyez séduit par l'approche progressive de Vue.js ou par la puissance du Virtual DOM de React.js, l'essentiel est de faire un choix éclairé.

À travers cette comparaison, nous avons exploré les fondamentaux, examiné les différences clés, et offert des conseils pratiques pour guider votre décision.

N'oubliez pas : la clé du succès réside souvent dans la simplicité. Optez pour le Framework qui s'aligne le mieux avec vos besoins, tout en privilégiant la qualité dès le départ. Que vous choisissiez Vue.js ou React.js, transformons ensemble votre vision en une réalité digitale.

Si des questions persistent ou si vous avez besoin d'un accompagnement plus approfondi, n'hésitez pas à nous contacter. Chez Yield Studio, nous sommes là pour concrétiser vos projets avec expertise et engagement.

Sommaire
Nos autres catégories
Partager sur :
Nos autres catégories
Partager sur :

Ne manquez rien
Abonnez-vous à notre newsletter

Notre newsletter tous les mois :
Je m'abonne
Merci ! C'est dans la boîte :)
Oops! Something went wrong while submitting the form.

Nos experts vous parlent
Le décodeur

Hard Delete vs Soft Delete : que choisir ?
23/1/2024

Dans le domaine de la gestion des données, le choix entre Hard Delete et Soft Delete peut avoir un impact significatif sur la sécurité et la récupération des informations. Ces deux méthodes de suppression de données sont essentielles pour les développeurs et les administrateurs de bases de données.

Dans cet article, nous explorerons en détail ce qu'est le Hard Delete et le Soft Delete, leurs avantages respectifs, et comment choisir la meilleure approche en fonction des besoins spécifiques de votre projet. Nous fournirons également des exemples de code source pour illustrer leur mise en œuvre, afin que même les novices puissent comprendre ces concepts fondamentaux.

Comprendre la différence entre Hard Delete et Soft Delete

La gestion des données supprimées est une composante cruciale de toute application ou système de gestion de bases de données. Comprendre les distinctions entre le Hard Delete et le Soft Delete est le point de départ pour prendre des décisions éclairées.

Hard Delete : La Suppression Définitive (h3)

  • Le Hard Delete, également connu sous le nom de suppression définitive, signifie que les données supprimées sont éliminées de manière permanente de la base de données.
  • Cela signifie qu'une fois que vous avez effectué un Hard Delete, les données sont irrécupérables.
  • Exemples de scénarios où le Hard Delete est approprié : suppression de données sensibles ou obsolètes, respect de la conformité légale.

Soft Delete : La suppression réversible

  • Le Soft Delete, contrairement au Hard Delete, implique une suppression réversible.
  • Les données supprimées sont marquées comme "supprimées" mais restent dans la base de données.
  • Cela permet la récupération des données supprimées si nécessaire, offrant une couche de sécurité supplémentaire.
  • Utilisation courante du Soft Delete : préservation de l'historique des données, récupération en cas d'erreur de suppression.

En comprenant la différence fondamentale entre le Hard Delete et le Soft Delete, vous pouvez commencer à évaluer quelle méthode convient le mieux à votre projet. La prochaine section examinera les avantages de chacune de ces méthodes pour vous aider à prendre une décision éclairée.

Les avantages du Hard Delete

Le Hard Delete est une méthode de suppression de données qui peut s'avérer essentielle dans certaines situations. Examinons de plus près les avantages qu'il offre :

L'un des principaux avantages du Hard Delete réside dans la sécurité qu'il offre. Lorsque vous effectuez un Hard Delete, les données sont supprimées de manière permanente de la base de données.

Cela garantit qu'aucune trace des données supprimées ne subsiste, réduisant ainsi le risque de divulgation d'informations sensibles.

Dans certains secteurs, comme la santé ou les finances, la conformité légale est cruciale. Le Hard Delete permet de répondre à ces exigences en supprimant irrévocablement les données.

En supprimant définitivement les données, le Hard Delete peut contribuer à améliorer les performances de la base de données en libérant de l'espace et en réduisant la charge de travail du système.

Le Hard Delete simplifie la gestion des données, car il n'est pas nécessaire de gérer un ensemble de données supprimées de manière réversible. Cela peut simplifier les processus de sauvegarde et de restauration.

Pour mieux comprendre la mise en œuvre du Hard Delete, voici un exemple de code SQL montrant comment effectuer une suppression permanente dans une base de données :

Une image contenant texte, capture d’écran, Police, GraphiqueDescription générée automatiquement

Les avantages du Soft Delete

Le Soft Delete, bien que différent du Hard Delete, présente des avantages significatifs dans certaines situations. Examinons en détail les avantages qu'il offre !

L'un des principaux avantages du Soft Delete est la capacité à récupérer des données supprimées par erreur. Les données marquées comme "supprimées" restent dans la base de données et peuvent être restaurées si nécessaire.

Le Soft Delete permet de conserver un historique complet des données, y compris celles qui ont été supprimées. Cela peut être utile pour l'audit, la conformité ou l'analyse des tendances historiques.

En évitant la suppression permanente des données, le Soft Delete offre une couche de protection contre les erreurs humaines, telles que la suppression accidentelle de données critiques.

Lors de la mise en œuvre de nouvelles fonctionnalités ou de modifications de la structure de la base de données, le Soft Delete permet une transition en douceur en conservant les données existantes.

Pour mieux comprendre la mise en œuvre du Soft Delete, voici un exemple de code SQL montrant comment marquer une ligne de données comme "supprimée" sans la supprimer définitivement :

Une image contenant texte, capture d’écran, Police, GraphiqueDescription générée automatiquement

Quand utiliser chacune des méthodes

La décision entre Hard Delete et Soft Delete dépend largement des exigences particulières de votre projet. Voici des conseils pour vous aider à faire le choix approprié :

Choisissez le Hard Delete lorsque la sécurité des données est une priorité absolue. Par exemple, dans les applications de santé ou financières, il est préférable d'opter pour une suppression définitive.

Si la récupération des données supprimées est essentielle, le Soft Delete est la meilleure option. Cela s'applique notamment aux systèmes où les erreurs de suppression peuvent se produire.

Pour respecter les réglementations strictes qui exigent la suppression permanente de données, le choix du Hard Delete est nécessaire.

Si vous avez besoin de conserver un historique complet des données, optez pour le Soft Delete. Cela est particulièrement utile pour l'audit et la conformité.

Si vous souhaitez optimiser la performance de la base de données en réduisant la charge, le Hard Delete peut être plus approprié, car il libère de l'espace.

Envisagez le Soft Delete lorsque vous prévoyez d'introduire de nouvelles fonctionnalités ou des changements structurels dans la base de données, car il permet une transition en douceur.

En évaluant soigneusement les besoins de votre projet en fonction de ces critères, vous pourrez prendre une décision éclairée quant à l'utilisation du Hard Delete ou du Soft Delete. Gardez à l'esprit que dans certains cas, une combinaison des deux méthodes peut également être envisagée pour répondre aux besoins spécifiques de votre application.

Le choix entre Hard Delete et Soft Delete est une décision cruciale dans la gestion des données. Chacune de ces méthodes présente des avantages distincts, et le choix dépend des besoins spécifiques de votre projet.

Le Hard Delete offre une sécurité maximale en supprimant définitivement les données, ce qui le rend idéal pour les applications où la confidentialité et la conformité légale sont essentielles. Cependant, il faut être prudent, car les données sont irrécupérables.

Le Soft Delete, quant à lui, permet la récupération des données supprimées, préservant ainsi un historique complet et offrant une protection contre les erreurs humaines. Il est particulièrement adapté aux systèmes où la récupération des données est une priorité.

Le choix entre ces deux méthodes peut également dépendre des contraintes de performance de votre base de données et de la flexibilité nécessaire pour les futures modifications.

En fin de compte, il n'y a pas de réponse universelle. Il est essentiel d'évaluer les besoins de votre projet et de choisir la méthode qui répond le mieux à ces exigences spécifiques. Dans certains cas, une combinaison des deux méthodes peut également être envisagée pour une gestion des données supprimées plus complète.

Quelle que soit la méthode choisie, la gestion des données supprimées est une composante essentielle de tout système de base de données bien conçu. En comprenant les avantages du Hard Delete et du Soft Delete, vous êtes mieux préparé à prendre des décisions éclairées pour garantir la sécurité et la flexibilité de votre application.

N'hésitez pas à partager vos propres expériences et réflexions sur ce sujet dans les commentaires ci-dessous. La gestion des données supprimées est une discipline en constante évolution, et l'échange d'idées peut bénéficier à l'ensemble de la communauté de développement.

Git : initiation, merge vs rebase, démo
22/6/2023

Origine

Git a été inventé et développé par Linus Torvalds en 2005. Il s’agit un logiciel libre et gratuit permettant aux développeurs de gérer les changements apportés au code au fil du temps. Linus Torvalds c’est aussi le petit génie qui est à l’origine du noyau Linux qu’il a commencé en 1991, donc bien avant Git.

Linux c’est un projet plutôt conséquent et il a donc dû nécessiter l’usage d’un outil de gestion de version. Cet outil, à l’époque, c’est BitKeeper. Le problème de BitKeeper, c’est qu’il s’agit d’un logiciel propriétaire et que toute la communauté qui gravite autour de Linux, elle n’aime pas vraiment les logiciels propriétaires. Alors que BitKeeper n’est déjà pas totalement apprécié par la communauté Linux, ils vont faire une annonce qui va déclencher la colère de toute cette communauté et surtout de Linus Torvalds. Ils vont cesser, du jour au lendemain, d’être gratuit. C’est à ce moment précis que Linus Torvalds décide de développer lui même son propre système de gestion de version du code source et tout comme Linux, ce système sera libre et gratuit.

Système de contrôle de version (VCS)

Git est donc un système de contrôle de version, il permet tout simplement de suivre l’évolution du code au fil du temps, à l’aide de branche, de fichiers et d’opérations sur ces fichiers.

Git est structuré comme suit :

  • on y retrouve des fichiers (le code source)
  • des branches (correspondant à une arborescence de fichiers)
  • et des opérations pour faire évoluer les fichiers dans les branches

Grâce à ces opérations, git permet de savoir qui a touché à quel fichier, à quel moment et comment.

GitHub, GitLab, Bitbucket, etc.

Git est un logiciel qui permet de sauvegarder et de gérer localement l’évolution du code source au fil du temps. GitHub, GitLab, Bitbucket, etc. sont des plateformes (web) qui se servent du logiciel git pour gérer le code source. Les dépôts ne sont alors plus gérer localement mais sur des serveurs distants et permettent donc notamment la collaboration avec plusieurs personnes. Ces plateformes proposent également de nombreuses fonctionnalités de gestion de projets et d’équipes (wiki, affectations de tâches, suivi des problèmes, roadmap, statistiques, etc.).

Les bases

Git Flow

Git Flow est une organisation de travail basé sur la capacité de Git à gérer des branches. Par défaut il existe une branche principale qui s’appelle main (anecdote : anciennement master, ce nom par défaut a changé pour des raisons culturelles, ne plus assimiler la notion de master/slave à l’industrie du développement face aux nombreux cas de racisme dans le monde). Il existe une deuxième branche que nous allons créer et qui sera également considérée comme principale, il s’agit de la branche develop.

Nous avons donc 2 branches principales :

  • main (anciennement master), qui représente le code source utilisé sur la production
  • develop, qui contient les dernières fonctionnalités dont la phase de développement est terminée

Tout au long du développement du projet, de nombreuses branches seront créées lors du développement des fonctionnalités et des corrections diverses. Ces branches respecteront des conventions de nommages comme suit :

  • feature/*, pour les branches de fonctionnalités
  • hotfix/* ou bugfix/*, pour les branches de corrections
  • refactor/*, pour améliorer la qualité du code

Conventional Commits

Conventional Commits est une spécification dont le but est d’améliorer la lisibilité des commits et l’historique des modifications du code source. À l’aide de ces conventions on peut identifier immédiatement le type, le contexte et l’objectif des modifications apportées au code sur un commit (nota bene : Cela permet aussi d’être compris par des outils automatisé pour générer de la documentation en autres).

Format Conventional Commits

Les types de commits les plus utilisés sont :

  • feat, développement d’une feature
  • fix, correction d’un bug
  • refactor, amélioration du code
  • test, ajout ou mise à jour de tests
  • chore, tâche technique non assimilée à une feature
  • remove, revert, style, ci, docs, etc.
Exemples de commits suivant la convention

Workflow : merge vs rebase

Avec Git Flow on travaille donc sur des branches partant de develop (ou autre) et une fois le travail terminé on met à jour develop pour qu’il ai connaissance des modifications apportées.

Il existe plusieurs façons de ramener les modifications d’une branche vers une autre. On peut utiliser la politique de merge ou bien la politique de rebase. Ces deux méthodes ont des avantages et des inconvénients.

Politique de merge

Lorsque le travail de développement est terminé sur une branche (de feature, de refactor, etc.), la branche contient un certain nombre d’opération qui n’existent pas sur la branche d’origine. Le principe de la politique de merge est simple : récupérer les modifications faites sur une branche et les ramener sur une autre branche qui n’a pas connaissance de ces modifications. Ces modifications sont ramenées telles quelles.

Avantages :

  • traçabilité totale, l’historique du code source correspond totalement à ce qui a été fait
  • résolution des conflits en une seule fois (peut être un inconvénient dans certains cas)

Inconvénients :

  • historique du code source vite pollué par des opérations inutiles “wip” ou des opérations qui s’annulent
  • historique peu fiable et difficile à debugger
  • résolution des conflits en une seule fois (peut être un avantage dans certains cas)

Politique de rebase

Lorsque le travail de développement est terminé sur une branche (de feature, de refactor, etc.), la branche a donc un certain nombre d’opération qui diverge de la branche principale. Lorsqu’on suit une politique de rebase, notre objectif va être de nettoyer ces opérations en les réécrivant jusqu’à avoir le nombre minimum d’opérations pertinentes.  

Avantages :

  • historique du code source linéaire et lisible qui peut servir de documentation
  • messages de commit clairs et respectant les conventions, plus de “wip”
  • plus de commits qui s’annulent et donc une fiabilité de l’historique
  • facilité pour revenir en arrière et trouver l’origin d’un bug car l’historique n’est pas pollué
  • facilité pour revoir une feature complète, pour la modifier ou l’annuler
  • résolution des conflits opération par opération (peut être un inconvénient dans certains cas)

Inconvénients :

  • demande une grande rigueur car on réécrit en permanence l’historique
  • demande une bonne communication ou des règles précises si on travaille en équipe sur la même branche
  • la réduction d’une nombre d’opération au minimum est parfois trop extrême et atténue la clarté du contexte dans certains cas
  • résolution des conflits opération par opération (peut être un avantage dans certains cas)

Nettoyage avec rebase Interactif

Avec la politique de rebase on réécrit l’historique des opérations faites sur le code source. Pour cela on peut utiliser des outils comme GitKraken ou autre, mais on peut également utiliser la commande git rebase interactive.

Les rebases réécrivent l’historique et donc écrasent totalement ce qui existait avant. En équipe il est donc indispensable de bien communiquer, de bien se mettre à jour et de prendre le soin de ne pas travailler sur la même branche. Si ces règles ne sont pas respecter, les pertes de code sont plus que probables !

Le processus classique de développement pour ne pas rencontrer de problèmes et profiter de la puissance du rebase est le suivant (en plus  :

  • travailler en local en faisant autant d’opérations que nécessaires
  • lorsque le travail est terminé et que tout fonctionne comme il faut, créer une pull request et demander une revue de code en gardant l’historique de code tel qu’il est pour garder du contexte et donner à l’auteur de la revue de code un moyen de comprendre le cheminement de pensé qui a amené à ces modifications
  • une fois la revue de code terminée et acceptée, il faut utiliser le rebase interactive pour nettoyer le code et ne garder que les opérations nécessaires
  • intégrer les modifications sur la branche d’origine et supprimer la branche créée précédemment

🧑💻 Démonstration

Supposons nous avons un dépôt git avec une seule branche main et un seul fichier hello.ts qui contient une fonction “Hello World !” comme suit :

Maintenant, nous devons développer la fonctionnalité “Good Bye World!”.

Pour cela, nous allons donc commencer par créer une branche qui respecte les conventions de nommage : git checkout -b feature/good-bye
Puis, nous allons créer un fichier good-bye.ts et écrire la fonction suivante :

Et nous allons créer un commit contenant cette fonctionnalité : git commit -m “feat: good bye world”.

Vous l’avez peut-être remarqué, une erreur s’est glissée dans la fonction, nous allons donc faire un commit pour la corriger :

Avec le commit suivant : git commit -m “fix(good-bye): typo”.

Nous avons donc 2 commits alors qu’il serait plus pertinent d’en avoir qu’un seul. Nous allons donc utiliser le git rebase interactive pour réécrire l’historique des modifications.

Pour initialiser le rebase interactive on utilise la commande suivante : git rebase interactive HEAD~2

Cette commande va ouvrir l’interface suivante :

Sur cette interface on voit les 2 derniers commits de mon dépôt git (parce qu’on a utilisé HEAD~2). On y retrouve également une documentation des commandes qu’on peut utiliser devant l’identifiant de chaque commit.

Dans notre cas, on veut fusionner les modifications du deuxième commit avec le premier commit. C’est donc la commande fixup qui nous intéresse, nous allons donc remplacer pick devant le commit fix(good-bye): typo par fixup.

On enregistre et on obtient l’historique suivant (un seul commit) :

7f077f4 (HEAD -> feature/good-bye-world) feat: good bye world

Liens utiles

DORA Metrics : utiliser la technologie pour piloter la valeur du business
11/4/2023

Les métriques DORA sont devenues incontournables pour évaluer et améliorer la performance des équipes DevOps. Ces indicateurs clés permettent de mesurer la rapidité, la stabilité et l'efficacité du processus de développement et de déploiement logiciel.

Dans cet article, nous analyserons en profondeur ces métriques, leurs implications pour les équipes techniques, et comment les implémenter efficacement. Que vous soyez CTO, membre de la DSI ou développeur, comprendre et utiliser les métriques DORA est essentiel pour optimiser vos opérations et garantir la livraison continue de valeur à vos utilisateurs finaux.

Voici un exemple de projet pour lequel nous suivons les DORA Metrics chez Yield Studio :

Pour qui ?

Avant d’attaquer le sujet concrètement, commençons par définir la cible de ces métriques.

Contre toute attente, elles sont transverses. Moyennant une bonne application, les métriques peuvent être consultées par la DSI , le CTO ou le management top level mais elles sont belles et bien pilotées par les équipes techniques. Ces métriques sont également essentielles pour les équipes DevOps qui cherchent à améliorer leur collaboration et leur performance globale.

Pourquoi ?

Assez simplement ce sont des métriques, des KPI, des nombres qui portent plus ou moins de contexte et permettent de quantifier la performance des équipes techniques (software team). Bien souvent, la littérature retient 4 métriques au total bien qu’il en existe une 5ème qu’on évoquera rapidement mais qu’on exclura par la suite.

Elles fournissent des informations précieuses sur la rapidité avec laquelle les équipes DevOps peuvent répondre aux changements, le temps moyen pour déployer du code, la fréquence des itérations et les échecs.

Ces indicateurs sont cruciaux pour :

  • Fournir des estimations de réponse réalistes
  • Améliorer la planification du travail
  • Identifier les domaines à améliorer
  • Consolider les investissements techniques et en ressources

Les 4 Principales Métriques DORA

  1. DF (Deployment Frequency)

    Il s’agit de la fréquence à laquelle du code est déployé en production sur une période de temps. Précisions tout de même que le code doit être déployé avec succès. S’il faut rollback chaque déploiement ça compte pas.
    C’est également un indicateur de fréquence à laquelle les ingénieurs délivrent de la valeur aux utilisateurs finaux.

    Plus elle est élevée et plus les utilisateurs profitent vite des incréments de code.

    A titre indicatif, une valeur moyenne est de 1 déploiement par semaine.

  2. MLTC (Mean Lead Time for Changes)

    Il s’agit du temps moyen entre le premier commit et le déploiement en production.
    Souvent les développeurs doivent repasser plusieurs fois sur le code produit initialement suite notamment à la re-lecture par d’autre développeurs ou pour apporter des corrections demandées par le product owner.

    Dans un autre domaine, cette métrique correspond au temps d’immobilisation (stock).

    A titre indicatif, une valeur moyenne est de 1 semaine.

  3. CFR (Change Failure Rate)

    Il s’agit du pourcentage de déploiements en production qui causent un problème.

    On le calcule en divisant le nombre d’incident par le nombre de déploiements.

    A titre indicatif, une valeur moyenne se situe entre 16 et 30%.

  4. MTTR (Mean Time To Recovery)

    Il s’agit du temps moyen nécessaire pour réparer un problème et remettre le système dans un état stable.

    A titre indicatif, une valeur moyenne se situe à moins d’un jour.

Une Cinquième Métrique : La Fiabilité

aSouvent oubliée, cette métrique est plus orientée DevOps/SRE et se base sur des objectifs opérationnels/contractuels (SLA). Elle mesure la capacité à atteindre ou dépasser ces objectifs, fournissant une perspective supplémentaire sur la performance opérationnelle.

Comment mettre en place ces métriques ?

Il existe plusieurs approches pour mettre en places ces métriques. La plus simple reste de s’appuyer sur un outil qui les intègre déjà, comme LinearB.

Source: LinearB https://linearb.helpdocs.io/article/7ck7fu67am-metrics-dashboards-dora-metrics

Qu’importe le flacon l’outil, pourvu que vous commenciez à mesurer.

Et si cela ne marche pas dans mon cas  ?

“Oui mais moi ma feature est complexe, il me faut plusieurs semaines pour terminer, je vais biaiser la moyenne gneu gneu gneu …”

  • Découpe ta feature et utilise des feature flags pour délivrer de façon incrémentale.

"Oui mais c’est long de tout tester à chaque fois gneu gneu gneu …"

  • Sois flemmard et écris des tests pour automatiser ton job.

TL;DR

Les métriques DORA sont des indicateurs de la production de valeur produit/business.

Elles sont applicables aux DevOps comme aux développeurs et intéressent toute la software team. Pour être pertinentes, les développeurs doivent être acteurs du pilotage de ces métriques car aucun manager ne pourra les forcer à cela.

Une observation macro est que les DORA poussent naturellement à réduire les incréments de code. En effet, en envoyant moins de code à chaque déploiement, on mitige le risque et les déploiements sont naturellement plus rapide.

Notons aussi que les DORA ne se suffisent pas à elle même, elles appellent à d’autre bonnes pratiques que sont le respect du manifeste agile https://agilemanifesto.org/, l’ajout de tests ou encore les principes LEAN de Toyota.

Enfin, avis aux néophytes avides de tableau Excel, si les DORA permettent de quantifier un problème, une lame de fond, elles ne le qualifie pas pour autant. Le sujet central reste un sujet humain, on parle d’équipes d’homme et de femme qui ont leur code, leur cohésion, leur problématique propre. Piloter uniquement les DORA pour présenter un Excel “tout au vert” serait naïf et pourrait compromettre l’équipe ciblée.

Et Yield Studio là dedans ?

Selon la classification mentionnée en annexe Yield Studio se situe en “high performer” et s’améliore en continu pour atteindre prochainement le grade “elite”. Et vous, vous vous situez où dans ce tableau ? Aujourd'hui les DORA Metrics nous permettent de garantir une réelle qualité auprès de nos clients dans les projets qu'ils nous confient.

Source

Valeurs indicatives pour chaque DORA metric

Source: Google Cloud https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance?hl=en

Échangeons sur votre projet !

Développement web
Application mobile
Design & Product
Nous contacter

Simulateur

Bienvenue dans le
simulateur d’estimation

Sélectionnez
vos besoins

Sélectionnez un ou plusieurs choix

Définissez les
fonctionnalités

Sélectionnez un ou plusieurs choix

Dernière
étape !

Renseignez votre adresse mail pour recevoir l’estimation !
Obtenez l’estimation
Précédent
Suivant

Bravo ! Vous avez terminé
l’estimation de votre future app !

Vous recevrez dans votre boite mail l’estimation personnalisé. Une estimation vous offre la possibilité de vous projeter dans un budget, vous permettant ainsi de planifier en toute confiance. Néanmoins, chez Yield, nous adoptons une approche agile, prêts à remettre en question et ajuster nos évaluations en fonction de l'évolution de vos besoins et des spécificités de votre projet.
Retour au site
Oops! Something went wrong while submitting the form.