Formation
Construire une application Web solide avec TDD et la Clean Architecture

Descriptif

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

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

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 unitaires et des différentes approches associées pour finalement constater par vous-même que la discipline TDD 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 Web !
Des technologies comme TypeScript, Redux et React seront prises pour les exemples; mais sachez que d'autres technologies comme Javascript ou encore Angular peuvent être intégrées de la même manière.
Vous en profiterez pour comprendre finement les avantages de Redux, qui est par constat une notion très peu maîtrisée et apprivoisée dans la communauté.

Enfin, vous réaliserez les deux derniers jours une application Web 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 Web 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

Réalisation d'une application Web solide

  • Présentation de Redux
    • Intérêt de l'Event-Oriented Programming
      • Découplage des différents acteurs du système
      • Plus jamais d'oublis manuels de synchronisation des états entre les acteurs du système
    • Intérêt d'une source de données unique, appelée source de confiance
    • Intérêt d'un journal complet des actions utilisateurs
    • Intérêt du functional programming avec Redux
      • Pas de side-effects affectant la séquence des actions Redux
    • Concept de reducers et d'actions
    • Exemples simples en TDD de l'utilisation de Redux avec TypeScript
  • Utilisation avancée de Redux
    • Usage de selectors
      • Notions d'états dérivés
      • Utilisation de Reselect et notions de mémoïsation
    • Normalisation du store Redux
      • Qu'est-ce que la normalisation ?
      • Pourquoi normaliser ?
      • Exemples
    • Découverte de Redux-Observable
      • Notion d'Epic
      • Avantage du monde RxJs avec Redux
  • Intégration de Redux dans une architecture orientée composants comme le proposent React, Vue.js ou Angular
    • Avantages de l'intégration de Redux
      • Limiter les passages de "props" massifs aux sous-composants
      • Synchronisation implicite de tous les composants abonnés au store Redux
      • Bénéfice d'un système de cache grâce aux selectors, améliorant les performances générales
      • Bénéfice d'un journal accessible avec Redux-Dev-Tools
    • Présentation de React-Redux, intégrant Redux aisément au sein des composants React
    • Exemples
  • Concept de Clean Architecture appliqué au Web
    • L'hexagone principal
      • Concentre les abstractions d'algorithmes purement orientés UI, réutilisables
      • Concentre toute la logique métier
      • Redux au coeur de l'hexagone !
      • Pas une seule notion de React, Vue.js ou Angular dans l'hexagone !
    • Adaptateurs
      • Les composants React, Vue.js ou Angular
      • Les "passerelles" vers le monde extérieur (appels Back-end)
      • Les bibliothèques tierces (Push Notification par exemple)
  • Challenge : Réaliser une application Web réaliste en 2 jours prenant en compte toutes ces pratiques

React

TypeScript

Redux


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 React, Angular ou Vue.js
  • Bonnes notions en TypeScript
  • Des bonnes notions en Functional Programming sont un gros plus

Lieu

3 cité Ferembach - Paris 17

Prochaine session

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

Durée

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

Personnes par session

5 à 12 maximum

Prix "entreprise"

2000 euros HT / personne

Prix "particulier"

600 euros TTC