Les formations nécessitent la présence physique de tous les participants au sein d'une grande salle réservée par WealCome sur Paris.

Les formations sont destinées aussi bien aux particuliers qu'aux entreprises.

10 personnes maximum peuvent être présentes lors d'une même session de formation.

Robert C. Martin disait : "Il n'est pas suffisant d'avoir un code qui marche".

En effet, pour qu'un logiciel soit considéré comme réussi, il faut qu'il valide tous les points suivants :

  • Est 100% utile à son client et ne permet rien d'autre qui n'a pas été exigé par celui-ci.
  • Marche sans l'ombre d'une anomalie; ceci validé par un ensemble de pratiques de tests automatisés.
  • Dispose d'un code source aisément lisible; comme de la prose.
  • Peut évoluer aisément en se concentrant sur ce qui amène de la valeur au client, sans engendrer de dette technique ni de surprise au niveau du coût.
  • Ne présente pas de contrainte forte quant à un changement des choix d'infrastructures (bases de données, bibliothèques etc.)

Craftsmanship signifie artisanat et le Software Craftsmanship est alors le mouvement qui considère la programmation comme étant de l'art.

Vous pouvez visualiser le manifesto officiel ici.

  • Test-Driven Development (alias TDD) :
    discipline de programmation qui vise à accélérer drastiquement les développements tout en assurant de forts bénéfices tels que :
    la concentration sur la vision cliente d'un cas d'utilisation du logiciel, l'absence de code mort, un design de code fortement maléable sans risque, une living documentation et encore plein d'autres aspects étonnants à découvrir.
  • Art du nommage (variables, fonctions, méthodes, classes, fichiers, dossiers)
  • Finesse du design de code (Design Patterns, Respect du DRY, YAGNI, KISS, découplage)
  • Soin quant à la lisibilité du code source avec des pratiques telles que Extract till you drop.
  • Ne pas dépendre fortement des choix d'infrastructures (frameworks, base de données, bibliothèques etc.) grâce à un découplage fort entre le code métier (le cerveau du produit) et ces derniers.
  • Et bien plus encore.

Sans ces pratiques, vos développeurs vont très vite se confronter à ce que l'on appelle une complexité accidentelle entraînant de très mauvaises surprises.

Le budget initialement alloué pour le projet sera très nettement dépassé, les clients seront mécontents, les nouvelles fonctionnalités ne pourront se greffer au produit, d'anciennes elles seront involontairement cassées, et la survie du projet sera donc en jeu.

Robert C. Martin explique très clairement dans cet article que sans pratique de Software Craftsmanship assidue, un projet ne pourra se déclarer agile.

De même, dans cette excellente courte vidéo, J. B. Rainsberger explique ce qu'est cette fameuse notion de complexité accidentelle qui ruine un projet tout en mettant en valeur l'importance du Software Craftsmanship.

Encore aujourd'hui, énormément de développeurs pensent que TDD est une pratique visant à tester son code, ce qui naturellement à tendance à laisser penser que cela engendre plus de travail qui serait en quelque sorte facultatif.

Ces développeurs ont totalement torts.

C'est d'ailleurs une des raisons pour lesquelles Michaël AZERHAD a décidé de monter WealCome, afin contrer ces fausses idées reçues et ainsi convaincre du contraire; ce qu'il a déjà réussi maintes fois.

Voir quelques témoignages ici.

En effet, TDD est une discipline visant à accélérer les développements car elle permet de découvrir le bon code à écrire à tout moment sans surprise.

Voir la vidéo de Michaël AZERHAD qui s'intitule : TDD ça ralentit ? Regarde-ça tu vas changer d'avis !

Voir également son article de blog révélant l'énorme quiproquo lorsque des développeurs méconnaissant le sujet parlent de TDD.

Comme évoquée dans la précédente question, TDD n'a pas pour vocation de tester son code.

C'est une discipline très stricte qui permet de copiloter le développeur chaque minute, chaque seconde; afin de produire un code source parfait sous tous les angles.

Ce n'est pas une discipline qui se fait après-coup mais pendant que l'on code.
C'est donc une discipline pour développeur exclusivement.

Lire également le super article Symmetry Breaking de Robert C. Martin à ce sujet.

Votre équipe de testeurs aura tout de même un rôle important quant à la phase de tests exploratoires; afin de dénicher le fameux bug très exceptionnel et totalement inanticipé (rare cependant).

Si vous avez compris ce qu'est la complexité accidentelle dans un projet informatique (évoquée dans la question évoquant les risques à ne pas suivre les pratiques de Software Craftsmanship), alors vous comprendrez pourquoi le coût d'un projet au code source de moindre qualité surpasse totalement le coût d'un projet bien pensé et réalisé en respectant scrupuleusement les principes du Software Craftsmanship.

Robert C. Martin le dit si bien : The only way to go fast is to go well.

Pour la petite anecdote, regardez cette vidéo de course d'athlétisme symbolisant très clairement une équipe qui prend le temps de bien faire les choses, et un développeur qui fonce "dans le tas" croyant bien faire.

Weal signifie Bien-être en ancien anglais, et Come signifie Venir.

Juxtaposés, cela signifie alors : Le bien-être à venir.

Connotant ainsi le confort que vous aurez à travailler avec un code source de très haute qualité.