‍

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).

‍

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.

‍

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

• https://wikipedia.org/wiki/Linus_Torvalds
• https://wikipedia.org/wiki/BitKeeper
• https://wikipedia.org/wiki/Git
• https://git-scm.com/book/
• https://nvie.com/posts/a-successful-git-branching-model/
• https://www.conventionalcommits.org/en/v1.0.0/
• https://ray.so
• https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase

‍

Bienvenue dans le monde fascinant de Laravel, le framework PHP qui a révolutionné le développement web avec sa simplicité, son élégance et sa puissance. Que vous soyez un développeur chevronné ou simplement curieux de découvrir comment les applications web modernes sont construites, Laravel est un outil incontournable qui facilite la réalisation de projets complexes grâce à ses fonctionnalités avancées et son code élégant.

‍

Dans cet article, nous allons plonger dans cinq exemples d'applications web exceptionnelles développées avec Laravel, qui illustrent parfaitement la polyvalence et l'efficacité de ce framework. De la préparation aux tests linguistiques avec GlobalExam à l’apprentissage de la conduite avec Ornikar, en passant par la formation logicielle via Lemon Learning ou encore le recrutement en ligne avec HelloWork, préparez-vous à être inspiré par la créativité et l'innovation que Laravel rend possible. Suivez-nous dans ce voyage à la découverte des meilleures applications Laravel et voyez par vous-même pourquoi ce framework est tant plébiscité dans le monde du développement web.

‍

1. GlobalExam : Optimiser la préparation aux tests de langues

GlobalExam est une plateforme innovante qui permet aux utilisateurs de se préparer efficacement à divers tests de langues officiels tels que le TOEFL, le TOEIC, et le DELF. Utilisant Laravel, GlobalExam offre une interface flexible et robuste pour l'apprentissage en ligne, la gestion de contenu dynamique, et un suivi personnalisé des progrès des utilisateurs.

‍

GlobalExam tire parti de Laravel pour développer une interface utilisateur qui facilite l'interaction et l'engagement des apprenants. Laravel aide à structurer des parcours d'apprentissage personnalisés en fonction des besoins spécifiques de chaque utilisateur, intégrant des exercices pratiques, des simulations d'examens, et des analyses de performances.

Exemple de code pour afficher des exercices personnalisés aux utilisateurs :

‍

public function showExercises(Request $request)
{
	$userLevel = $request->user()->level;
	$exercises = Exercise::where('difficulty', $userLevel)->get();
	return view('exercises.list', compact('exercises'));
}

Ce code PHP illustre comment Laravel peut être utilisé pour récupérer et afficher des exercices adaptés au niveau de difficulté de l'utilisateur, en utilisant l'ORM Eloquent pour une extraction efficace des données correspondantes.

La capacité de Laravel à gérer de grandes quantités de contenu éducatif est essentielle pour une plateforme comme GlobalExam, qui offre des ressources pour une variété de tests dans plusieurs langues. Laravel facilite la mise à jour et l'organisation du contenu, assurant que les informations restent à jour et pertinentes.

public function updateContent(Request $request, $contentId)
{
	$content = Content::find($contentId);
	$content->update($request->all());
	return redirect()->back()->with('status', 'Content updated successfully!');
}

‍

Cet exemple montre comment Laravel gère la mise à jour du contenu éducatif, permettant aux administrateurs de la plateforme de maintenir facilement le matériel à jour avec des informations précises et actuelles.

Un aspect crucial de la préparation aux tests est le suivi des performances. Laravel aide GlobalExam à collecter et analyser les données des utilisateurs pour fournir des feedbacks détaillés et des recommandations personnalisées. Laravel offre des outils robustes pour le reporting et les analytics, qui sont essentiels pour optimiser les parcours d'apprentissage.

public function getUserProgress($userId)
{
	$progress = Progress::where('user_id', $userId)->latest()->first();
	return view('users.progress', compact('progress'));
}

Ce code démontre l'utilisation de Laravel pour suivre et afficher les progrès des utilisateurs, en permettant un accès facile aux informations historiques et actuelles sur les performances.

GlobalExam est un exemple parfait de la façon dont Laravel peut être utilisé pour développer des applications web complexes, centrées sur l'utilisateur, dans le domaine de l'éducation.

‍

‍

2. Ornikar : Révolutionner l'apprentissage de la conduite

Ornikar est non seulement une auto-école en ligne qui offre des leçons de conduite et des cours de code de la route, mais elle transforme également la façon dont les gens apprennent à conduire en France. Utilisant Laravel, Ornikar offre une plateforme flexible et sécurisée pour que les utilisateurs planifient leurs leçons, étudient le code de la route et passent leurs examens, le tout en ligne.

Laravel permet à Ornikar de proposer une interface utilisateur (UI) fluide qui s'adapte à tous les appareils, essentielle pour les étudiants en déplacement. La facilité d'utilisation est améliorée par Laravel, qui soutient une expérience utilisateur homogène sur le site web, en permettant de réserver des leçons et d'accéder à des matériaux d'étude interactifs.

Exemple de code pour une réservation de leçon dans Laravel :

‍

public function bookLesson(Request $request)
{
	$request->validate([
    	'lesson_date' => 'required|date',
    	'instructor_id' => 'required|exists:instructors,id',
	]);
 
	$lesson = new Lesson([
    	'student_id' => auth()->id(),
    	'instructor_id' => $request->instructor_id,
    	'scheduled_date' => $request->lesson_date,
	]);
 
	$lesson->save();
 
	return redirect()->back()->with('success', 'Lesson booked successfully!');
}

Ce code Laravel illustre comment une leçon peut être réservée via la plateforme, en s'assurant que toutes les données sont validées avant de procéder à l'enregistrement dans la base de données.

Avec un grand nombre d'utilisateurs accédant à des cours variés, la gestion efficace du contenu est cruciale. Laravel aide Ornikar à organiser et à mettre à jour ses contenus éducatifs de manière dynamique, garantissant que les informations sont toujours actuelles et pertinentes.

‍

public function updateCourseMaterial(Request $request, $courseId)
{
	$course = Course::findOrFail($courseId);
	$course->update($request->all());
 
	return redirect()->back()->with('status', 'Course material updated successfully!');
}

Ce morceau de code permet aux administrateurs de mettre à jour facilement le matériel de cours, en utilisant l'ORM Eloquent de Laravel pour une interaction fluide avec la base de données.

Ornikar utilise Laravel pour suivre les progrès des étudiants et analyser les données d'utilisation pour améliorer continuellement leurs services. Cette fonctionnalité est essentielle pour fournir un feedback personnalisé aux étudiants et pour ajuster les méthodes d'enseignement en fonction des besoins des utilisateurs.

‍

public function getStudentProgress($studentId)
{
	$progress = Progress::where('student_id', $studentId)->latest()->get();
	return view('students.progress', ['progress' => $progress]);
}

Ce code utilise Laravel pour récupérer et afficher les progrès d'un étudiant, aidant les instructeurs et les étudiants à visualiser les améliorations au fil du temps et à identifier les domaines nécessitant une attention supplémentaire.

Ornikar est un exemple éloquent de la manière dont Laravel peut être utilisé pour transformer des industries traditionnelles comme l'éducation à la conduite.

‍

3. Lemon Learning : Transformer la formation logicielle en entreprise

Lemon Learning est une plateforme innovante qui révolutionne la formation logicielle en entreprise en intégrant des guides interactifs directement dans les outils SaaS utilisés par les entreprises. Grâce à Laravel, Lemon Learning offre une solution fluide et intégrée qui aide les employés à maîtriser rapidement et efficacement divers logiciels, en réduisant le temps nécessaire à la formation et en maximisant la productivité.

L'un des défis majeurs pour Lemon Learning était d'assurer une intégration transparente de ses guides interactifs avec une multitude d'applications d'entreprise sans perturber l'expérience utilisateur. Laravel a permis de développer une API robuste et sécurisée qui s'interface facilement avec n'importe quel logiciel d'entreprise utilisé par les clients.

Exemple de code pour une API Laravel gérant les requêtes d'intégration :

‍

Route::post('/integration/setup', 'IntegrationController@store');
 
public function store(Request $request)
{
	$this->validate($request, [
    	'software_id' => 'required|exists:softwares,id',
    	'client_id' => 'required|exists:clients,id',
    	// Autres validations nécessaires
	]);
 
	$integration = new Integration([
    	'software_id' => $request->software_id,
    	'client_id' => $request->client_id,
    	// Autres paramètres
	]);
 
	$integration->save();
 
	return response()->json(['message' => 'Integration setup successfully!'], 201);
}

Ce code illustre comment Laravel peut être utilisé pour créer des endpoints API qui facilitent l'intégration de la plateforme Lemon Learning avec divers logiciels d'entreprise, permettant des configurations personnalisées pour chaque client.

Laravel aide également Lemon Learning à gérer de manière dynamique et efficace les contenus de formation. La plateforme doit constamment mettre à jour et personnaliser les tutoriels pour s'adapter aux logiciels qui évoluent rapidement. Laravel offre des outils puissants pour la gestion de contenu qui facilitent ces mises à jour régulières.

public function updateTutorial(Request $request, $tutorialId)
{
	$tutorial = Tutorial::findOrFail($tutorialId);
	$tutorial->update($request->all());
 
	return redirect()->back()->with('success', 'Tutorial updated successfully!');
}

Ce morceau de code permet aux administrateurs de Lemon Learning de mettre à jour les tutoriels directement via le tableau de bord, en utilisant l'ORM Eloquent pour une interaction efficace avec la base de données.

Un autre aspect crucial de Lemon Learning est le suivi des progrès des utilisateurs et l'analyse des performances des tutoriels. Laravel fournit des capacités sophistiquées de reporting et d'analyse qui permettent à Lemon Learning d'offrir des insights précieux aux entreprises sur l'efficacité des formations.

‍

public function getUserProgress($userId)
{
	$progress = Progress::with('tutorials.completed')->where('user_id', $userId)->get();
	return view('progress.show', compact('progress'));
}

Ce code utilise Laravel pour recueillir et présenter des données détaillées sur la progression de chaque utilisateur, aidant les entreprises à mesurer l'impact réel de la formation sur la productivité et l'efficacité des employés.

Lemon Learning illustre parfaitement la capacité de Laravel à soutenir des solutions technologiques innovantes dans le domaine de la formation en entreprise.

‍

4. HelloWork : Dynamiser le recrutement en ligne

HelloWork est une plateforme française leader dans le domaine du recrutement en ligne, qui connecte les employeurs aux candidats à travers une interface intuitive et efficace. Utilisant Laravel, HelloWork optimise les processus de recherche d'emploi et de recrutement, facilitant les interactions entre les entreprises et les chercheurs d'emploi grâce à des fonctionnalités avancées et une gestion fluide des données.

La plateforme HelloWork repose sur Laravel pour fournir une expérience utilisateur (UX) riche et interactive, facilitant la navigation, la recherche d'emploi et la gestion des candidatures. Laravel aide à structurer une interface utilisateur qui répond rapidement aux actions des utilisateurs, améliorant ainsi leur engagement et leur satisfaction.

Exemple de code pour afficher les offres d'emploi selon les filtres de l'utilisateur :

