Design Pattern : Compound Components

Nos composants traditionnels montrent parfois leurs limites. Ils ne sont pas tous adaptés pour faire face de manière flexible et robuste à l'évolution constante.

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.

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

Ne manquez rien
Abonnez-vous à notre newsletter

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

Nos experts vous parlent
Le décodeur

5 applications web impressionnantes développées avec Laravel
18/4/2024

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.

Test Driven Development (TDD) : Guide pour un Développement Efficace
21/9/2023

L'origine


Le Test-Driven Development plus communément appelé TDD n'a pas été inventé par une seule personne mais par plusieurs développeurs. Kent Beck est souvent la personne la plus affiliée au TDD parce qu'il est celui qui l'a popularisé lors de ses travaux sur la méthodologie Extreme Programming à la fin des années 90. Néanmoins il est important de rappeler qu'il n'est pas le créateur de l'outil qu'est le TDD, il a été mis en place pour tout un tas de personne, dont notamment Martin Fowler (co-auteur du Manifeste Agile) ou encore Ward Cunningham et Ron Jeffries qui ont fondé l'Extreme Programming avec Kent Beck.


Un outil de travail


L'outil


Le TDD est un outil de travail qui permet au développeur de coder en étant guidé par les tests. Il permet d'avancer étape par étape, petit pas par petit pas, pour avancer vers une solution toujours plus fiable.


Cette solution plus fiable est notamment due à sa forte proximité avec les principes SOLID. En effet, le TDD facilite la mise en place des principes SOLID. En écrivant d'abord des tests, il est plus naturel de concevoir un code simple et cohérent qui respecte les principes tels que l'encapsulation, le découplage, la gestion des dépendances et la séparation des responsabilités. On se retrouve plus naturellement avec des modules indépendants et l'injection de dépendances, ce qui conduit à du code plus propre.


Le TDD et les principes SOLID vont donc de pair pour une conception logicielle de qualité.



  1. Nous avons une première phase (rouge sur le schéma) où nous devons écrire un test qui échoue, basé sur une spécification. NB : on n'écrit pas de code de production (code final) tant que le test n'est pas en échec.
  2. La deuxième phase (verte sur le schéma) consiste à faire passer le test en succès en écrivant du code de production et tout en restant le plus simple possible. NB : on écrit uniquement le code nécessaire pour faire passer le test et sans retourner dans le code du test.
  3. La dernière phase (bleue sur le schéma) concerne le refactoring. On met à jour le code en appliquant les bonnes pratiques, le clean code, etc. Une fois que le refactoring est fait, si les tests passent toujours, on conserve le refactor et on passe aux prochaines spécifications, sinon, on annule le refactor et on essaye autre chose. NB : ne doit jamais effectuer de refactoring dans les autres phases, seulement ici.


L'approche TDD est un développement itératif et incremental qui met l'accent sur la qualité du code.


Le manifeste


Le TDD respecte certains principes qui sont :


  • Baby steps instead of large-scale changes

On avance petit pas par petit pas pour avoir une boucle de feedback rapide et régulière.


  • Continuous refactoring instead of late quality improvements

On améliore le code en continue, on s'en occupe tout de suite parce qu'un refactor annoncé pour plus tard n'arrive finalement en général jamais.


  • Evolutionary design instead of big design up front

On développe ce qui est nécessaire et suffisant et on évolue progressivement.


  • Executable documentation instead of static documents

Les tests mis en place pendant le TDD sont en réalité une documentation executable. L'idée est de lier la documentation avec le code pour s'assurer qu'elle est bien à jour et maintenue.


  • Minimalist code instead of gold-plated solution

Un code simple et qui fonctionne plutôt qu'une solution surdimensionnées avec un niveau de complexité bien trop élevé et pas nécessaire.




Le test propre

Given When Then


L'approche Given When Then est basée sur une convention développée dans le cadre du Behaviour-Driven Development autrement appelé BDD. Il s'agit d'une approche de développement axée sur la collaboration et la spécification du comportement à travers ds scénarios clairs et compréhensibles.


En utilisant cette convention on divise le test en trois parties :

  1. Given, la condition préalable au test
  2. When, l'exécution du système testé
  3. Then, le comportement attendu


Exemple : Given user is not logged in When user logs in Then user is logged in successfully


Should When


L'approche Should When est une convention de nommage facile à lire et plus largement utilisée.


En utilisant cette convention on divise le test en deux parties :

  1. When, la condition préalable au test
  2. Should, le comportement attendu


Exemple : Should have user logged in When user logs in


Arrange Act Assert


Le modèle Arrange Act Assert autrement appelé AAA est un pattern descriptif et révélateur des intentions pour structurer le test.


Le test est alors organisé de la manière suivante :

  1. La partie Arrange contient la logique de configuration du test. C'est ici qu'on initialise le test.
  2. La partie Act execute le système que l'on souhaite tester. C'est ici qu'on fait l'appel d'une fonction, d'un composant, d'un call API, etc.
  3. La partie Assert, vérifie que le système testé se comporte comme prévu. C'est ici qu'on vérifie que le résultat obtenu correspond au résultat attendu.


Exemple :




F.I.R.S.T.


Le principe F.I.R.S.T. est un ensemble de principes qui définissent les caractéristiques d'un test propre et de qualité.


Ces caractéristiques sont les suivantes :

  • Fast, un test doit être rapide et efficace de manière à pouvoir être exécuté fréquemment pour avoir un feedback régulier
  • Independent, les tests doivent être indépendants les uns des autres afin d'être exécutable individuellement et efficacement
  • Repeatable, un test doit être répétable dans n'importe quel environnement et à tout moment
  • Self-Validating, les tests doivent retourner un succès ou un échec afin de vérifier lui même si l'exécution du test a réussi ou échoué sans évaluation manuelle
  • Timely, les tests doivent être écrit avant ou en même temps que le code de production. ils doivent être maintenus et exécutés régulièrement


