Les formations Craft pour nos consultants

Partager sur linkedin
Partager sur twitter
Partager sur facebook

Les formations Craft pour nos consultants

Chez novencia, nous proposons régulièrement des formations à nos consultants. En février, ces derniers ont eu l’opportunité de se former au TDD et au Clean Code au côté de Patrice. Mais ces formations sont également accessibles à l’externe :

Formation TDD

Consultant C#, Patrice Bardeur a animé une première formation dédiée à l’interne au sujet du Test Driven Development. Avec la situation actuelle, elle a dû se faire en distanciel en prenant en compte certaines spécificités et donc des difficultés en plus. Mais Patrice a su les résoudre grâce à son expertise et l’utilisation de différents outils.

Nous vous proposons un retour guidé sur le programme :

Qu’est-ce que le TDD ?

Test Driven Development est une méthode de logiciel qui permet de concevoir un logiciel pas à pas, de façon itérative et incrémentale, en écrivant chaque test avant d’écrire le code source et en remaniant le code continuellement.

Selon Patrice, il y a 3 règles bien distinctes :

  • « Vous ne pouvez pas écrire de code de production tant que vous n’avez pas écrit un test unitaire qui échoue. »
  • « Vous ne pouvez pas écrire plus d’un test unitaire que nécessaire pour échouer, et ne pas compiler revient à échouer. »
  • « Vous ne pouvez pas écrire plus de code de production que nécessaire pour que le test unitaire actuellement en échec réussisse. »

 

Quel est le principe du TDD ?

Une méthode à part entière au TDD qui repose sur la rédaction de tests unitaires avant de procéder à une phase de codage. Contrairement à l’approche traditionnelle qui consiste à rédiger les tests d’une portion d’un programme afin de vérifier la validité de l’unité implémentée.

La démarche à suivre est décomposée en trois phases appelées RGR :

Puis pas à pas, on écrit le code :

 

 

Les avantages :

  • Les tests unitaires sont réellement écrits
  • Obtenir un code plus cohérent
  • Clarification des détails de l’interface et du comportement

 

Ci-dessous un exemple de structure d’un test TDD :

 

Afin de bien comprendre les principes du TDD et de se mettre rapidement dans le bain, Patrice a invité les participants à pratiquer 2 exercices :

Le premier était un Live Coding FizzBuzz et un Leap Year, en 1h le défi, écrire une fonction qui retourne true si l’entier en entrée est une année bissextile ou non. (A savoir, qu’une année bissextile est divisible par 4 mais pas par 100 sauf si elle est aussi divisible par 400.) Après cette mise en bouche, les participants ont continué la journée de formation sur des cas pratiques et d’autres exercices.

Développeurs, chefs de projet, ingénieurs, consultants, si la formation TDD a attisé votre attention et que vous souhaitez en apprendre d’avantage, rejoignez la prochaine session de formation !

 


Formation Clean Code

9 heures précises, Patrice lance la seconde formation au Clean Code avec comme première question : « Selon vous, que serait un mauvais code ? »

Les participants sont unanimes : « Un code illisible, nommé en abrégé, peu explicite ou encore des fonctions de 400 lignes ».

Patrice conclu cet échange par la célèbre phrase d’Uncle Bob Martin : « No matter how slow you are writing clean code, you will always be slower if you make a mess. »

Pour comprendre et réaliser un clean code, rien de mieux que de pratiquer. Les participants ont donc, dès le début de la formation, réalisé un exercice pour apprendre à coder proprement : Kata, Fruit Shop.

Après 2 heures de pratique, Patrice a évoqué les principes du Clean Code, il convient d’ailleurs de respecter certains principes de base de la programmation. En commençant par le nommage ; où il faut éviter les acronymes (préférer utiliser « paymentSystemProvider » au lieu de « psp »).  Il faut rendre le code expressif, comme si nous étions nouveaux dans le domaine.

Dans l’idée de conserver des fonctions courtes pour qu’elles n’aient qu’une seule responsabilité, et afin d’éviter les répétitions inutiles, il faut préférer ce code :
.
.

.

.

Au lieu de celui-ci :

 

Ou encore, il faut contourner les side effects :

 

 

Et préférer utiliser ce code :

 

 

Enfin, la lisibilité avant la concision, le code se doit d’être lisible pour les autres développeurs qui travaillent sur le projet. Ecrire un code concis, mais incompréhensible par les autres n’aura aucun sens.

Lors de la seconde partie de la journée, nous avons continué la formation pour devenir un clean codeur en utilisant de nombreux outils et en pratiquant plusieurs cas.

Vous souhaitez continuer la formation ? Rejoignez-nous !

 

Pour aller plus loin :

En réagissant à cet article, vous nous permettez d'affiner les contenus que nous publions ici !

  • Awesome (1)
  • Interesting (1)
  • Useful (1)
  • Boring (0)
  • Sucks (0)

Si cet article vous a plu, n’hésitez pas à le partager via

Partager sur linkedin
Partager sur twitter
Partager sur facebook