public function listJobs(Request $request)
{
	$jobs = Job::query();
 
	if ($request->has('location')) {
    	$jobs->where('location', $request->location);
	}
	if ($request->has('keyword')) {
    	$jobs->where('title', 'like', '%' . $request->keyword . '%');
	}
 
	return view('jobs.index', ['jobs' => $jobs->paginate(10)]);
}

Ce code illustre comment Laravel peut être utilisé pour créer des filtres dynamiques qui ajustent les résultats de recherche en fonction des préférences des utilisateurs, rendant la recherche d'emploi plus ciblée et efficace.

‍

Laravel fournit à HelloWork les outils nécessaires pour gérer dynamiquement des milliers d'annonces d'emploi et de profils de candidats. L'ORM Eloquent intégré permet une manipulation aisée des données, assurant une mise à jour et une récupération efficace des informations pertinentes.

‍

public function updateJob(Request $request, $jobId)
{
	$job = Job::findOrFail($jobId);
	$job->update($request->all());
 
	return redirect()->back()->with('success', 'Job updated successfully!');
}

‍

Ce morceau de code montre comment les annonces d'emploi peuvent être mises à jour facilement par les employeurs, garantissant que les informations restent actuelles et précises.

La capacité de suivre les candidatures et d'analyser le comportement des utilisateurs est cruciale pour optimiser les stratégies de recrutement. Laravel aide HelloWork à collecter et analyser les données des utilisateurs, fournissant des insights précieux pour les employeurs sur l'efficacité de leurs annonces.

‍

public function trackApplications($jobId)
{
	$applications = Application::where('job_id', $jobId)->get();
	return view('employers.analytics', ['applications' => $applications]);
}

Ce code utilise Laravel pour récupérer et afficher les données sur les candidatures reçues pour un poste spécifique, permettant aux employeurs de mesurer l'intérêt et l'efficacité de leurs annonces.

HelloWork démontre l'efficacité de Laravel dans le développement de solutions de recrutement en ligne.

‍

5. Ecodrop : Faciliter le recyclage pour les professionnels du BTP

Ecodrop est une plateforme innovante qui révolutionne la gestion des déchets de construction en facilitant le recyclage pour les professionnels du BTP en France. Utilisant Laravel, Ecodrop offre une solution efficace pour localiser les points de collecte les plus proches, gérer les déchets de manière responsable, et optimiser la logistique des déchets de chantier.

Laravel aide Ecodrop à fournir une interface utilisateur claire et facile à naviguer, permettant aux professionnels de trouver rapidement des solutions de recyclage à proximité. La plateforme permet également une interaction fluide pour la réservation de collectes de déchets, la consultation des prix et le suivi des transactions.

Exemple de code pour la recherche de centres de recyclage par localisation :

‍

public function searchRecyclingCenters(Request $request)
{
	$centers = RecyclingCenter::query();
	if ($request->has('zipcode')) {
    	$centers->where('zipcode', $request->zipcode);
	}
	return view('recycling.centers', ['centers' => $centers->get()]);
}

Ce code montre comment Laravel peut être utilisé pour filtrer les centres de recyclage en fonction du code postal fourni par l'utilisateur, simplifiant ainsi la recherche et aidant les professionnels à trouver les options les plus pratiques.

Laravel fournit les outils nécessaires pour gérer efficacement les profils des utilisateurs et les commandes de collecte de déchets. Les professionnels peuvent s'enregistrer, gérer leurs informations, et planifier des collectes en quelques clics.

‍

public function updateProfile(Request $request)
{
	$user = Auth::user();
	$user->update($request->all());
 
	return redirect()->route('profile')->with('success', 'Profile updated successfully!');
}

Ce morceau de code illustre la mise à jour du profil utilisateur avec Laravel, utilisant l'authentification intégrée et l'ORM Eloquent pour une interaction sécurisée et efficace avec la base de données.

Laravel aide Ecodrop à suivre les transactions et à analyser l'efficacité des services offerts. La plateforme collecte des données sur les types et volumes de déchets collectés, permettant des analyses approfondies pour améliorer continuellement le service.

‍

public function getTransactionDetails($transactionId)
{
	$transaction = Transaction::with('user', 'recyclingCenter')->findOrFail($transactionId);
	return view('transactions.detail', ['transaction' => $transaction]);
}

Ce code utilise Laravel pour récupérer les détails d'une transaction spécifique, y compris les informations sur l'utilisateur et le centre de recyclage, facilitant le suivi et l'analyse des services de collecte.

Ecodrop illustre parfaitement comment Laravel peut être exploité pour développer des solutions durables et efficaces dans le secteur du BTP.

‍

En explorant ces cinq applications fascinantes développées avec Laravel - de GlobalExam à Ecodrop, en passant par Ornikar, Lemon Learning, et HelloWork -, il est clair que Laravel ne se contente pas d'être un simple outil de développement web. Il représente une solution complète qui offre flexibilité, efficacité et puissance pour relever les défis du développement web moderne. Chaque exemple met en lumière la capacité de Laravel à transformer des idées ambitieuses en réalités numériques robustes et performantes, offrant des expériences utilisateur riches et intuitives.

‍

Que vous soyez un développeur cherchant à affiner vos compétences ou une entreprise en quête d'innovation, Laravel se présente comme le framework de choix pour créer des applications web qui se distinguent. En définitive, ces cinq exemples ne sont qu'un aperçu de ce qui est possible avec Laravel, ouvrant la porte à un monde de potentiel illimité pour les développeurs et les entreprises du monde entier.

‍

Le database branching est une approche d’organisation de base de données qui permet de reproduire la dynamique et le fonctionnement des branches Git.

On va alors pouvoir à partir d’une base de données appelé “master” pouvoir dupliquer une “branche” avec un certain nom. Cette nouvelle base de données se vera hériter des données ainsi que des migrations de la branche source.

Les cas d’usages de ce principe sont multiples et variés. Si nous reprenons l’analogie avec Git flow, lorsque vous allez créer une nouvelle branche de feature, vous serez amené à devoir développer puis appliquer une migration de données ou bien tout simplement altérer les données contenues dans cette base. Elle devient à partir de là un bac à sable tout en partant d’un environnement déjà prédéfini.

Grâce à la nouvelle base de données mise en place pour votre feature, vous n’allez impacter aucun environnement de production / staging / dev mis en place et accessible par tous les développeurs.

Votre base de données sera alors unique et éphémère, une fois la feature terminée, celle-ci pourra être supprimée.

Elle peut aussi servir de base de données temporaire pour une démonstration client, alimentée de données bien précises pour cette dite démonstration.

Pour terminer cette introduction, j’ajouterai que le database branching est présent avant tout pour améliorer la “DX” des développeurs au quotidien.

‍

Pourquoi ne pas alors simplement produire une base de données sur ma machine ?

Il est autant possible que l’infrastructure du projet mette à disposition un cluster de base de données sur un serveur ou bien qu’un développeur puisse créer son cluster sur sa machine.

Avec un provisionnement type Docker vous pouvez déployer rapidement une base de données sur votre machine avec un script de seeding permettant d’alimenter cette base en données. Cependant, vous allez perdre une composante essentielle au database branching qui est la synchronisation de la branche Git avec les données.  En effet, si vous êtes plusieurs développeurs à intervertir sur cette feature / environnement, aucune manipulations supplémentaires ne sera à faire lors du passage sur la branche Git. Vous récupérez la base de données déjà préparée par le précédent développeur.

Vous allez aussi avoir la problématique d’espace disponible sur votre machine, si vous travaillez sur plusieurs branches en même temps, cela implique de pouvoir posséder un conteneur d’une base de données unique par branche. Donc, une grande quantité de données en local.

‍

Comment s’intègre le Database branching dans le workflow du développeur

Comme n’importe quel outil s’ajoutant sur une stack d’un projet, le database branching viens complexifier quelques aspects techniques de celui-ci.

Alors, il est nécessaire d’automatiser le maximums d’aspects du database branching afin de ne pas augmenter le nombre de tâches à réaliser par les développeurs lors de la création d’une nouvelle feature.

En laissant certaines tâches manuelles, nous risquons de frustrer nos collègues développeurs. En effet, il est très facile d’oublier d’exécuter  une certaine commande après un changement de branche.

Dans la deuxième partie de l’article nous nous intéresseront à réaliser un environnement de développement fluide avec l’exemple d’une stack web.

Je dirai alors que le database branching idéal est celui qui est complètement transparents pour les développeurs.

Dans la finalité ce principe est plus ou moins une idéologie, le degrés de l’implémentation peut dépendre de l’envergure du projet et du nombre de développeurs.

‍

Tutoriel: Mise en place du database branching sur une stack Typescript, Prisma

‍

Initialisation du projet et de la base de donnée

La première étape de ce tutoriel sera de se munir d’une base de données avec un utilisateur ayant l’autorisation de créer des database supplémentaires.

Voici plusieurs providers proposant ce service:

• Planetscale
• Neon
• AWS

Actuellement nous utilisons une base de données hébergée Aurora Serverless hébergée sur AWS déployée depuis Terraform avec le module suivant.

Pour la suite de ce tutoriel nous avons choisis d’utiliser une base de données PostgreSQL. Il est aussi tout à fait possible de l’intégrer sur une base de données MongoDB, MySQL, …

Pour passer rapidement sur les étapes d’initialisation du projet TS avec Prisma je vous redirige vers la documentation officielle de Prisma.

Après toutes ces étapes vous devriez avoir dans la racine de votre projet un fichier d’environnement nommé .env qui possède une url de base de données DATABASE_URL.

À présent nous pouvons remplacer cette url par celle de notre base de données  provisionnée un peu plus haut.

DATABASE_URL="postgresql://gabriel:password@db-branching.cluster-xxxxxxx.eu-west-3.rds.amazonaws.com:5432/master?schema=public"

La database pointée (master dans ce cas-là) importe peu, elle sera mise à jour par  la suite automatiquement.

‍

Automatisation du changement de branche

Afin de faciliter le passage sur une nouvelle base de données à chaque changement de branche git, il est possible de créer un hook sur le projet git, qui sera exclusivement lancé lors d'une commande git checkout.

Pour celà nous utiliserons un outil facilitant la création de hook git nommé Husky.

Voici les commandes d’installation que vous pouvez retrouver dans la documentation officielle:

Cette dernière commande va alors créer un script bash dans le dossier suivant.husky/post-checkout.

On ajoutera ces trois lignes de bash permettant de récupérer la branche git lors d’un checkout et de mettre à jour le fichier .env

Et voilà !

Maintenant à chaque changement de branche en local votre .env sera mis à jour automatiquement.

Il est possible d’aller plus loin en ajoutant l’application automatique des migrations de la base données et/ou le seeding de data.

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.

‍

‍

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

‍

Lorsque l’on développe une solution SaaS, il est nécessaire de bien penser son architecture, surtout si à l’avenir vous réfléchissez déjà à faire découpler plusieurs instances de celle-ci.

‍

Pour imager, prenons pour exemple un site e-commerce.

‍

Vous pouvez faire le choix de partir sur une architecture simple pour votre MVP, avec tout simplement votre boutique à Paris, mais dès lors où le besoin d’avoir plusieurs boutiques se présente, plusieurs questions vont venir à vous.

