Formation
Construire une application Backenden Java avec TDD et la Clean Architecture

Descriptif

Spring et autres bibliothèques/Frameworks, le coeur d'une application Java ?
Et bien, contrairement à la pratique de beaucoup de développeurs, cela ne doit clairement pas être le cas !

Une bonne architecture backend se doit de garantir un découplage maximum entre le code logique de l'application et toute notion de bibliothèques externes comme Spring ou encore JavaMail.

Dans cette session de formation, vous allez d'abord prendre conscience de la profondeur des problématiques que vous rencontrez tous les jours en codant.
Ainsi, nous entrerons dans le monde des tests et des différentes approches associées pour finalement constater par vous-même que la discipline TDD dans le cadre des tests unitaires change radicalement la vie, amenant un large spectre de bénéfices !
Des exercices et live coding animés par Michaël AZERHAD seront au rendez-vous !

Dans un second temps, nous allons nous immerger dans le domaine de l'architecture logicielle.
De même que lors de la phase précédente, vous allez d'abord prendre conscience de la problématique sous-jacente, largement et malheureusement ignorée dans la communauté des développeurs.
Puis nous introduirons le concept de la "Clean Architecture", également appelée "Hexagonal Architecture" ou encore "Ports / Adapters Architecture".
Ce type d'architecture qui n'est rien d'autre qu'un jeu de bon sens amène énormément de bénéfices, aussi bien technologiquement que financièrement.
Des exemples et du live coding seront animés également par Michaël AZERHAD !

Une fois ces aspects théoriques et pratiques découverts, nous allons les mettre en valeur dans le monde du Backend !

Vous réaliserez alors durant les deux derniers jours une application Backend de type entreprise "from scratch" afin de mettre à l'épreuve vos compétences et valider vos acquis.

À l'issue de cette formation, vous maîtriserez donc les fondamentaux permettant de réaliser des applications Backend durables, évolutives, fiables, robustes et plaisantes à réaliser; et ainsi faire la différence au travail !

Programme

Test-Driven Development

  • Problèmes récurrents dans le monde des algorithmes
    • Fautes d’inattention coûteuses
    • Crainte quant à s'aventurer dans le refactoring du cerveau de l’application
      • Crainte d’effacer du code pourtant mort
      • Crainte d’effacer du code pourtant inutile
      • Crainte d’essayer/utiliser de nouvelles syntaxes du langage
    • Conséquences : De nombreuses heures de debugging et un code qui grossit exponentiellement sans réelle valeur ajoutée
  • La solution naïve : écrire des tests unitaires sans discipline particulière
    • Les fausses idées reçues concernant les test unitaires
    • Qu’est-ce donc qu’un test unitaire ?
    • Pourquoi écrire des tests unitaires APRÈS avoir rédigé le code de production est une pratique dangereuse ?
      • Teste très rarement l’exhaustivité du problème
        • Conséquences : % de Code Coverage mensonger et “faux positifs”
      • Pas de refactoring sain
        • Certaines craintes citées plus haut sont toujours présentes
          • Code mort fortement présent
          • Code inutile fortement présent
      • Code souvent non testable ou difficilement testable
        • Dépendances implicites
        • Initialisation du contexte d’un test unitaire trop lourde
      • “Later equals never” => plusieurs tests n’auront pas le temps d’être écrits et ne seront donc jamais écrits
  • Deuxième solution naïve : La méthode Test-First, écrire des tests unitaires en premier lieu puis coder tout l’algorithme correspondant ensuite, sans discipline particulière
    • Pourquoi écrire un test unitaire avant de coder tout code de production ?
      • Avoir du code testable à tout moment
        • Dépendances explicites substituables
        • Introduction aux différentes types de doubles (Mocks, Stubs, ...)
        • Focus immédiat sur la qualité de l’initialisation d’un test unitaire
      • Pas de fonctionnalité existante sans test(s) unitaire(s) associé(s)
      • Moins de code inutile
        • Feedback automatisé immédiat lorsque l’algorithme dans sa totalité est rédigé
    • Pas de gain significatif en terme de productivité
      • Debugging ardu et chronophage toujours d’actualité
      • Difficulté à trouver les bons algorithmes du premier coup
      • Code inutile toujours fortement présent
    • Pas de gain en terme de qualité de code
      • Algorithmes souvent trop complexes vu le besoin (KISS & YAGNI)
      • Pas de refactoring sain
        • Certaines craintes citées plus haut sont toujours présentes
          • Crainte d’effacer du code pourtant mort
          • Crainte d’effacer du code pourtant inutile
    • % de Code Coverage mensonger
      • Manque de finesse et de ciblage par les tests unitaires rédigés; des subtilités non testées
  • LA solution : La discipline Test-Driven Development
    • Les 3 lois sans compromis de TDD
    • Le développement incrémental : pilier majeur de TDD
      • Quand coder devient un jeu d’énigmes interactif et prenant
      • Obvious Implementation
      • Fake it until you make it
      • La triangulation
    • Le concept de “Transformation Priority Premise”, primordial pour réussir un développement incrémental
    • Amélioration drastique de la pratique Test-First
      • Gain en productivité
        • Feedbacks automatisés ultra-rapides quant à l’évolution de son code
        • Les bons algorithmes sont souvent trouvés du premier coup
        • Plus besoin du mode “debug” et de placer des breakpoints !
    • Gain en qualité de code
      • Algorithmes répondant de manière minimaliste et optimal au besoin
      • Refactoring sain
        • Plus de crainte quant à supprimer du code mort
        • Plus de crainte quant à supprimer du code inutile
        • Pas de risque de régression
          • Plus peur de toucher au code de ses collègues en vue de l’améliorer !
    • 100% de Code Coverage fiable
      • Chaque lettre dans le code a été justifiée par un test unitaire
      • Chaque lettre dans le code a été justifiée par un test unitaire
    • Exemples avec différents Katas de difficulté croissante

