Formation TDD, Clean Architecture et DDD dans le monde Java
Descriptif
Les backends comme les frontends souffrent d’une complexité accidentelle dans la plupart des projets.
Une complexité accidentelle est une complexité additionnelle malvenue qui aurait pu être évitée.
Quand s’observe t'elle réellement ?
Quelques mois après le début du projet.
Pourquoi donc le terme “accidentelle” et non le terme “additionnelle” ?
Car bien souvent, elle survient par surprise, sans anticipation aucune.
Surtout lorsque le développeur n’est pas aguerri sur les concepts théoriques relatifs à la conception logiciel.
Quelles en sont ses conséquences :
- - Un temps de développement considérablement augmenté pour la moindre fonctionnalité normalement simple.
- - Une peur extrême de changer le code existant, de peur d’y engendrer des impacts non perçus ni maîtrisés.
- - Par cette peur de changer/casser, chaque bug remonté est corrigé avec des workarounds ; autrement dit des pansements indirects proches de la supercherie.
- - Une expressivité du code réduite à néant, par à-coups de ces workarounds et du stress engendré par la soumission face au code existant.
- - Un code qui devient de moins en moins testable, par des prises de raccourcis contraires aux bonnes pratiques d’architectures et de code design souvent passées inaperçues, sans prise de conscience.
- - Des sessions fatiguantes de débugging à outrance devant ce code jugé farfelu, non expressif et souvent bancal.
- - Une application devenue très rapidement inflexible, dont même la moindre évolution technologique telle une mise à jour de frameworks devient le signe d’un besoin de refonte globale …
Est-ce une fatalité ?
Devant le nombre de projets dans ce cas-là, il faut croire que oui.
Mais il existe heureusement des pratiques logicielles qui redonnent de l’espoir et qui atténuent drastiquement cette complexité accidentelle si bien comprises et bien menées.
Parmi ces pratiques, je mettrai l’accent sur deux d’entre-elles qui me paraissent totalement cruciales et qui ont changé mon quotidien dès 2011 :
- - Le Test-Driven Development alias TDD
- - La Clean Architecture (cf Hexagonal Architecture ou Ports/Adapters architecture).
Dans cette formation, je vous démontrerai comment réaliser un backend from scratch avec ces pratiques dans un live coding avancé et fluide, sans manquer de vous exposer une bonne stratégie de tests combinant tests d’acceptation, tests unitaires, tests d’intégration et tests end-to-end.
Mon premier souhait : que vous compreniez bien que le TDD n’est pas une technique de test mais de codage permettant une amélioration notable de vos algorithmes et de vos designs.
Le sujet sera un sujet Java digne de ce qu’on attend de nous en entreprise, bien loin d’un vulgaire Kata de tri de nombres.
Technologies :
- - Java 16+
- - Spring-Boot / Rest APIs
- - Hibernate/JPA
- - PostgreSQL
- - JUnit 5 / AssertJ
- - TestContainers (Docker).
Ce sera interactif avec des exercices sur le chemin, des échanges de questions/réponses au tac au tac, et surtout une bonne ambiance, à la fois pro et détendue.
Ayant l’habitude d’enseigner sur les sujets Craft, j’ai acquis une pédagogie qui vous plaira et qui ne laissera personne sur le carreau.
Aussi, j’assurerai un suivi sous forme de réponses à vos nouvelles questions post-formation de sorte à ce que chacun d’entre-vous évoluent et progressent sans blocage et dans la bonne direction au quotidien.
Pour finir, vous constaterez pour beaucoup que quasiment tout ce que vous pensiez au sujet de ces pratiques sont en réalité de fausses croyances ...
Je n'ai plus qu'à vous souhaiter la bienvenue dans ce noble monde du développement logiciel professionnel.
Les sessions regroupent entre 3 et 11 personnes, afin de garder une haute qualité d’intéraction.
Programme et méthode pédagogique
Objectif du parcours pédagogique
- Identifier les principes fondamentaux du Test-Driven Development (TDD) et de la Clean Architecture dans un environnement Java.
- Reconnaître les causes de la complexité accidentelle et adopter des pratiques permettant de la prévenir.
- Appliquer les concepts principaux du Domain-Driven Design (DDD) et de CQRS dans des cas pratiques.
- Développer une application from scratch en suivant une méthodologie professionnelle, comme attendu en entreprise.
- Mettre en œuvre différents types de tests (unitaires, d'acceptation, end-to-end, d'intégration) pour garantir la qualité du code.
- Analyser et comparer les différents types de tests pour mieux comprendre leur utilité et leur complémentarité.
- Clarifier et démontrer les concepts majeurs et connexes à travers des sessions interactives de questions-réponses.
- Expérimenter des situations concrètes grâce à des exercices de live coding.
Durée
14 heures
Date
Mercredi 18 septembre - 09h15 / 17h00
et jeudi 19 septembre 2024 - 09h15 / 17h00
Lieu
À distance en visioconférence par Zoom.
Public cible
Particuliers et professionnels :
- Technical Leader
- Développeur Backend
- Développeur Full Stack
- Architecte technique
Pré-requis
- Bonne maîtrise de Java ou d'un langage similaire comme C#
- Notions aux frameworks, Spring-Boot / Spring-IOC / Hibernate précisément sont un plus
- Bonnes connaissances en programmation orientée objet
- Capacité à écrire un simple test unitaire avec JUnit
Déroulement du parcours pédagogique
Jour 1
- Rapide tour de table, présentation de chacun et exposition des attentes
- Introduction et cours théorique sur le TDD cassant les énormes quiproquos à son sujet
- Si le groupe est vraiment novice en TDD, Kata éventuel et judicieusement choisi de mises en pratique avec Java et JUnit
- Introduction et cours théorique sur la Clean Architecture
- Démarrage d'écriture d'une application "from scratch" digne d'un cas réel d'entreprise en TDD (User Story avec plusieurs règles de gestion) tout en respectant la Clean Architecture dans le monde Java.
Approche agile avec le mindset NoEstimates initiée par un mini atelier BDD judicieusement mené.
Notion DDD principales expliquées et prises en compte (Aggregates, Value Objects, Bounded Contexts).
Approche CQRS (séparation Read et Write). - Séances de questions / réponses tout au long
Jour 2
- Suite du live coding de l'application "from scratch" digne d'un cas réel d'entreprise
- Séances de refactoring au fil de l'eau du code ET des tests de l'application exemple, rendues plaisantes et sans crainte grâce au TDD
- Clarification de concepts subtils relatifs au TDD et à la Clean Architecture
- Liaison à une base de données PostgreSQL avec TestContainers - démonstration de tests d'intégration
Concept de persistent model allié à Hibernate/JPA/Spring - Exposition des services réalisés sous forme d'API REST avec Spring-Boot et tests end-to-end
- Séance de questions / réponses tout au long
Capacités développées
- Maîtrise de l'approche des problèmes algorithmiques avec le mindset TDD
- Maîtrise de l'écriture des tests unitaires orientés comportements, de tests d'acceptation, de tests d'intégration et de tests end-to-end
- Maîtrise du concept d'inversion de dépendances (DIP)
- Maîtrise de la Clean Architecture (Hexagonale Architecture) et de l'arborescence de fichiers optimale
- Capacité à relier une base de données avec JPA (Hibernate) dans un environnement respectant les principes de la Clean Architecture, sans jamais la violer.
- Capacité à refactorer des tests astucieusement (techniques de chapitrage / nommage / D.R.Y), essentielle pour évoluer sereinement en TDD
- Bonnes notions des concepts DDD principaux et de CQRS
Démarche et méthodes proposées
La formation se présentera sous la forme d'une alternance entre découverte de concepts théoriques, annihilation de fausses croyances, démonstrations complètes de l'approche par du live coding, exercices et échanges constants avec les participants.
L'outil de communication requis pour cette formation est l'alternance entre l'oral, l'écrit, le partage d'écran si visio (audio/video) et la manipulation d'un éditeur de code.
Les moyens pédagogiques
- Des apports théoriques sur le processus
- Des exemples concrets
- Des démonstrations complètes par le formateur en live coding
- Exercices réalisés en live par les participants afin de s'exercer sur cette application d'entreprise.
- Challenges proposés quant au TDD, Clean Archi et au refactoring de code (modification de structure du code)
Évaluation formative
Une feuille d'évaluation de compétences est remise à chaque stagiaire leur permettant d'évaluer leurs acquis.
Une deuxième évaluation permet d'évaluer les modalités pédagogiques et le contenu de la formation, de mesurer le degré de satisfaction à chaud du stagiaire pour adapter les formations suivantes aux besoins spécifiques des participants.
Documents et supports pour les stagiaires
À l’issue de cette session, il sera remis à chaque stagiaire le support de formation, le projet sur Git réalisé ensemble, ainsi qu’une certification de réalisation de l’action de formation.
Encadrement pédagogique
La formation sera assurée par Michaël AZERHAD
Profil et qualité : Président de WealCome et expert technique de plus de 15 ans d'expérience
Modalité d'accès
Contactez-nous au 06 09 88 51 02 ou par mail : contact@wealcomecompany.com
Délais d'accès
Nous pouvons programmer les formations en fonction de vos contraintes et de nos disponibilités.
Nos formations sont accessibles aux personnes en situation de handicap.
Les aspects, l’accessibilité et le type de handicap au regard des modalités pédagogiques sont à évoquer impérativement au cours de l’entretien préalable à toute contractualisation afin de pouvoir orienter ou accompagner au mieux les personnes en situation de handicap.
Prochaine session
par Michaël AZERHAD
Mercredi 18 septembre - 09h15 / 17h00
et jeudi 19 septembre 2024 - 09h15 / 17h00
Les inscriptions à nos formations sont ouvertes jusqu'à la veille de la date de début de la session indiquée.
Tarif "particulier"
Pour les salariés en CDI qui financent eux-mêmes
400 euros TTC / personne
Pas de CPF possible
Tarif "professionel"
Pour les entreprises y compris Freelances
1500 euros HT / personne
Finançable par les organismes financeurs
Wealcome est certifiée Qualiopi, ce qui vous permet de faire une demande de prise en charge par vos OPCO (Opco-Atlas, etc.) et les autres financeurs (FIFPL, FNE, etc.)