‍

Ces questions pourraient concerner :

La gestion du stock : est-elle centralisée ? Y-a-t’il un stock par boutique ?

La gestion des produits : est-ce que chaque boutique est indépendante, est-ce qu’elle a ses propres produits ?

La gestion des utilisateurs : est-ce que je stocke les données utilisateurs par boutique ? Est-ce que j’ai une base commune d’utilisateurs ?

‍

Toutes vos réponses vont impacter la façon dont vous allez mettre en place le multi-tenant.

‍

Le multi-tenant

Vous l’avez compris, on parle de multi-tenant lorsque l’on doit gérer plusieurs contextes dans une application, si l’on devait reprendre notre exemple précédent on considèrerait chaque boutique comme un contexte.

‍

Gestion en single-database

La gestion du multi-tenant au moyen d'une seule base de données présente plusieurs avantages significatifs.

Tout d'abord, elle simplifie considérablement la maintenance car il n'y a qu'une seule base a gérer en cas de bugs ou de restauration des backups.

‍

De plus, la base de données demeure relativement simple à gérer avec l'utilisation d'un champ tenant_id (store_id) pour distinguer les différents tenants.

‍

Cela offre un avantage financier car il n'y a pas de surcoût au niveau de l'infrastructure.

‍

L'approche du multi-tenant avec une seule base de données comporte également certains inconvénients notables.

‍

Dans le cas de l'utilisation d'un Framework PHP tel que Laravel ou Symfony par exemple, l'adaptation des packages de la communauté ainsi que des requêtes SQL est nécessaire, ce qui peut entraîner des coûts de développements supplémentaires.

‍

En effet, il faudra ajouter un critère à chaque requête pour spécifier le bon tenant à utiliser, un oubli entraînerait des conséquences assez importantes.

‍

De plus, la centralisation des données peut rendre la restauration de données complexe si on a besoin de restaurer les données pour un tenant précis.

‍

Gestion en single-database multi-schema

Une alternative possible dans l'implémentation du multi-tenant consiste à attribuer à chaque tenant ses propres tables au sein de la base de données.

Cette approche offre une isolation accrue et la gestion des données s'en retrouve simplifiée. Tout comme pour l'implémentation précédente, la restauration des données reste simple. En adoptant cette approche, on ajoute donc une séparation des données de tenants.

‍

Cependant, cette approche présente également quelques inconvénients.

‍

La nécessité de restaurer un tenant spécifique peut être plus compliquée, car il faut sélectionner individuellement chacune des tables lors du backup ou lors de la restauration.

‍

De plus, à mesure que le nombre de tenants augmente, le nombre de tables associées peut devenir considérable, ce qui risque de compliquer la gestion à long terme.

‍

Si des modifications sont apportées à la structure d'une table, chaque table dupliquée pour chaque tenant doit être mise à jour individuellement.

‍

Cela rend également la gestion des migrations compliquées avec des frameworks comme Laravel ou Symfony puisqu'ils n'ont pas été prévu à cet effet.

‍

Gestion en multi-database

L'utilisation du multi-tenant avec une base de données spécifique par tenant offre plusieurs avantages.

Une simplicité côté développement, où il suffit de spécifier quel tenant est utilisé sans adaptations complexes de packages ou de requêtes SQL. L'implémentation est donc plus rapide et le code plus facile à maintenir.

‍

Pour le backup et la restauration, il suffit de le faire sur la base de données du tenant.

‍

On peut optimiser les performances en ajustant les ressources allouées à chaque tenant en fonction de ses besoins.

‍

C’est également le schéma idéal si dans un projet chaque tenant correspond à un site client et que ces clients souhaitent une confidentialité et isolation de leur données.

‍

Et pour les désavantages de cette implémentation, on peut avoir plus de serveurs ou plus de base de données à maintenir, il faut avoir quelques bases côté infrastructure pour mettre en place et configurer les environnements et le coût d'infrastructure sera plus conséquent.

‍

Conclusion

Chaque architecture a ses avantages et inconvénients, la décision devra se prendre en fonction de vos besoins, de vos coûts, de l’effectif de votre équipe et de nombreux facteurs qui composeront la pérennité de votre projet.

‍

Sur le Framework Laravel, plusieurs packages existent pour gérer le multi-tenant. Si on devait en opposer deux, le package Laravel Multitenancy de Spatie propose une implémentation simple et légère qu’il faudra agrémenter de “Tasks” selon le mode de gestion que vous allez choisir, tandis que le package Tenancy d’ArchtechX propose plutôt une architecture plus complexe qui répond à un maximum de besoins avec plus d'opinion.

‍

Il est primordial de s’intéresser à chacune des solutions existantes et de créer des POCs avant de se lancer tête baissée dans l’implémentation du multi-tenant.

‍

Et vous ? Lequel de ces packages choisiriez-vous ?

‍

Si vous hésitez encore pas de panique ! Nous étudierons sans doute plus en détails les différences dans un prochain article.

Bienvenue dans l'univers du développement web, où chaque choix compte. Laravel et Symfony, deux géants du langage serveur PHP, se disputent la première place. Dans cet article, nous plongeons dans les détails, examinant performances, sécurité, et courbes d'apprentissage.

‍

Prêts à choisir le Framework idéal pour votre projet ? 

‍

Laravel et Symfony : Les titans du développement PHP

‍

Dans l'arène du développement serveur PHP, deux titans émergent : Laravel et Symfony.

‍

Laravel, créé par Taylor Otwell, séduit par son architecture élégante basée sur le modèle MVC (pour Modèle-Vue-Contrôleur), ses outils puissants, et une courbe d'apprentissage conviviale.

‍

De l'autre côté, Symfony, de SensioLabs, brille par sa modularité et des composants réutilisables. Avant de choisir votre champion, explorons en détail ce que chaque Framework peut vous offrir.

‍

Laravel

‍

Laravel est un Framework PHP qui a su captiver la communauté des développeurs. Imaginé par le développeur américain, Taylor Otwell, Laravel séduit par son architecture claire et élégante, basée sur le modèle architectural MVC. Cette structure facilite la conception d’applications et le développement en offrant une séparation nette entre les composants d’un projet.

Laravel ne fait pas que promettre, il délivre des performances remarquables. Les temps de réponse sont optimisés pour offrir une expérience utilisateur plus fluide. La gestion intelligente des bases de données et les outils intégrés font de Laravel un choix judicieux pour des applications performantes.

Dans le monde numérique d'aujourd'hui, la sécurité est primordiale. Pour cela, Laravel intègre des systèmes robustes garantissant la protection à long terme de vos applications web modernes. Des mécanismes de sécurité avancés sont mis en place pour contrer les menaces potentielles.

La courbe d'apprentissage est souvent un obstacle, mais pas avec Laravel. Son approche conviviale permet aux développeurs de rapidement maîtriser le Framework. La documentation détaillée et la communauté active font de l'apprentissage une expérience fluide.

‍

Exemple de code concret : Gestion des utilisateurs avec Laravel

‍

‍

• Laraval utilise l’ORM (pour Object Relational Model) Eloquent pour simplifier les opérations d’interactions avec la base de données.
• La fonction bcrypt () sécurise le mot de passe avant son enregistrement.
• La réponse est renvoyée au format JSON.

‍

Laravel est votre allié dans la création d'applications web dynamiques et performantes.

‍

Symfony

‍

L’univers du Framework PHP Symfony est tout aussi passionnant. Renommé, riche et modulaire, Symfony est développé et maintenu par la société française SensioLabs. Symfony se démarque par son approche modulaire et ses composants réutilisables, offrant une flexibilité remarquable dans la conception d’application web.

Symfony ne se contente pas d'une architecture flexible, il excelle également en matière de performances. Les temps de réponse compétitifs et la gestion efficace des ressources font de Symfony un choix judicieux pour réaliser des applications PHP performantes.

La sécurité étant une priorité dans le paysage numérique actuel, Symfony intègre des mécanismes de sécurité assurant la protection de vos applications contre les menaces. La courbe d'apprentissage de Symfony est également conçue pour faciliter l'adoption du Framework. Les développeurs bénéficient d'une documentation exhaustive et d'une communauté active, simplifiant ainsi l'exploration des fonctionnalités avancées de Symfony.

‍

Exemple de code concret : gestion des utilisateurs avec Symfony

‍

‍

• Symfony utilise l’ORM Doctrine ainsi que les méthodes setName(), setEmail(), et setPassword() pour définir les propriétés de l'objet utilisateur.
• Le mot de passe est sécurisé à l’aide de password_hash().
• La méthode flush() persiste les changements en base de données.
• La réponse est renvoyée au format JSON.

‍

En somme, Symfony est un partenaire fiable pour le développement web.

‍

Comparaison directe

‍

Plongeons dans la comparaison directe entre Laravel et Symfony, examinant de près les éléments clés qui pourraient influencer votre décision dans le choix du Framework PHP idéal.

‍

Performance : la quête de la réactivité

La performance est cruciale pour une expérience utilisateur optimale. Nous comparons les temps de réponse de Laravel et Symfony pour vous aider à choisir le Framework qui offre la réactivité nécessaire à votre projet.

• Temps de Réponse : Laravel excelle avec des temps de réponse moyens de 250 millisecondes, offrant une expérience utilisateur rapide. Symfony, bien que compétitif, tend à se situer légèrement au-dessus, aux alentours de 300 millisecondes.

• Exemple : Un site e-commerce nécessitant une navigation rapide pourrait bénéficier des performances de Laravel, assurant une réponse quasi-instantanée lors de la recherche de produits.

‍

Architecture : MVC sous le microscope

L'architecture MVC (Modèle-Vue-Contrôleur) est le pilier du développement web moderne. Analysons comment Laravel et Symfony abordent cette structure fondamentale et en quoi cela peut impacter la gestion de votre code.

• Laravel : Son modèle MVC clair offre une structure fluide. Les développeurs peuvent facilement segmenter les responsabilités, améliorant la maintenabilité du code.

• Symfony : Une approche modulaire permettant une personnalisation avancée. Les composants réutilisables simplifient le développement, mais cela peut entraîner une complexité accrue pour les petits projets.

• Exemple : Un projet nécessitant une structure claire et simple pourrait préférer Laravel, tandis qu'un système complexe pourrait tirer parti de la modularité de Symfony.
• ‍

Command Line Interface (CLI) : L'art de la ligne de commande

La ligne de commande est l'alliée du développeur moderne. Comparons comment Laravel et Symfony s'engagent dans le royaume de l'interface en ligne de commande (CLI), facilitant ainsi le flux de travail du développeur.

• Laravel : La CLI de Laravel simplifie les tâches courantes telles que la génération de code, facilitant le flux de travail du développeur.

• Symfony : Une CLI robuste, mais avec une courbe d'apprentissage plus prononcée. Elle offre une personnalisation avancée, mais peut sembler complexe pour les débutants.

• Exemple : Pour un développeur qui privilégie la simplicité et la rapidité, la CLI de Laravel serait un choix naturel.

‍

Migration de base de données : Gestion intelligente des données

La migration efficace de la base de données est un défi incontournable. Jetons un regard attentif sur la manière dont Laravel et Symfony simplifient ce processus critique pour garantir une gestion fluide des données.