Clean Architecture

  • Problèmes récurrents dans le monde de l’architecture logicielle
    • Testabilité
      • Contexte d’exécution non substituable
      • Dépendances aux infrastructures et choix/détails d’implémentations techniques
        • Tests trop lourds
        • Tests lents
        • Tests souvent impossibles
    • Évolutivité
      • Non-respect du Separation of concerns
        • La vue par la logique métier sur les choix/détails d’implémentations techniques empêche une évolutivité aisée de l’application
      • Diagnostics d’anomalies
        • Diagnostics d’anomalies compliqués
          • La fonctionnalité ne marche-t-elle pas pour des raisons relatives aux infrastructures, frameworks, bibliothèques ou algorithmes maison ?
        • Création tardive de valeur au client
          • La livraison au client d’une fonctionnalité engendre trop souvent une étude en amont profonde et chronophage des choix technologiques
    • Coûts
      • Des choix technologiques déterminés en amont engendrent souvent des coûts additionnels non-nécessaires
  • Mini-historique de la Clean Architecture
    • Émergence en 2005 des concepts de la Clean Architecture par Alistair Cockburn 
  • Séparation drastique des choix/détails d’implémentations techniques du coeur de l’application
    • Concept d’hexagone, de ports et d’adaptateurs
      • L’hexagone : le coeur de l’application.
      • Les ports : les points d’entrée et de sortie de l’application
      • Les adaptateurs : les choix d’implémentations techniques permettant à l’hexagone de prendre vie
      • Les hexagones imbriqués : D’autres hexagones au sein des d’adaptateurs
    • L’inversion de dépendances
      • Permet de plugger les bons adaptateurs à un hexagone
      • L’injection de dépendances, une manière très courante d’assurer l’inversion de dépendances
      • Permet de développer plusieurs implémentations d’adaptateurs différentes et de switcher à sa guise
    • Testabilité
      • Contexte d’exécution substituable
      • Tests indépendants des choix/détails d’implémentations techniques et d’infrastructure
      • Tests légers
      • Tests rapides
    • Évolutivité
      • Changement rapide de frameworks, bibliothèques et d’infrastructures !
    • Diagnostics d’anomalies
      • Diagnostics d’anomalies aisés
        • Il est facile de déterminer la source du problème : algorithme maison, frameworks ou bibliothèques.
    • Création rapide de valeur au client
      • La fonctionnalité peut être testée et livrée rapidement grâce à la substitution de contexte d’exécution.
      • Les choix définitifs d’implémentations techniques peuvent être remis à plus tard
    • Coûts
      • Des choix technologiques pouvant être déterminés tardivement, avec des prises de décisions bien plus cohérentes
    • Exemples simples de Clean Architecture

Acceptance Test-Driven Development (ATDD)

  • Introduction au BDD (notion des "3 amigos") et au Gerhkin + explication du lien entre BDD et ATDD.
  • Présentation de Cucumber, l'outil parsant notre Gherkin !
  • Exercices de mise en pratique de Cucumber parsant un fichier exemple de Gherkin.

Les tests d'intégration

  • Introduction et fausses idées reçues.
  • Exercices de mise en pratique de tests d'intégration s'assurant de la bonne collaboration avec une base de données.

Les tests end-to-end

  • Introduction
  • Exercices de mise en pratique de tests end-to-end s'assurant du bon fonctionnement de Rest APIs avec Spring-Boot.

Réalisation d'application from scratch

  • Définition des scénarios Gherkins relatifs à l'application à partir des conversations autour des critères d'acceptation.
  • Mise en pratique de Cucumber, ATDD, TDD et tests complémentaires au sein d'une application Backend réaliste utilisant Spring IOC, Spring-Boot, base de données et une API d'envoi de mail, avec corrigés en live coding.

Java

Spring


Par Michaël AZERHAD

Pré-requis

  • Forte curiosité et une dose de perfectionnisme innées !
  • Pas de timidité pour poser toutes les questions que vous aurez à l'esprit !
  • Compétences en programmation logicielle
  • Bonnes notions de Java 8+ et Spring
  • Compétences en programmation logicielle orientée objet

Durée

6 jours / 10h - 18h avec une pause de 1h30 le midi

Lieu

3 cité Ferembach - Paris 17

Prochaine session

À définir très bientôt en fonction des candidatures

Personnes par session

5 à 12 maximum

Prix "entreprise"

2000 euros HT / personne

Prix "particulier"

800 euros TTC