Pour qui

• Développeuses et développeurs .NET, web ou applicatif, qui maintiennent une application en production
• Tech leads et architectes qui veulent des critères concrets pour découper une application

Prérequis

• Pratique quotidienne de la programmation orientée objet
• Un environnement .NET installé : Visual Studio 2022 Community ou Rider
• Docker Desktop, facultatif

Objectifs

• Reconnaître dans votre code les symptômes du couplage qui rend chaque modification risquée
• Structurer une application en couches dont le domaine ne dépend de rien
• Séparer lecture et écriture avec CQRS quand le contexte le justifie, et savoir quand il ne le justifie pas
• Écrire des tests unitaires, d'intégration et des scénarios BDD qui protègent le refactoring

Tout le monde a lu un schéma en cercles concentriques. Peu d’équipes arrivent à le mettre en place sur une application qui existe déjà, avec ses contrôleurs de 800 lignes, ses requêtes SQL dans les vues et sa logique métier éparpillée dans quatre couches qui se renvoient la balle.

Cette formation part de là. On ne construit pas une architecture propre sur une page blanche. On part d’un dépôt qui ressemble au vôtre, et on le transforme, étape par étape, en gardant les tests au vert. À la fin des trois jours, vous avez fait le chemin une fois, sur un code que vous avez compris. Vous savez le refaire sur le vôtre.

À quoi vous attendre

L’architecture n’est pas un choix de départ. C’est le résultat de mille petites décisions prises sous pression. La formation vous donne des critères pour les prendre mieux.

Trois principes guident les trois jours :

• On code plus qu’on n’écoute. Chaque demi-journée alterne une courte séquence de concepts et un atelier sur le projet fil rouge. Le formateur code en direct, et vous codez avec lui.
• On refactore, on ne réécrit pas. Le projet fil rouge démarre en MVC et N-Tier classique. Il finit en Clean Architecture avec CQRS et des scénarios BDD. Entre les deux, aucune page blanche.
• Les tests viennent avant l’architecture. Impossible de déplacer du code en confiance sans filet. Le premier atelier de refactoring attend d’avoir un filet de tests.

Les exemples sont en C#. En intra-entreprise, le projet fil rouge peut être remplacé par un extrait de votre propre code, et la formation existe aussi en TypeScript et en PHP.

Programme

Jour 1 : comprendre pourquoi ça fait mal

Matin. L’architecture, un coût caché

• Ce que « architecture » veut dire quand on parle d’une application qui a cinq ans
• Le lien entre structure du code, vitesse de livraison et nombre de bugs en production
• Ce que coûte réellement une mauvaise architecture, et pourquoi personne ne le voit sur une feuille de budget
• Tour de table : les difficultés concrètes que chaque participant rencontre sur son propre code

Matin. Lecture critique d’un dépôt legacy

• Rappel de ce que promettent MVC et N-Tier, et de ce qu’ils tiennent
• Les points de douleur : couplage fort, logique métier dispersée, dépendances qui traversent toutes les couches
• Repérer la dette technique en lisant du code, pas en la mesurant
• Atelier : exploration guidée du projet fil rouge dans son état de départ

Après-midi. Le projet fil rouge

• Présentation du besoin métier et clarification des règles
• Mise en place de la solution .NET et des conventions du reste de la formation
• Atelier : création du squelette de projet

Après-midi. Le filet de tests

• Pourquoi un test automatisé vaut plus qu’un test manuel, même quand il coûte plus cher à écrire
• Tests unitaires, d’intégration et de bout en bout : à quoi sert chacun, et lequel écrire en premier
• Introduction à xUnit et à la structure Arrange, Act, Assert
• Atelier : premiers tests unitaires en TDD sur le projet fil rouge

Jour 2 : séparer ce qui change de ce qui ne change pas

Matin. SOLID sur du vrai code

• Les cinq principes, chacun illustré en C# sur un cas où il aurait évité un bug
• Les antipatterns typiques, et comment ils apparaissent sans que personne ne les ait voulus
• Exercice : identifier les violations dans le projet fil rouge et décider lesquelles corriger

Matin. Ports & Adapters, Clean Architecture, hexagonale

• Ce que MVC et N-Tier ne savent pas faire
• Séparation des préoccupations et inversion des dépendances : le même principe, deux échelles
• Ports & Adapters : le métier définit des interfaces, la technique les implémente
• Clean Architecture : les couches concentriques (domaine, application, infrastructure, interface) et la règle de dépendance
• Atelier : schématiser le projet fil rouge cible avant d’y toucher

Après-midi. Mettre en place Ports & Adapters

• Créer les contrats (les ports)
• Écrire les premiers adaptateurs : en mémoire pour les tests, API pour la production
• Intégrer le code existant sans tout casser
• Substituer une implémentation par une autre, et le vérifier avec un test
• Atelier : migrer un cas d’usage complet vers Ports & Adapters

Après-midi. Évoluer vers la Clean Architecture

• Structurer les couches concentriques
• Faire respecter la règle de dépendance : le domaine ne connaît personne
• Adapter le code existant, et repérer ce qui résiste
• Comparer Ports & Adapters et Clean Architecture : ce qui change, ce qui est une question de vocabulaire
• Atelier : migration du projet fil rouge en Clean Architecture

Jour 3 : lire, écrire, et parler le langage du métier

Matin. CQRS

• Séparer les lectures des écritures : pourquoi, et à partir de quand
• CRUD ou CQRS : ce qui différencie vraiment les deux approches
• Ce que la séparation simplifie, et ce qu’elle complique
• Mise en place des handlers en .NET
• Atelier : un cas d’usage complet en CQRS

Matin. CQRS, la suite

• DTO de commande, DTO de requête : les faire vivre sans dupliquer le domaine
• L’impact sur les tests : ce qui devient plus simple, ce qui bouge
• Savoir dire non : les contextes où CQRS n’apporte rien
• Atelier : une requête et ses tests unitaires

Après-midi. Introduction au BDD

• TDD et BDD : deux disciplines, deux publics
• Le langage du métier comme outil de collaboration entre développeurs, testeurs et product owners
• Gherkin : Given, When, Then
• Des scénarios lisibles par le métier et exécutables par les développeurs
• Les outils .NET : SpecFlow, Reqnroll
• Atelier : premiers scénarios Gherkin automatisés

Après-midi. BDD en pratique

• Transformer un scénario en test qui pilote le code
• Démonstration : du Gherkin au code .NET, aller et retour
• Ce que le BDD apporte à la communication et à la documentation
• Les limites et les pièges : scénarios trop techniques, suites lentes, Gherkin écrit par les seuls développeurs
• Atelier : un scénario Gherkin de bout en bout sur le projet fil rouge

Avec quoi vous repartez

• Le projet fil rouge dans son état final, commité à chaque étape, pour retrouver le chemin parcouru
• Les supports de cours
• Une liste de critères pour décider, sur votre propre code, par où commencer

Organiser cette formation

Elle se donne dans vos locaux, pour votre équipe, sur votre code si vous le souhaitez. Le programme s'adapte à votre contexte et à votre langage.

Me contacter par emailouMe contacter sur LinkedIn