• Laravel : Les migrations simplifient les changements de schéma de base de données. Les développeurs peuvent versionner et partager ces modifications facilement.

• Symfony : Des migrations intégrées offrant également une gestion efficace des changements de base de données. Les bundles Symfony facilitent la modularité.

• Exemple : Un projet nécessitant des mises à jour fréquentes de la base de données pourrait bénéficier de la simplicité des migrations de Laravel.

‍

N’hésitez pas à plonger davantage dans ces détails pour faire un choix éclairé entre Laravel et Symfony, en alignant les forces de chaque Framework avec les exigences spécifiques de votre projet.

‍

‍

Frameworks PHP : Un choix déterminant pour le développement web

‍

Explorez l'impact déterminant que le choix entre Laravel et Symfony peut avoir sur votre projet de développement web.

‍

Choisir le bon Framework : un dilemme crucial

La sélection du bon Framework PHP est un dilemme majeur, influençant directement la réussite de votre projet. Laravel et Symfony offrent des avantages uniques, mais lequel répond le mieux à vos besoins spécifiques ?

• Laravel : Excellant dans la simplicité et la rapidité de développement, Laravel est souvent le choix préféré pour les projets de taille moyenne nécessitant une mise en œuvre rapide.

• Symfony : Connu pour sa modularité et ses composants réutilisables, Symfony brille dans des projets plus complexes où la personnalisation et la réutilisation de code sont essentielles.

• Exemple : Un site vitrine pour une petite entreprise pourrait privilégier la simplicité de Laravel, tandis qu'un système de gestion complexe opterait probablement pour la modularité de Symfony.

‍

Forces et faiblesses : un examen critique

Chacun des Frameworks a ses points forts et ses faiblesses. Examinons en détail les avantages et les limitations de Laravel et Symfony pour vous guider dans cette décision cruciale.

• Laravel : Points forts dans la simplicité, la documentation claire et la courbe d'apprentissage conviviale. Cependant, sa modularité peut être moins flexible pour des projets très spécifiques.

• Symfony : Excellant dans la modularité, Symfony offre une flexibilité maximale, mais sa courbe d'apprentissage peut être plus abrupte pour les débutants.

• Exemple : Un projet nécessitant des fonctionnalités spécifiques pourrait bénéficier de la flexibilité de Symfony, tandis qu'un projet plus simple pourrait opter pour la simplicité de Laravel.

‍

Taille du projet : l'importance du contexte

La taille de votre projet est un facteur déterminant. Nous évaluons comment Laravel et Symfony s'adaptent aux projets de différentes envergures, vous permettant ainsi de choisir en fonction de vos besoins spécifiques.

• Laravel : Idéal pour des projets de taille moyenne, où la rapidité de développement est cruciale.

• Symfony : Convient particulièrement aux projets de grande envergure, offrant la modularité nécessaire pour gérer la complexité.

• Exemple : Un blog personnel pourrait tirer parti de la simplicité de Laravel, tandis qu'un système de gestion d'entreprise complexe pourrait profiter de la robustesse de Symfony.

‍

Performance attendue : Une réflexion essentielle

Quelles performances attendez-vous de votre application web ? Laravel et Symfony offrent des approches différentes. Décortiquons ces approches pour vous aider à prendre une décision éclairée.

• Laravel : Performances élevées pour des projets de taille moyenne, avec des temps de réponse compétitifs.

• Symfony : Excellentes performances également, mais peut être plus adapté à des projets plus vastes.

• Exemple : Un site de portfolio artistique pourrait privilégier les performances de Laravel, tandis qu'un site e-commerce à fort trafic pourrait opter pour Symfony.

‍

Préférences des développeurs : Un facteur humain

L'adhésion des développeurs à un Framework peut être un critère déterminant. Découvrez comment Laravel et Symfony sont perçus dans la communauté des développeurs, un aspect clé pour le succès à long terme de votre projet.

• Laravel : Apprécié pour sa simplicité et son approche élégante, attirant souvent les développeurs cherchant une courbe d'apprentissage plus douce.

• Symfony : Adopté par des développeurs expérimentés cherchant une modularité étendue et une personnalisation avancée.

• Exemple : Une équipe de jeunes développeurs débutants pourrait se sentir à l'aise avec la simplicité de Laravel, tandis qu'une équipe expérimentée pourrait être attirée par la puissance de Symfony.

‍

Après avoir exploré les nuances de Laravel et Symfony, il est temps de conclure. Chaque projet a des besoins uniques, et votre décision devrait être ancrée dans une évaluation minutieuse des forces et des faiblesses de chaque Framework.

‍

En conclusion, gardez un œil sur l'horizon du développement web. Les Frameworks évoluent, les tendances changent. Votre choix devrait également être orienté vers l'avenir, en tenant compte des mises à jour futures, de la communauté active et des innovations à venir.

‍

Votre choix entre Laravel et Symfony déterminera la trajectoire de votre projet. Explorez les possibilités infinies offertes par ces Frameworks PHP et prenez votre décision en connaissance de cause. Votre aventure de développement web commence ici. Bonne exploration !

À 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.

‍

‍

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.

Introduction

Aujourd'hui, comment parler de développement logiciel sans parler de Git ? Un bon système de gestion des versions est essentiel pour assurer un flux de travail efficace. Git est l'outil de gestion de versions par excellence et est le plus populaire. Néanmoins, avec Git, il s'est développé différentes stratégies pour structurer et gérer le flux de modifications de la codebase. Parmi toutes ces stratégies, aujourd'hui, deux vont nous intéresser : le Trunk-Based Development (TBD) et Git Flow.

‍

D'un côté on a le TBD, une approche minimaliste qui préconise de travailler directement sur un tronc commun, autrement dit la branche principale. Tandis que Git Flow, lui, propose une structure plus complexe, avec des branches dédiées à des fonctionnalités, des corrections, des versions, etc.

‍

Les deux approches ont des avantages et des inconvénients, leurs propres complexités et simplicités et c'est ce que nous allons voir maintenant.

‍

L'objectif de cet article n'est pas simplement de fournir une explication de ces deux stratégies de gestion des versions, mais plutôt de démontrer pourquoi, dans de nombreux contextes, le TBD peut s'avérer une approche plus optimale que Git Flow.

‍

Git Flow vs Trunk-Based Development

‍

La stratégie Git Flow

Git Flow est une stratégie de gestion de versions populaire qui a été conçue pour aider les équipes à gérer les développements complexes, en tirant parti de la puissance et de la flexibilité des branches Git. Elle propose une structure organisée qui facilite le développement parallèle de différentes fonctionnalités et la gestion des versions.

‍

Organisation

Avec Git Flow on organise nos branches de la manière suivante :

• main, la branche principale qui représente l'état actuel de la production
• develop, la branche où se trouve toutes les fonctionnalités, corrections et autres de la prochaine version prévue
• feature/xxx, les branches créées à partir de develop où se trouve le code d'une fonctionnalité qui sera fusionné avec develop une fois le développement terminé
• release/xxx, les branches créées à partir de develop où se trouve le code d'une nouvelle version du logiciel, potentiellement affiné avant le déploiement
• hotfix/xxx, les branches créées à partir de main pour des corrections critiques découvertes en production. Ces branches sont fusionnées dans main dès que le correctif est prêt et sont également fusionnées avec develop pour s'assurer que la correction perdurera dans la codebase

‍

Les problèmes de Git Flow

La force de Git Flow réside dans sa structure qui permet de gérer facilement des tâches parallèles et suivre d'évolution du code à travers le temps.

Cette stratégie entraîne néanmoins un lot d'inconvénients :

• Complexité - Cette stratégie nécessite beaucoup de manipulation manuelle des branches qui demande une maîtrise totale de Git et de ce processus
• Intégration continue compliquée - L'intégration continue est plus complexe à mettre en place en raison du développement parallèle sur plusieurs branches
• Déploiement fréquent coûteux - Le déploiement continus/fréquents n'est pas impossible mais demande beaucoup plus de temps et d'énergie
• Problèmes de fusion - Le nombre parallèle de branches important entraîne de nombreux problèmes potentiels de merge
• Revues de code difficiles - La taille des pull requests a tendance à être plus importante avec Git Flow parce qu'elles contiennent des fonctionnalités complètes. La branche de feature a tendance à vivre trop longtemps, nécessitant des fusions fréquentes avec develop ce qui entraîne des retards dans le processus de livraison
  

‍

La stratégie Trunk-Based Development

La stratégie Trunk-Based Development est une approche bien plus minimaliste dont le but est de simplifier le flux de travail en minimisant la fragmentation du code et en facilitant l'intégration continue. Pour cela on ne va travailler que sur une seule branche principale (main ou trunk) autrement appelé : le tronc commun.

‍

Une seule source de vérité

Avec le TBD, cela signifie donc que toutes les modifications du code sont introduites et fusionnées directement dans la branche principale. Chaque développeur doit donc fusionner régulièrement ses modifications, plusieurs fois par jour. En conséquence, les versions sont gérées directement à partir de la branche principale, chaque développeur est constamment à jour et les problèmes de fusions sont considérablement réduits. Le cycle de développement est plus rapide et alimente l'intégration et le déploiements continus.

‍

Quid des branches ?

Travailler avec l'approche TBD ne signifie pas qu'on a plus du tout de branche en plus de la branche principale. En effet, les branches peuvent encore être utilisées mais elles se doivent d'être de très courte durée et fusionnées dès que le travail est terminé.

‍

Quid des revues de code ?

Quel que soit la stratégie adoptée, le processus de revue de code persiste et demeure une composante essentielle pour assurer la qualité du code qui est fusionné dans le tronc commun. La subtilité entre les deux stratégie est que avec le TBD, les modifications étant fréquemment fusionnées, elles sont généralement plus petites. Et si les modifications s'avèrent importante alors le TBD souhaite mettre en avant la collaboration et demanderait de faire ces modifications en pair ou en mob programming. Enfin, les revues de code se doivent d'être traitées rapidement (dans la demi-journée) et doivent durer que quelques minutes (15 maximum à peu près).

‍

Quid des modifications importantes ?

Le TBD n'empêche pas le développement de fonctionnalités importantes qui demandent donc de lourdes modifications du code. En revanche, cette stratégie va favoriser la collaboration via du pair ou du mob programming mais ce n'est pas la seule solution. Il existe également les Feature Flags.

‍

Un Feature Flag est une technique de développement logiciel permettant de masquer, activer ou désactiver une fonctionnalité dans un environnement de production sans avoir à redéployer le code. Cette technique offre un contrôle en temps réel des fonctionnalités, représente une sécurité contre les problèmes potentiels de nouvelles fonctionnalités et, surtout, permet de travailler sur de nouvelles fonctionnalités directement dans la branche principale sans interrompre le fonctionnement normal de l'application.

‍

Dans le cadre de l'approche TBD, où toutes les modifications sont effectuées directement sur la branche principale, l'utilisation de Feature Flags de fusionner le code pour de nouvelles fonctionnalités qui ne sont pas encore terminées ou testées. La fonctionnalité peut être développée et fusionnée dans le tronc sans être exposée aux utilisateurs jusqu'à ce qu'elle soit prête, où le Feature Flag à ce moment-là, peut être activé.

‍