Quand l'utiliser ?


Quand ne pas l'utiliser plutôt !


Il n'est pas nécessaire et pas utile de faire du TDD quand on a pas de spécifications, quand les tests n'apportent rien, quand les tests sont trop lents, quand il n'y a pas de logique.


La démo


L'incontournable Fizz Buzz


Le Fizz Buzz est un exercice populaire qui permet d'appréhender la méthode TDD. Ce n'est qu'un échantillon et qu'un début de la méthode, mais ça reste intéressant.


Les spécifications sont les suivantes :

  • On commence à compter à partir de 1 jusqu'à 100
  • Lorsqu'on rencontre un nombre divisible par 3, on retourne "Fizz"
  • Lorsqu'on rencontre un nombre divisible par 5, on retourne "Buzz"
  • Lorsqu'on rencontre un nombre divisible par 3 et par 5, on retourne "Fizz-Buzz"


Nous allons utiliser le TypeScript pour mettre en place cet algorithme et le tester.


Première spécification


On créé un fichier test fizz-buzz.test.ts et on créé notre premier test qui va gérer la spécification où on teste le nombre 1.





Ici, le test ne passe pas parce qu'on a pas encore créé la fonction fizzBuzz() et encore moins l'algorithme associé. Nous sommes donc à la première phase du TDD, la phase rouge, celle où on écrit un test qui échoue.


On va maintenant passer à la deuxième phase du TDD, celle où on va faire passer le test au vert. Pour cela, on va créer le fichier fizz-buzz.ts et écrire le code permettant de gérer notre cas de spécification.




Ici, on pourrait avoir tendance à faire un return String(n) directement, mais TDD nous dit de commence par écrire le code le plus simple possible pour faire passer le test au vert, et en réalité le plus simple et rapide et de tout simplement retourner 1 directement.


On va passer au prochain test qui est de tester l'input 2.



Le test échoue parce qu'on a pas encore géré ce cas dans notre fonction. On retourne donc dans notre fonction et on essaye de résoudre ce cas de la manière la plus simple et rapide.




Ici, encore une fois, le plus rapide est de retourner 2 si on a 2 en input.


Maintenant on arrive à la troisième et dernière phase du TDD, celle du refactor. En effet, actuellement nos tests passent avec succès, le code est simple, mais il pourrait l'être encore plus en appliquant de bonnes pratiques.


On va donc revenir sur notre fonction fizzBuzz() sans modifier les tests.




Notre fonction est maintenant simple, propre et concise et les tests sont toujours verts. Notre refactor est donc réussit, on peut passer à la prochaine spécification.


Deuxième spécification


Nous devons maintenant faire en sorte de retourner Fizz si l'input est divisible par 3.



Le test échoue, on va maintenant gérer le cas du Fizz dans la fonction.




Le code le plus simple pour retourner  Fizz quand on a 3 et de tester si n === 3.


On va maintenant gérer un deuxième cas où on a un nombre divisible par 3.




Le test échoue, on met à jour le code.




Le code le plus simple pour retourner Fizzquand on a 3 ou 6 et de faire un ||, mais on se rend bien compte qu'on peut améliorer le code en utilisant le modulo de 3. Les tests sont tous verts, donc on peut se permettre de passer à la phase de refactor en modifiant uniquement le code de la production.



Refactor terminé, tous les tests sont verts, on peut passer à la prochaine spécification.


Troisième spécification


Nous devons maintenant faire en sorte de retourner Buzz si l'input est divisible par 5.


On va aller un peu plus vite, mais le procédé est le même, on va d'abord faire un test avec un input 5 puis 10, puis refactor.




Dernière spécification


Nous devons maintenant faire en sorte de retourner Fizz-Buzz si l'input est divisible par 3 et par 5.


Comme pour les spécifications précédentes, on va faire un test avec un input 15 puis 30 et enfin refactor.


Et voilà !


Le mot de la fin


Stop aux amalgames ! Le TDD n'est pas un outil pour avoir une bonne couverture de code avec les tests, ce n'est pas simplement "faire des tests". Le TDD est un outil dont le but est de guider le développeur vers un objectif. Il permet de donner un feedback régulier afin de s'assurer qu'on est toujours sur la bonne voie. Il faut le voir comme un GPS, qui nous donne des directions à suivre (tourner à droite, aller tout droit pendant 2km, etc.) jusqu'à atteindre un objectif.


Les dédicaces


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

Origine

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

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

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

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

Git est structuré comme suit :

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

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

GitHub, GitLab, Bitbucket, etc.

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

Les bases

Git Flow

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

Nous avons donc 2 branches principales :

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

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

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

Conventional Commits

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

Format Conventional Commits

Les types de commits les plus utilisés sont :

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

Workflow : merge vs rebase

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

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

Politique de merge

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

Avantages :

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

Inconvénients :

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

Politique de rebase

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

Avantages :

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

Inconvénients :

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

Nettoyage avec rebase Interactif

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

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

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

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

🧑💻 Démonstration

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

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

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

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

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

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

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

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

Cette commande va ouvrir l’interface suivante :

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

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

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

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

Liens utiles

Échangeons sur votre projet !

Développement web
Application mobile
Design & Product
Nous contacter

Simulateur

Bienvenue dans le
simulateur d’estimation

Sélectionnez
vos besoins

Sélectionnez un ou plusieurs choix

Définissez les
fonctionnalités

Sélectionnez un ou plusieurs choix

Dernière
étape !

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

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

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