#5 Le « Software Craftsmanship » : un Agile pragmatique

article author

Lionel, software developer chez Technology Partner est adepte du mouvement “Software Craftsmanship”. Il va nous raconter son intérêt pour le concept sur base d’un livre de Sandro Mancuso : The Software Craftsman.

De manière générale, ce livre présente un concept, définit comme un état d’esprit où le développement logiciel est comparé à un métier d’artisanat. Comme tout artisan, son rôle principal est de résoudre une problématique grâce à des techniques spécifiques. On différencie ainsi les artisans grâce à leurs expériences et à la façon dont ils la valorisent.

Pourquoi nous parler du livre “ The Software Craftsman“ ?

Ce livre parle de façon clairvoyante et pragmatique de sujets que je trouve importants. Comme, le rôle d’un développeur, la manière d’envisager le métier ou encore sur l’amélioration continue.Dans la préface du livre, Robert Martin le décrit comme “une fascinante alternance entre des anecdotes autobiographiques chroniquant la vaste expérience de l’auteur et des recommandations autoritaires basées sur ses expériences”. Cet article synthétisera les principaux points qui me semblent primordiaux.

 

Le Software Craftsmanship, qu’est-ce que c’est ?

La définition de ce concept est sujet à débat dans la communauté mais l’auteur en donne la définition personnelle suivante : “Un long voyage vers la maîtrise.Un état d’esprit ou le développeur choisit d’être responsable de sa propre carrière, constamment en apprentissage de nouveaux outils et techniques et en recherche d’améliorations. Le software craftsmanship a pour but de mettre la responsabilité, le professionnalisme et le pragmatisme au centre du développement”.
En prélude, l’auteur présente la synergie que ce mouvement a avec l’Agilité. Selon lui, ces méthodologies permettent de“construire le bon produit” et le faire en “Software Craftsman” permet de “le construire bien”.

L’intégration de l’Agilité dans une équipe de développement rencontre parfois des écueils. De nombreuses entreprises se sont confrontées à des difficultés lors de transformations radicales de leurs processus via des méthodologies Agiles. Selon Sandro Mancuso, l’Agilité ne doit pas être remise en cause car une méthodologie ne va interagir que sur les processus et sur l’Humain. Dans ce cadre, c’est la culture d’entreprise qui doit être modifiée selon les valeurs de l’Agilité (Cf. Agile manifesto) et de l’esprit du software craftsmanship.
En parallèle, le manifesto du software craftsman est le suivant :

“En tant qu’aspirants Artisans du Logiciel, nous relevons le niveau du développement professionnel de logiciels par la pratique et en aidant les autres à acquérir le savoir-faire. Grâce à ce travail, nous avons appris à apprécier :

Pas seulement des logiciels opérationnels, maisaussi des logiciels bien conçus.
Pas seulement l’adaptation aux changements, maisaussi l’ajout constant de la valeur.
Pas seulement les individus et leurs interactions, maisaussi une communauté de professionnels.
Pas seulement la collaboration avec les clients, maisaussi des partenariats productifs.

C’est à dire qu’en recherchant les éléments de gauche, nous avons trouvé que les éléments de droite sont indispensables.”

A première vue, ces points paraissent un peu évidents. A travers son livre, l’auteur explicite plusieurs situations, où certains de ces points peuvent tomber dans l’oubli et affine sa vue de ces différentes idées.

 

Pourquoi dit-on que le Software Craftsmanship met en lumière des bonnes pratiques ?

Les concepts de perfectionnement continu s’appliquent à la fois pour le travail général d’un software craftsman mais aussi dans ses tâches techniques.

Comme un avocat qui donne des conseils personnalisés, un développeur expliquera les tenants et aboutissants de son travail ainsi que les avantages et inconvénients de ses choix techniques.
Être professionnel et satisfaire son client ne signifie pas simplement de développer le produit tel qu’il le demande. Il s’agit également d’endosser un rôle de conseiller et de communicateur en aidant le client à comprendre ses objectifs et comment les atteindre. Dans son livre, l’auteur soutient qu’il est important d’assumer ce rôle pour une collaboration profitable et efficace à tous.

En ce qui concerne la technique, il suggère avant tout d’être pragmatique. La mise en place d’outils ou pratiques n’a pas de valeur en soit mais devrait permettre d’accomplir une tâche de manière optimale. Si ce n’est pas le cas, ce n’est probablement pas le bon outil.
En termes de pratique, il insiste sur deux concepts qui me parlent beaucoup : le re-factoring et le Test Driven Development. (ci-après)

 

Quels sont ces deux concepts et quels sont les liens avec le développement ?

Dans ce livre, j’ai trouvé une très bonne argumentation pour justifier le re-factoring sous la forme de la métaphore suivante : “Comme un jardin, le code a besoin de maintenance constante.[…] Avec une maintenance basique et régulière, le jardin sera toujours beau mais si on le néglige, l’effort nécessaire pour lui rendre sa splendeur sera bien plus important.”
Il ne s’agit pas de “corriger du mauvais code” mais simplement de rester à jour sur les derniers standards. Il ne s’agit pas de “corriger un design fautif”mais bien de s’assurer que l’ajout de fonctionnalité se fait en prenant en compte l’environnement actuel. Puis, de mettre ce dernier à jour si nécessaire afin de garder un design impeccable.

En ce qui concerne le Test Driven Development (TDD), le principal avantage est de s’assurer que le résultat attendu d’une fonctionnalité corrobore avec les attentes du client. De plus, cela permet aussi d’aller droit au but dans l’écriture en réduisant les risques “d’over-engineering”. (complexification excessive du design du code).

De plus, un code trop complexe tend à être difficile à tester, ce qui pousse le développeur à réanalyser le design de son code afin de le simplifier. Le TDD raccourcit la boucle de feedback du testing, un peu comme l’Agilité au niveau du business. Ainsi, notre code est plus épuré et plus facilement maintenable et testable.

 

Comment “The Software Craftsman” influencera ta carrière ?

Pour un jeune développeur, comprendre les tenants et aboutissants de son rôle, ainsi que de la façon de le remplir de manière professionnelle, est une des choses qui ne s’apprend pas de manière académique mais plutôt par expérience. De plus, les observations notées dans ce livre m’ont semblés intéressantes. Elles feront désormais parties de ce que je prendrai en compte en créant ma propre vision des choses.

Obtenir le livre en l’achetant ici

 

Ecrit par Lionel Mottet & Charline Pennisi

Published on 08/03/2019
Update cookies preferences