Le recours à des Feature Flags apporte une flexibilité considérable au processus de développement et constitue une composante essentielle pour atteindre un déploiement continu et un flux de travail efficace dans le TBD.

‍

Mais à quoi ça ressemble concrètement ?

Ce sont ni-plus ni-moins des booléens :

‍

Et à l'usage, par exemple pour du React mais le principe est le même pour n'importe quel environnement :

Il est tout à fait possible de mettre en place un système de Feature Flags contrôlable à distance via un backoffice ou des outils tout prêt à l'usage qui existe sur le marché comme Firebase Remote Config, PostHog ou Harness par exemple.

‍

Pré-requis

Pour une implémentation efficace du TBD, plusieurs éléments sont généralement requis :

• Intégration Continue (CI) : c'est une stratégie qui bénéficie grandement de l'utilisation de la CI étant donné quelle est souvent sollicité pour de petites modifications. La CI permet d'assurer que le tronc commun est toujours en état de fonctionner correctement et qu'elle continue à être deployable à tout moment.
• Tests automatisés : les tests automatisés vont de pair avec la CI, ils assurent, si ils sont correctement mis en place, de la qualité du code.
• Revues de code : comme mentionné précédemment, les revues de code sont une composante essentielle pour maintenir la qualité et le partage de connaissance.
• Feature flag : comme expliqué précédemment, il est important de savoir mettre en place les features flag parce qu'ils sont souvent utilisés.
• Culture de la collaboration : enfin, l'environnement de travail est très important, toute l'équipe doit être impliqué, connaître et appliquer ce processus. L'équipe doit également se responsabiliser et doit être prête à collaborer étroitement et à partager ses connaissances.

‍

Résumons les bénéfices

Maintenant que nous avons expliqué le TBD comment il fonctionne et dans quel contexte, nous pouvons en ressortir les bénéfices suivants :

• Intégration continue (CI) : grâce à l'intégration fréquente de petits changements, les problèmes sont détectés et résolus plus rapidement. De plus, cela limite les éventuels conflits de fusion.
• Déploiements plus rapides : avec une seule branche principale toujours prête à être déployée, le TBD peut faciliter des déploiements plus rapides et plus réguliers.
• Simplification du processus : la stratégie TBD supprime la nécessité de gérer de nombreuses branches à long terme, simplifiant le flux de travail de l'équipe.
• Qualité du code : les revues de code régulières contribuent à maintenir la qualité du code et à anticiper les problèmes.
• Flexibilité grâce aux Feature Flags : l'utilisation de Feature Flags permet de tester de nouvelles fonctionnalités en production sans les exposer aux utilisateurs finaux, contribuant à un lancement plus sûr et contrôlé des nouveautés.

‍

Un dernier bénéfice que nous allons voir en détail dans le dernier point de cet article, c'est la facilité avec laquelle le TBD favorise l'atteinte de performances élevées selon les métriques DORA, un ensemble de mesures reconnues pour évaluer l'efficacité des équipes.

‍

‍

Et les inconvénients dans tout ça ?

La mise en œuvre de la stratégie TBD présente également certains défis ou inconvénients :

• Gestion rigoureuses des fusions : les modifications doivent être fusionnées en continu dans le tronc commun, ce qui nécessite que les développeurs synchronisent fréquemment leur travail avec la branche principale pour éviter les conflits de fusion.
• Culture : pour certaines équipes, l'adoption de cette stratégie peut nécessiter un changement significatif dans leurs pratiques de travail, notamment l'intégration continue et les revues de code constantes.
• Déploiements risqués sans tests adéquats : sans une couverture de test adéquate, le risque d'introduction de bugs en production peut être plus élevé, car tout le code est fusionné directement dans la branche principale qui est déployée.
• Complexité des Feature Flags : bien que les Feature Flags offrent plus de flexibilité, leur gestion peut ajouter une certaine complexité. Une mauvaise utilisation des feature flags peut entraîner de la dette technique.

En dépit de ces défis/inconvénients, il est globalement reconnu que les avantages valent les efforts nécessaires pour mettre en œuvre le TBD. Comme pour beaucoup de choses de la vie, il est important de déterminer si cette stratégie est adaptée au contexte spécifique de votre équipe et de votre projet.

‍

‍

DORA Metrics et Trunk-Based Development

‍

Les DORA Metrics (ou DevOps Research and Assessment metrics), sont une série de mesures de performance pour les équipes de développement logiciel.

‍

Ces mesures incluent :

• Le temps de cycle de déploiement (Mean Lead Time for Changes - MLTC) : Le temps moyen nécessaire pour qu'un commit passe à la production.
• La fréquence de déploiement (Deployment Frequency - DF) : À quelle fréquence une organisation déploie du code en production.
• Le temps de rétablissement (Mean Time to Restore - MTTR) : Le temps nécessaire pour récupérer d'une panne ou d'un incident de production.
• Le taux d'échec des modifications (Change Failure Rate - CFR) : La proportion de déploiements causant un incident de production ou un échec de service.

‍

Le TBD est lié aux DORA Metrics car c'est une méthode de développement qui peut potentiellement améliorer ces mesures. Il encourage des cycles d'intégration et de déploiement plus courts, ce qui peut accélérer le délai de déploiement et augmenter la fréquence de déploiement.

• MLTC et DF : La fusion fréquente de petites modifications permet de réduire le temps de cycle de déploiement et d'augmenter la fréquence de déploiement, car la branche principale est toujours dans un état deployable.
• CFR : Avec des revues de code régulières et des tests automatisés, on peut s'attendre à ce que le pourcentage de modifications ratées diminue, car les problèmes sont souvent découverts et corrigés avant le déploiement.
• MTTR : Comme les problèmes sont généralement plus petits et plus localisés avec cette approche, il est généralement possible de corriger et de restaurer le service plus rapidement.

‍

En résumé, l’approche Trunk-Based Development est bien alignée avec l’amélioration des métriques DORA, ce qui en fait une stratégie de choix pour les équipes axées sur le DevOps.

Ainsi, le développement basé sur la stratégie TBD peut contribuer à l'amélioration des DORA metrics.

‍

‍

Le mot de la fin

Cet article a examiné en profondeur la stratégie de Trunk-Based Development (TBD) en la comparant à Git Flow et en mettant en avant ses nombreux avantages. Nous avons analysé comment le TBD favorise des cycles de développement plus rapides, une meilleure qualité de code grâce aux revues de code constantes, et une plus grande flexibilité par l'utilisation de feature flags. Nous avons également expliqué comment le TBD facilite l'atteinte de performances élevées selon les DORA Metrics.

‍

Cependant, nous avons également souligné que le TBD n'est pas sans défis. Il nécessite une gestion rigoureuse des fusions, un changement culturel significatif dans certaines équipes, une bonne couverture de tests pour minimiser les risques associés au déploiement constant.

Pour conclure, le TBD est un modèle puissant qui peut accélérer la livraison de valeur, améliorer la qualité du code et favoriser l'optimisation continue des performances de l'équipe. Cependant, comme pour toute stratégie, son adoption doit être précédée d’une évaluation approfondie des besoins, contextes et capacités spécifiques de l’équipe.

‍

‍

Les dédicaces

• Trunk-Based Development - Paul Hammant
• The best Git branching strategy - Daniel Moka
• Trunk-Based Development for Mobile Apps - Mirella Batista
• Atlassian Resources
• DORA Metrics : utiliser la technologie pour piloter la valeur du business - Thibaut Weissgerber

Dans l'univers du développement d'applications mobiles, la gestion des versions de Node.js est cruciale. Découvrez ici comment utiliser Node Version Manager (NVM) pour changer, installer des versions LTS, et éviter les conflits. Que vous soyez débutant ou expert, ce guide vous aidera à maîtriser cet outil essentiel.

‍

Comprendre l'importance de Node Version Manager (NVM)

‍

L'utilisation de différentes versions de Node.js peut être délicate. NVM simplifie ce processus en vous permettant de basculer facilement entre les versions. Vous évitez ainsi les conflits et assurez la compatibilité de vos projets.

‍

NVM offre une flexibilité totale pour installer et gérer des versions spécifiques de Node.js en fonction de vos besoins. Son utilisation est simple, même pour les débutants, avec des commandes intuitives. NVM vous protège contre les conflits de versions en isolant les environnements.

‍

NVM garantit que vos projets restent compatibles avec la version de Node.js sur laquelle ils ont été développés. Vous pouvez également mettre à jour vos projets en douceur sans crainte de problèmes de compatibilité.

‍

En automatisant la gestion des versions de Node.js, NVM vous permet de vous concentrer sur le développement plutôt que sur la résolution de problèmes de version. C'est un gain de temps précieux.

‍

En comprenant ces points, vous serez mieux préparé à tirer parti de Node Version Manager (NVM) dans votre travail de développement Node.js.

‍

Installation de Node Version Manager

‍

L'installation de Node Version Manager (NVM) est la première étape essentielle pour gérer vos versions Node.js. Cette section vous guidera à travers le processus d'installation sur différentes plateformes : 

‍

• Linux : Utilisez la commande wget pour récupérer NVM depuis GitHub. Suivez notre guide étape par étape pour une installation sans faille.

‍

• macOS : Apprenez comment installer NVM sur macOS en utilisant la commande curl. Suivez nos instructions pour garantir une installation réussie.

‍

• Windows : Si vous êtes sur Windows, découvrez comment installer NVM en utilisant des outils tels que Git Bash ou Windows Subsystem for Linux (WSL).

‍

Après l'installation, nous vous montrerons comment configurer NVM pour une utilisation optimale. Vous serez prêt à commencer à gérer vos versions Node.js avec aisance.

‍

Familiarisez-vous avec les commandes de base de NVM, telles que nvm --version pour vérifier la version installée, nvm ls pour afficher les versions disponibles et nvm install pour installer une version spécifique.

‍

Suivez les instructions détaillées dans cette section pour installer NVM sur votre plateforme de choix. Vous serez rapidement opérationnel pour gérer vos versions Node.js de manière fluide.

‍

Utilisation de NVM pour installer la dernière version LTS de Node.js

‍

Maintenant que vous avez installé Node Version Manager (NVM), apprenons comment utiliser cet outil pour installer la dernière version LTS (Long Term Support) de Node.js.

‍

Avant de procéder à l'installation, il est essentiel de savoir quelles versions LTS de Node.js sont disponibles. Vous pouvez le faire en utilisant la commande nvm ls-remote --lts.

‍

Suivez ces étapes simples pour installer la dernière version LTS :

1. Exécutez nvm install --lts pour installer la dernière version LTS disponible.
2. Pour vérifier que l'installation a réussi, utilisez node --version pour afficher la version de Node.js installée.

‍

Si vous souhaitez que la dernière version LTS soit la version par défaut utilisée par NVM, exécutez nvm alias default <version>.

‍

Grâce à ces étapes simples, vous pouvez désormais installer et utiliser la dernière version LTS de Node.js avec facilité en utilisant Node Version Manager (NVM). Cela vous permettra de bénéficier des avantages de stabilité et de support à long terme pour vos projets Node.js.

‍

Gestion de multiples versions de Node.js avec NVM

‍

La gestion de plusieurs versions de Node.js est une nécessité pour de nombreux développeurs. Voici comment utiliser Node Version Manager (NVM) pour gérer efficacement ces versions.

‍

Pour voir toutes les versions de Node.js installées sur votre système, utilisez simplement la commande nvm ls. Vous obtiendrez une liste claire de toutes les versions disponibles.

‍

Pour basculer entre les versions, utilisez la commande nvm use <version>. Cela changera votre environnement de développement pour utiliser la version spécifiée.

‍

Vous pouvez également créer des alias pour des versions spécifiques avec nvm alias <alias> <version>. Cela simplifie encore la gestion des versions.

‍

Avec ces commandes simples, vous pouvez gérer facilement plusieurs versions de Node.js sur votre système, en utilisant Node Version Manager (NVM). Cela vous permet de maintenir la compatibilité de vos projets et de travailler sur des versions spécifiques selon vos besoins.

‍

Mettre à jour Node.js avec NVM

‍

Maintenir votre installation Node.js à jour est crucial pour bénéficier des dernières fonctionnalités et correctifs de sécurité. Voici comment effectuer des mises à jour en utilisant Node Version Manager (NVM).

‍

Pour vérifier si des mises à jour sont disponibles, exécutez nvm ls-remote <version>. Cela affichera les versions de Node.js disponibles à la mise à jour.

‍

Pour mettre à jour Node.js vers la dernière version LTS disponible, utilisez nvm install --lts. Cela installera la dernière version LTS sans affecter vos versions précédentes.

‍

Si vous avez une version spécifique que vous souhaitez mettre à jour, utilisez nvm install <version> pour obtenir la dernière version de cette branche.

‍

En utilisant ces commandes simples, vous pouvez maintenir votre installation Node.js à jour avec facilité, en garantissant que vos projets sont toujours optimisés en termes de performances et de sécurité.

‍

Exemples pratiques et code source

‍

Dans cette section, nous explorerons quelques exemples pratiques d'utilisation de Node Version Manager (NVM) avec des extraits de code source pour une meilleure compréhension.

Exemple 1 : Installation de Node.js LTS

‍

‍

Cette commande installe la dernière version LTS de Node.js.

‍

Exemple 2 : Basculer vers une version spécifique

‍

‍

Utilisez cette commande pour basculer vers une version spécifique de Node.js (dans cet exemple, la version 14.17.6).

‍

Exemple 3 : Créer un alias pour une version

‍

‍

Créez un alias pour définir une version spécifique de Node.js comme version par défaut.

‍

Exemple 4 : Vérifier les versions installées

‍

‍

Cette commande affiche la liste des versions de Node.js installées sur votre système.

‍

Exemple 5 : Mise à jour de Node.js

‍

‍

Mettez à jour Node.js vers la dernière version (ici, la version actuelle) tout en conservant les packages de la version précédente.

‍

Utilisez ces exemples pratiques et extraits de code source pour mieux comprendre comment utiliser NVM dans vos projets Node.js. Cela vous aidera à gérer efficacement les versions et à optimiser votre environnement de développement web.

‍

Les meilleures pratiques de gestion des versions Node.js

‍

Pour tirer le meilleur parti de Node Version Manager (NVM) et maintenir un environnement de développement Node.js efficace, suivez ces meilleures pratiques :

• Gardez NVM à jour : Pensez à mettre à jour régulièrement NVM pour bénéficier des dernières améliorations et corrections de bogues.

• Utilisez les versions LTS : Privilégiez les versions LTS (Long Term Support) pour une stabilité à long terme. Cela garantit que vos projets restent stables et sécurisés.

• Créez des alias significatifs : Lors de la création d'alias pour des versions spécifiques, choisissez des noms significatifs pour vous faciliter la gestion.

• Documentez vos projets : Tenez un journal des versions utilisées pour chaque projet afin de garantir une compatibilité continue.

• Gérez les dépendances avec npm : N'utilisez pas NVM pour gérer les dépendances de vos projets. Utilisez npm pour gérer les packages Node.js spécifiques à chaque projet.

• Restez informé : Suivez les annonces de nouvelles versions Node.js et les mises à jour de sécurité pour rester au courant des dernières avancées.

‍

En suivant ces meilleures pratiques, vous optimiserez votre gestion des versions Node.js avec NVM et garantirez la stabilité, la sécurité et la facilité de gestion de vos projets.

‍

Dans cet article, nous avons exploré en détail l'utilisation de Node Version Manager (NVM) pour la gestion des versions Node.js. Que vous soyez un développeur expérimenté ou que vous découvriez Node.js, NVM est un outil essentiel pour maintenir un environnement de développement propre et efficace.

‍

Nous avons abordé les étapes clés, de l'installation de NVM sur différentes plateformes à la gestion de multiples versions de Node.js, en passant par les mises à jour et les meilleures pratiques. En utilisant NVM, vous pouvez facilement basculer entre les versions, maintenir la compatibilité de vos projets et garantir la sécurité de votre environnement de développement.

‍

Les exemples pratiques et les extraits de code source ont été fournis pour vous aider à mieux comprendre comment utiliser NVM dans vos projets. En suivant les meilleures pratiques recommandées, vous pouvez maintenir un environnement de développement Node.js optimal.

‍

En fin de compte, Node Version Manager (NVM) est un outil puissant qui facilite grandement la gestion des versions Node.js. Il vous permet de rester à jour avec les dernières versions, d'adapter vos projets aux besoins spécifiques et de maintenir un flux de travail de développement efficace. Intégrez NVM dans votre boîte à outils de développement Node.js dès aujourd'hui pour une expérience de développement plus fluide et plus productive.

‍

Maintenant que vous savez correctement utiliser NVM, nous vous invitons à consulter notre guide complet sur l’outil de gestion de versions Git.

‍

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 :

‍

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 :

‍

‍

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.

‍

Dans l'article précédent nous avons initialisé notre monorepo, la CI, le framework de test et préparé la structure de notre projet et plus précisément de notre Architecture Hexagonale pour la lib core.

Dans ce nouvel article de la série notre objectif va être de mettre en place l'Architecture Hexagonale et de montrer comment grâce à elle nous allons pouvoir développer et créer de la logique métier sans UI (donc sans ouvrir le navigateur ou l'app mobile). Pour cela nous allons travailler en TDD (Test-Driven Development, vous pouvez voir mon article à ce sujet) et utiliser le feedback des tests.

‍

L'Architecture Hexagonale

‍

La structure cible

Pour rappel, voici la structure que l'on va mettre en place à l'issue de cet article :

- src
    - wallet
       - __ tests __
‍         - wallet.service.test.ts
       - domain
‍         - wallet.ts
‍         - wallet.repository.ts
‍         - wallet.service.ts
       - infrastructure
         - in-memory-wallet.repository.ts
         - local-storage-wallet.repository.ts
         - mmkv-wallet.repository.ts
       - user-interface
‍         - wallet.store.ts

‍

Chose promise, chose due ! Nous allons maintenant rentrer dans le détail de chaque fichier, à quoi ils servent et ce qu'ils contient.

‍

Développer en TDD

‍

Lorsqu'on travaille en TDD on commence par le test et ce test va nous guider vers un objectif. Il va nous assurer qu'on suit le bon chemin à l'aide de la boucle de feedback régulière qu'on obtient à l'aide des tests. Pour en savoir plus sur la méthodologie à suivre pour faire du TDD je vous invite à nouveau à lire mon article à ce sujet.

Nous allons commencer par travailler sur l'entité Wallet qui correspond à un portefeuille qui a un solde négatif ou positif (par exemple on peut avoir le portefeuille "Compte Principal Julien" qui a un solde positif de 1000€).

Voici les tests mis en place pour cette entité :

describe('Wallet Service', () => {
	let service: WalletService

	beforeEach(() => {
		const repository = new InMemoryWalletRepository()
		service = new WalletService(repository)
	})

	test('getAll > should retrieve all wallets', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }

		await service.create(newWallet)
		const retrievedWallets = await service.getAll()

		expect(retrievedWallets).toEqual([newWallet])
	})

	test('get > should retrieve a wallet according to an id', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }

		await service.create(newWallet)
		const retrievedWallet = await service.get(newWallet.id)

		expect(retrievedWallet).toEqual(newWallet)
	})

	test('create > shoudl create a wallet', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }

		const createdWallet = await service.create(newWallet)
		const retrievedWallets = await service.getAll()
		const retrievedWallet = await service.get(createdWallet.id)

		expect(createdWallet).toEqual(newWallet)
		expect(retrievedWallets).toEqual([newWallet])
		expect(retrievedWallet).toEqual(newWallet)
	})

	test('update > should update the specified wallet', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }
		const updatedWallet = { id: '1', name: 'Wallet 1', balance: 100 }

		await service.create(newWallet)
		const retrievedWallet = await service.get(newWallet.id)
		const modifiedWallet = await service.update(updatedWallet)
		const retrievedModifiedWallet = await service.get(modifiedWallet.id)

		expect(retrievedWallet).toEqual(newWallet)
		expect(modifiedWallet).toEqual(updatedWallet)
		expect(retrievedModifiedWallet).toEqual(updatedWallet)
	})

	test('delete > should delete a wallet according to an id', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }

		await service.create(newWallet)
		const retrievedWallet = await service.get(newWallet.id)
		await service.delete(newWallet.id)
		const retrievedWallets = await service.getAll()

		expect(retrievedWallet).toEqual(newWallet)
		expect(retrievedWallets).toEqual([])
	})
})

‍

‍

On peut comprendre via ces tests que les cas d'utilisations de notre entité sont :

• getAll, récupération de tous les portefeuilles
• get, récupération d'un portefeuille en particulier
• create, création d'un portefeuille
• update, mise à jour d'un portefeuille
• delete, suppression d'un portefeuille

Nous allons voir maintenant comme réussir à mettre en place ces tests.

‍

Domain

‍

Nous allons commencé par créer le contenu de la partie Domain. Dans cette partie nous allons retrouver tout ce qui représente le problème à résoudre (problème métier). C'est une partie qui doit être totalement indépendante.

‍

L'entité

‍

Commençons par créer notre entité Wallet correspondant à un portefeuille.

type Wallet = {
	// un identifiant unique (ex: 4d0c2e72-be1a-4e2c-a189-2f321fcdc3a4)
	id: string

	// un nom (ex: Compte Principal Julien)
	name: string

	// un nombre positif ou négatif pour le solde (ex: +1000€)
	balance: number
}

‍

‍


Le repository

‍

Maintenant que notre entité est définie, nous allons définir une interface que l'on appelle également port qui va préciser comment interagir avec cette entité. Nous utilisons ici un modèle de conception d'inversion de dépendances qui nous permet de rester totalement libre sur les outils à utiliser pour respecter cette interface. Nous pourrons très bien implémenté cette interface en utilisant une base de données, une API ou un localStorage par exemple, le domaine s'en fiche.

interface WalletRepository {
	getAll(): Promise
	get(walletId: string): Promise
	create(wallet: Wallet): Promise
	update(wallet: Wallet): Promise
	delete(walletId: string): Promise
}

‍

Le service

‍

Nous avons notre entité et nous savons commencer interagir avec, maintenant nous allons créer un service qui va consumer une implémentation du de notre interface repository (partie suivante dans l'infrastructure).

class WalletService implements WalletRepository {
	constructor(private repository: WalletRepository) {}

	getAll() {
		return this.repository.getAll()
	}

	get(walletId: string) {
		return this.repository.get(walletId)
	}

	create(wallet: Wallet) {
		return this.repository.create(wallet)
	}

	update(wallet: Wallet) {
		return this.repository.update(wallet)
	}

	delete(walletId: string) {
		return this.repository.delete(walletId)
	}
}

‍

Infrastructure

L'infrastructure est composée des différentes implémentations des ports du domaine, on les appelle également Adapters. Ici, nous aurons du code spécifique pour consommer une technologie concrète (une base de données, une API, etc.). C'est une partie qui ne doit dépendre uniquement du domaine.

‍

L'implémentation du repository

Nous allons maintenant voir l'une des implémentation possible de notre WalletRepository. Pour commencer nous allons faire du in-memory, pratique notamment pour la mise en place des premiers tests de nos cas d'utilisations.

‍

class InMemoryWalletRepository implements WalletRepository {
	private wallets: Wallet[] = []

	getAll() {
		return Promise.resolve(this.wallets)
	}

	get(walletId: string) {
		return Promise.resolve(this.wallets.find((wallet) => wallet.id === walletId))
	}

	create(wallet: Wallet) {
		this.wallets.push(wallet)
		return Promise.resolve(wallet)
	}

	update(wallet: Wallet) {
		const index = this.wallets.findIndex((w) => w.id === wallet.id)
		this.wallets[index] = wallet
		return Promise.resolve(wallet)
	}

	delete(walletId: string) {
		const index = this.wallets.findIndex((w) => w.id === walletId)
		this.wallets.splice(index, 1)
		return Promise.resolve()
	}
}

‍

Comment dis précédemment, il s'agit d'une des multiples implémentation possible de notre WalletRepository. Nous pouvons très bien imaginer plus tard mettre en place un LocalStorageWalletRepository ou bien un SupabaseWalletRepostory.

Vous pouvez consulter mon répertoire public de broney sur GitHub pour voir mon implémentation de ces 2 repository et notamment de comment j'ai adapté ma série de test pour garantir leur bon fonctionnement.

‍

‍

User Interface

‍

La partie user interface est composée de tous les adaptateurs qui constituent les points d'entrée de l'application. Les utilisateurs utilisent ces adaptateurs pour pouvoir interagir avec le coeur de l'application. Dans notre cas nous allons régulièrement utiliser des stores en utilisant la libraire Zustand. Il s'agit d'une libraire JS minimaliste pour la gestion d'états (une solution plus complexe serait par exemple Redux).

‍

Voyons voir comment articuler notre store Zustand pour permettre à l'utilisateur d'interagir avec le coeur de l'application.

‍

import { createStore } from 'zustand/vanilla'
import { InMemoryWalletRepository } from '../infrastructure/in-memory-wallet.repository'
import { WalletService } from '../domain/wallet.service'
import { Wallet } from '../domain/wallet'

const repository = new InMemoryWalletRepository()
const service = new WalletService(repository)

type States = {
	wallets: Wallet[]
	currentWallet: Wallet | undefined
}

type Actions = {
	load: () => void
	setCurrentWallet: (wallet: Wallet) => void
	getWallet: (walletId: string) => void
	createWallet: (wallet: Wallet) => void
	updateWallet: (wallet: Wallet) => void
	deleteWallet: (walletId: string) => void
}

export const walletStore = createStore()((set) => ({
	wallets: [],
	currentWallet: undefined,

	load: async () => {
		const allWallets = await service.getAll()
		set({ wallets: allWallets })
	},

	setCurrentWallet: (wallet) => set({ currentWallet: wallet }),

	getWallet: async (walletId: string) => {
		const wallet = await service.get(walletId)
		set({ currentWallet: wallet })
	},

	createWallet: async (wallet: Wallet) => {
		const newWallet = await service.create(wallet)
		set((state) => ({ wallets: [...state.wallets, newWallet] }))
	},

	updateWallet: async (wallet: Wallet) => {
		const updatedWallet = await service.update(wallet)
		set((state) => ({
			wallets: state.wallets.map((w) => (w.id === updatedWallet.id ? updatedWallet : w)),
			currentWallet: state.currentWallet?.id === updatedWallet.id ? updatedWallet : state.currentWallet,
		}))
	},

	deleteWallet: async (walletId: string) => {
		await service.delete(walletId)
		set((state) => ({
			wallets: state.wallets.filter((w) => w.id !== walletId),
			currentWallet: state.currentWallet?.id === walletId ? undefined : state.currentWallet,
		}))
	},
}))

‍


Avec ce store on remarque qu'on va pouvoir facilement, dans n'importe quel environnement JavaScript, charger, définir, récupérer, créer, mettre à jour et supprimer des portefeuilles, tout en maintenant un état global pour l'ensemble des portefeuilles et du portefeuille courant.

‍

‍

Conclusion

Nous avons maintenant terminé ce deuxième article de cette série sur le développement d'une application web et mobile avec l'Architecture Hexagonale et le partage de la logique métier et des composants UI.

Dans cette deuxième partie nous avons vu comment travailler en TDD et surtout comment écrire de la logique métier sans avoir à ouvrir une quelque interface à l'exception du terminal pour les retours de tests.

Nous avons également eu un aperçu de comment nous allons interagir avec nos applications avec le coeur de l'application, via notre store Zustand. Nous irons plus loin à ce sujet dans le prochain article, la troisième partie : Partager de la logique métier et des composants entre le Web et le Mobile.

‍

‍

Introduction

‍

En tant que développeurs, nous savons que les projets évoluent constamment : les besoins changent, les designs se métamorphosent et les spécifications initiales peuvent rapidement devenir obsolètes.

Face à cet environnement mouvant, nos composants traditionnels montrent parfois leurs limites. Ils ne sont pas tous adaptés pour faire face de manière flexible et robuste à cette évolution constante.

Qui n'a jamais été frustré par un composant trop rigide pour s'accommoder d'un changement de maquette ou d'une mise à jour des exigences du projet ?

‍

Examinons ensemble, deux exemples, pour illustrer le Design Pattern : Compound Components.

‍

‍

‍

Exemple d’un composant d’UI simple ✏️

Supposons que nous devons créer un composant Card tout ce qu’il y a de plus classique. On a besoin d’affiche un title, une description et un thumbnail.

Voilà une implementation simple de ce que pourrait être ce composant :

// card.tsx

type CardProps = {
	title: string;
	description: string;
	thumbnail: string;
}

function Card({ title, description, thumbnail }: CardProps) {
	return (
		<View>
			<Image source={{ uri: thumbnail }} />
			<Text>{title}</Text>
			<Text>{description}</Text>
		</View>
	)
}

‍

Ainsi que son usage :

‍

// home.tsx

function HomeScreen() {
	return (
		<View>
			<Card
				title="Lorem ipsum"
				description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				thumbnail="https://picsum.photos/200/300"
			/>
		</View>
	)
}

‍

Jusque là, tout va bien, notre composant est simple à développer, simple à utiliser et facile à relire.

‍

Maintenant, comme dans tous les projets, le besoin évolue et le design de nos composants avec. Admettons, que notre besoin a évolué de façon à ce qu’on ai besoin d’ajouter un bouton sur notre composant Card. Mais, ce bouton ne doit pas apparaître à tous les endroits de mon application.

‍

Ce que l’on va retrouver dans la plupart des projets professionnels aujourd’hui, c’est une surcharge de propriétés sur le composant. Le plus souvent, notre composant serait comme suit :

‍

// card.tsx

type CardProps = {
	title: string;
	description: string;
	thumbnail: string;
	buttonLabel?: string;
	showButton?: boolean;
	onPressButton?: () => void;
}

function Card({ 
	title, 
	description, 
	thumbnail,
	buttonLabel,
	showButton = false,
	onPressButton
}: CardProps) {
	return (
		<View>
			<Image source={{ uri: thumbnail }} />
			<Text>{title}</Text>
			<Text>{description}</Text>
			{showButton && <Button label={buttonLabel} onPress={onPressButton} />}
		</View>
	)
}

‍


NB : c’est volontairement exagéré pour mettre en avant le problème. Même sans Compound Components que l’on verra après, on pourra avoir un composant bien plus propre !

‍

Et l’usage du composant serait comme suit :

‍

// home.tsx

function HomeScreen() {
	return (
		<View>
			<Card
				title="Lorem ipsum"
				description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				thumbnail="https://picsum.photos/200/300"
			/>
			<Card
				title="Lorem ipsum"
				description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				thumbnail="https://picsum.photos/200/300"
				buttonLabel="Lorem"
				onPressButton={() => { /* ... */}}
				showButton
			/>
		</View>
	)
}

‍


Observations

Que peux-tu observer sur cet exemple de composant “traditionnel” qui ne représente que de l’UI ?

‍

1. Structure rigide
   ‍Le composant Card a une structure définie, il contient toujours une image, un titre, une description et un bouton. Il n’y a flexibilité pour changer la structure d’un composant en fonction des besoins.
   ‍
2. Passage de props
   ‍Toutes les données dont le composant Card a besoin sont passées via les props. Cela peut devenir encombrant et difficile à maintenir à mesure que nous ajoutons plus de props au composant.
   ‍
3. Moins de réutilisabilité
   ‍Les sous-composants ne peuvent pas être réutilisés indépendamment. Par exemple, si nous voulons utiliser seulement le bouton ou l'image de la carte dans un autre composant, cela ne serait pas possible.
   ‍
4. Peu extensible
   ‍Ajouter de nouvelles fonctionnalités à la carte nécessite une modification de l'implémentation de la carte elle-même, augmentant potentiellement le risque de créer des bugs non liés.
   ‍
5. Simplicité
   ‍Cependant, dans certains cas, cette approche peut être préférable pour sa simplicité. Si votre composant est très simple et n'a pas besoin des avantages offerts par le pattern de Compound Components, le surcoût en complexité peut ne pas en valoir la peine.

‍

‍

Exemple d’un composant plus complexe ✏️

Supposons maintenant que nous devons créer un composant plus complexe, des composants mêmes, qui ont besoin de travailler ensuite pour mettre en oeuvre une fonctionnalité de Todo-list.

‍

Pour cela, nous allons avoir les composants TodoList (pour afficher une liste d’item de todo), TodoItem (qui représente un item de todo), TodoForm (qui représente le formulaire d’un item de todo) et TodoStats (qui affiche des statistiques pour une liste de todo donnée).

‍

Voilà une implementation de ce que pourrait être ces composants :

‍

// todo-list.tsx

type TodoListProps = {
	todos: Array<{ id: string; content: string }>;
	onPressDelete: (id: string) => void;
}

function TodoList({ todos, onPressDelete }: TodoListProps) {
	return (
		<View>
			{todos.map((todo) => (
				<TodoItem 
					key={todo.id} 
					id={todo.id} 
					content={todo.content}
					onPressDelete={onPressDelete}
				/>
			)}
		</View>
	)
}

// todo-item.tsx

type TodoItemProps = {
	id: string;
	content: string;
	onPressDelete: (id: string) => void;
}

function TodoItem({ id, content onPressDelete }: TodoListItemProps) {
	return (
		<View>
			<Text>{content}</Text>
			<Button label="Delete" onPress={() => onPressDelete(id)} />
		</View>
	)
}

// todo-form.tsx

type TodoFormProps = {
	onPressSubmit: (content: string) => void;
}

function TodoForm({ onPressSubmit }: TodoFormProps) {
	const [value, setValue] = useState<string>('')
	
	return (
		<View>
			<TextInput value={value} onChangeText={setValue} />
			<Button label="Add" onPress={() => onPressSubmit(value)} />
		</View>
	)
}

// todo-stats.tsx

type TodoStatsProps = {
	todos: Array<{ id: string; content: string }>;
}

function TodoStats({ todos }: TodoStatsProps) {
	return (
		<View>
			<Text>Sum of todos: {todos.length}</Text>
			{/* average number of characters */}
			{/* ... */}
		</View>
	)
}

‍


Ainsi que l’usage de ces composants :

‍

// home.tsx

function HomeScreen() {
	const [todos, setTodos] = useState([])
	
	return (
		<View>
			<TodoList 
				todos={todos} 
				onPressDelete={(id) => 
					setTodos((state) => state.filter(todo) => todo.id !== id
				}
			/>
			<TodoStats todo={todos} />
			<TodoForm 
				onPressSubmit={(content) =>
					setTodos((state) => [...state.todos, { id: uuid(), content }])
				} 
			/>
		</View>
	)
}

‍


Observations

Que peux-tu observer sur cet exemple de composant “traditionnel” qui ne représente cette fois une fonctionnalité plus complexe ?

‍

1. Rigidité
   ‍Dans l'état actuel, la structure est assez rigide. Par exemple, si vous voulez une autre variante de TodoItem qui a un bouton pour marquer une tâche comme terminée, ou peut-être une variante de TodoForm qui a des champs supplémentaires, l'adaptation de ces composants à ces scénarios serait plus complexe.
   ‍
2. Passage de props
   ‍Les fonctions de suppression et d'ajout sont transmises en tant que props aux composants enfants TodoItem et TodoForm depuis le composant parent HomeScreen. Cela peut devenir compliqué à gérer à mesure que l'application s'agrandit, car chaque fois que vous voulez utiliser ces fonctions, vous devez les transmettre à travers tous les composants intermédiaires.
   ‍
3. Manque d’encapsulation
   ‍Les composants TodoItem et TodoForm exposent trop de détails d'implémentation. Par exemple, TodoItem a besoin de connaître non seulement le contenu de la tâche, mais aussi son id et comment traiter une action de suppression. De même, TodoForm doit gérer son propre état et savoir comment gérer une action de soumission. Cela pourrait être évité avec une version composée qui masquerait ces détails.
   ‍
4. Peu extensible et peu lisible
   ‍Ce point est suffisamment explicite je pense !

‍

‍

Le Design Pattern : Compound Components 👀

‍

Le Design Pattern : Compound Components s’applique à n’importe quel langage fonctionnant avec des composants et de la gestion d’états. Il s’agit d’une approche qui offre :

‍

1. Structure
   ‍Le terme "Compound Components" décrit une relation "a un" entre les composants. Un composant comporte plusieurs sous-composants qui travaillent ensemble pour former une unité cohérente. Le composant parent sert de composant de mise en page tandis que les sous-composants déterminent le contenu.
   ‍
2. Flexibilité
   ‍Les Compound Components offrent une grande flexibilité dans l'arrangement des sous-composants. Les utilisateurs de cette API de composant peuvent contrôler l'organisation, la structure et la présentation d'un composant.
   ‍
3. Abstraction
   ‍Ils permettent une bonne séparation des préoccupations car chaque sous-composant traite une fonctionnalité particulière. Cela permet une meilleure réutilisation des composants et simplifie le test et la maintenance.
   ‍
4. Pas de passage de props
   ‍Un avantage majeur du modèle de Compound Components est l'évitement du prop-drilling, qui est un problème où des props doivent être passés à travers de nombreux niveaux de composants. Les Compound Components résolvent ce problème en utilisant le contexte React pour partager la valeur entre les composants.
   ‍
5. Encapsulation
   ‍Avec les Compound Components, nous pouvons exposer ce qui est nécessaire et masquer les détails d'implémentation spécifiques. Cela aide à produire un code plus clair et plus facile à maintenir.

‍

Mise en pratique

‍

Maintenant, voyons ensemble un refactor de nos composants précédents en version Compound Components.

‍

‍

Le composant d’UI simple en Compound Components

Reprenons notre composant d’UI simple et convertissons les props title, description, etc. en sous-composants pour en faire une composition comme suit :

‍

// card.tsx

type CardProps = PropsWithChildren

function Card({ children }: CardProps) {
	return <View>{children}</View>
}

Card.Title = CardTitle
Card.Description = CardDescription
Card.Thumbnail = CardThumbnail
Card.Button = CardButton

// card-title.tsx

type CardTitleProps = {	title: string }

function CardTitle({ title }: CardTitleProps) {
	return <Text>{title}</Text>
}

// card-description.tsx

type CardDescriptionProps = {	description: string }

function CardDescription({ description }: CardDescriptionProps) {
	return <Text>{description}</Text>
}

// card-thumbnail.tsx

type CardThumbnailProps = {	source: string }

function Card({ source }: CardThumbnailProps) {
	return <Image source={{ uri: thumbnail }} />
}

// card-button.tsx

type CardButtonProps = {
	label: string;
	onPress: () => void;
}

function CardButton({ label, onPress }: CardButtonProps) {
	return <Button label={label} onPress={onPress} />
}

‍


Et maintenant l’usage :

‍

// home.tsx

function HomeScreen() {
	return (
		<View>
			<Card>
				<Card.Thumbnail source="https://picsum.photos/200/300" />
				<Card.Title title="Lorem ipsum" />
				<Card.Description 
					description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				/>
			</Card>
			<Card>
				<Card.Thumbnail source="https://picsum.photos/200/300" />
				<Card.Title title="Lorem ipsum" />
				<Card.Description 
					description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				/>
				<Card.Button label="Lorem" onPress={() => { /* ... */}} />
			</Card>
		</View>
	)
}

‍


Observations

Quelles observations peux-tu faire cette fois ci ?

‍

1. Flexibilité
   ‍Le Compound Components donne un plus grand contrôle sur l'organisation des éléments dans le rendu. Dans le deuxième exemple d'utilisation, nous avons de l'information supplémentaire et une absence de bouton, ce qui ne serait pas possible avec une version non composée du composant qui limiterait strictement la structure.
   ‍
2. Réutilisabilité
   ‍Les sous-composants, comme CardTitle, CardImage, et CardContent peuvent être réutilisés et réarrangés librement. Cette approche réduit la duplication du code et accroît la maintenabilité.
   ‍
3. Lisibilité
   ‍Le code est plus facile à comprendre. Alors qu'un composant non composé pourrait avoir un grand nombre de props, ce qui pourrait rendre le code plus difficile à suivre, chaque sous-composant sait clairement quel est son rôle dans le composant de carte.
   ‍
4. Isolation
   ‍Les sous-composants (comme CardButton ou CardImage) peuvent être mis à jour indépendamment des autres sous-composants, évitant ainsi les effets de bord inattendus.
   ‍
5. Scalabilité
   ‍Les nouveaux sous-composants peuvent être ajoutés facilement en suivant cette approche, permettant au composant de s'adapter et de se développer avec le temps. Par exemple, un sous-composant CardFooter pourrait être ajouté si besoin.

‍

Le composant complexe en Compound Components

Enfin, passons au plus intéressant, le groupe de composant qui représente la fonctionnalité de Todo-list, voilà la version Compound Components :

‍

// home.tsx

function HomeScreen() {
	return (
		<View>
			<Card>
				<Card.Thumbnail source="https://picsum.photos/200/300" />
				<Card.Title title="Lorem ipsum" />
				<Card.Description 
					description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				/>
			</Card>
			<Card>
				<Card.Thumbnail source="https://picsum.photos/200/300" />
				<Card.Title title="Lorem ipsum" />
				<Card.Description 
					description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				/>
				<Card.Button label="Lorem" onPress={() => { /* ... */}} />
			</Card>
		</View>
	)
}

‍

Ainsi que son usage, drastiquement simplifiée :

‍

// home.tsx

function HomeScreen() {
	return (
		<View>
			<Todos todos={[]}>
				<Todos.List />
				<Todos.Stats />
				<Todos.Form />
			</Todos>
		</View>
	)
}

‍


Observations

Que peux t-on observer sur cette dernière partie ?

‍

1. Flexibilité d’affichage
   ‍Avec l'approche de Compound Components, la disposition des composants est beaucoup plus flexible. Vous pouvez choisir de rendre Todos.List, Todos.Form, et Todos.Stats dans n'importe quel ordre ou même de ne pas les afficher en fonction des spécificités des spécifications ou des besoins de votre application.
   ‍
2. Utilisation du Contexte
   ‍Grâce à l'utilisation de React Context (TodosContext), vous pouvez facilement partager des données (todos) et des fonctions (add, remove) entre tous les composants enfants. Cela permet d'éviter le problème de prop-drilling propre à l'approche non compound components.
   ‍
3. Hook personnalisé
   ‍Ils utilisent un hook personnalisé useTodosContext pour obtenir les valeurs du contexte. Ce hook rend le code plus lisible et plus facile à utiliser.
   ‍
4. Réutilisabilité accrue
   ‍Les composants sont désormais plus indépendants et peuvent être facilement réutilisés ailleurs dans l'application. Par exemple, Todos.List pourra être utilisé dans un autre écran ou dans une sidebar sans avoir besoin de passer d'informations supplémentaires via les props.
   ‍
5. Extensibilité
   ‍Avec cette approche, vous pouvez également étendre facilement le composant Todos en ajoutant des sous-composants supplémentaires sans bouleverser l'architecture existante. Par exemple, si vous voulez ajouter une fonctionnalité pour marquer les tâches comme faites, vous pourriez créer un nouveau sous-composant Todos.Checkbox.

‍

Le mot de la fin 👋

‍

De manière générale, le composant “traditionnel” est plus simple, mais il offre moins de flexibilité et de potentiel de réutilisation que le Compound Components. Le choix entre les deux approches dépend des besoins spécifiques du projet. Mais de mon experience, partir direct sur du Compound Components est rarement une mauvaise idée !

‍

Les inconvénients potentiels de cette approche sont qu'elle est plus complexe et qu'elle nécessite une compréhension plus approfondie des concepts de React (pour le cas de React), tels que le Contexte et les Compound Components eux-mêmes. De plus, il est important de noter que bien que le Context puisse sembler être une solution à tous les problèmes, il doit être utilisé avec parcimonie pour éviter un couplage excessif entre les composants de votre application.

‍

L'adoption du pattern Compound Components dans la conception d'interfaces utilisateur peut sembler déroutante au début, mais les avantages qu'elle offre en termes de modularité, de flexibilité et de réutilisabilité sont indéniables. Ainsi, en décomposant intelligemment les composants en des sous-éléments logiques, nous pouvons produire des systèmes d'UI flexibles, réutilisables et gérables.

‍

Vous pouvez retrouvez cet article au format vidéo sur YouTube en suivant ce lien.

‍