L’esprit Software Craftsmanship – Partie 1

Nicolas G

Software Craftsmanship

swcraftmanship

Nous pouvons lire le titre de Software Craftsman et notre implication dans des événements de Software Craftsmanship un peu partout sur notre blog ainsi que sur notre site. Cependant, suite à la remarque d’un ami me demandant ce que c’était, j’ai remarqué que ce n’était pas forcément clair.

Retours aux sources

Approche de développement initialement venue des U.S, elle met en avant les compétences des développeurs. Elle se veut de responsabiliser le développement ainsi que de produire le code le plus propre possible.
Un des enjeux du software craftsmanship est de lutter contre les mauvaises manies telles que les priorisations financières poussant à produire le plus rapidement possible du code, laissant de côté la qualité inhérente, par exemple, en repoussant la partie testing.

Le mouvement d’artisanat du logiciel place le logiciel au centre. Il voit le développement du logiciel comme un art. Le développement effectué doit résoudre les demandes du client, d’un point de vue technique et fonctionnel bien sûr mais il doit également pouvoir être viable sur le long terme.

Pour cela, la solution doit avoir un taux de bug avoisinant les 0% et doit pouvoir être remaniée pour des évolutions futures. Pour cela, rien n’est mieux que le Test Driven Development, permettant d’avoir un code testé, avec une couverture de code de 100% mais permettant également de s’assurer que le code est remaniable en le refactorisant.

Ainsi la philosophie du software craftsmanship veut que l’on y mette du sien lorsque l’on développe, que le développeur cherche la qualité et voit sur le long terme, afin d’éviter au maximum le legacy code futur.

En outre, l’artisanat du logiciel prône la culture du développement plus qu’un ensemble de pratiques à mettre en œuvre. Cependant elle reconnaît et recommande fortement un bon nombre de techniques, dont pas mal sont empruntées à Extreme Programming.

Objectifs

Le but final est de sensibiliser le développeur vers la qualité. Celle-ci peut s’octroyer de bien des manières et n’a pas pour objectif la perfection. Elle a pour but la recherche de l’amélioration et de faire “de son mieux”, et pour cela, l’idéal est d’évoluer en équipe, avec les autres et dans un but commun.

De toutes les bonnes manières reconnues pour faire évoluer la qualité, nombreuses sont celles qui tournent autour de la collaboration et du partage en permanence de ses acquis, ses problèmes, son évolution.Pour cela, au sein d’une équipe et d’un fonctionnement agile, Scrum, Kanban ou autre, l’équipe doit pouvoir être informée au maximum des conditions qui l’entourent. Pour cela, elle se doit de disposer d’indicateurs visuels afin de connaître :

  • les tâches attribuées aux autres membres de l’équipe,
  • les tâches qu’ils ont effectué
  • les tâches restantes dans le backlog

En outre, nous retrouvons ce système d’échanges dans Scrum avec le Daily Meeting et ses quinze minutes consacrées à faire le point, la remontée des soucis des membres, de ce qu’ils ont fait et de ce qu’ils vont faire.

Collaboration

L’une des meilleures façon d’apprendre est de collaborer avec les autres personnes. L’artisan met un effort tout particulier pour programmer ensemble, pratiquer ensemble, définir le design, les patterns, méthodologies et la planification avec son équipe.

Cela permet d’apprendre de l’un et de l’autre, de promouvoir une motivation au sein de l’équipe et d’accomplir plus de choses avec moins d’erreurs.

<!> Ce n’est pas parce que la collaboration apporte beaucoup de bon et qu’il est plaisant de faire du pair programming par exemple, que vous ne devez ne faire que cela. Il est également très prolifique de se retrouver seul à coder.

Techniques à mettre en place

Afin d’éviter un maximum de régressions et d’avancer vers un code de qualité, plusieurs techniques s’avèrent fortement appréciables, voire indispensables.

Revue de code

 

searching for bug

Indispensable à mes yeux, chez-nous, ainsi qu’au sein des grandes entreprises (Corp, Amazon, …), la revue de code permet d’éviter bon nombre de soucis. Outre le fait de permettre d’éviter de petites bévues en permettant à une autre paire d’yeux de voir le code fournit et d’identifier un éventuel problème, elle permet une harmonisation et une évolution des compétences des membres de l’équipe.

La revue de code se prête d’ailleurs très bien à l’arrivée d’un nouveau membre dans l’équipe. Celui-ci peut rapidement recevoir des retours sur ce qu’il produit et monter rapidement en compétence en obtenant des conseils en termes de qualité de code (testing, refactorisation, design).

Elle permet également de s’assurer qu’il n’apporte pas de bévues et/ou d’oublis tout en lui permettant d’apprendre de nouvelles choses, que cela soit de l’ordre de l’optimisation ou bien encore du correctif.

Pair programming

pairprogramming

Le duoing ou pair programming est une méthode empruntée à Extreme Programming consistant à mettre deux développeurs devant un même poste. La méthode veut que celui qui code soit celui ayant le moins d’expérience. Il permet de gagner un temps considérable s’il est utilisé efficacement.

Tout comme la revue de code, Il peut être un moyen très efficace lors de l’intégration de personnes dans l’équipe leur permettant de monter en compétence très rapidement tout en ayant un appui.

Mais il est aussi très pertinent lors de la résolution de tâches complexes où deux cerveaux peuvent arriver à une solution beaucoup plus efficace qu’un seul. Il permet également de discuter autour de la problématique et de dégager une solution beaucoup plus prestement que si une seule personne s’était penchée sur le sujet.

Sessions de partage

 

Dans le monde d’aujourd’hui et plus particulièrement dans nos métiers, le partage et les échanges sont essentiels. Ce sont eux qui nous permettent d’évoluer et d’en apprendre davantage, ainsi que de pousser notre curiosité.
Dans ce cadre chez Soft’it nous avons ce que nous nommons “Light’it”. Derrière ce terme, se cachent des soirées où des sessions sont proposées afin de partager ses connaissances au sein de l’entreprise. Celles-ci peuvent prendre différentes formes, tels que des ateliers techniques sur une nouvelle technologie, une présentation sur un sujet qui touche la personne (accessibilité, green code) voire sur une méthodologie (tdd, bdd, …).
D’ailleurs, en termes de sensibilisation, si vous désirez partager la culture craft au sein de votre entreprise, quoi de mieux qu’une session dédiée au craft voire à l’un de ses aspects sous-jacent pour commencer à partager cette vision avec vos collègues?
En outre, si vous voulez vous former vous même, partager des expériences ou bien encore des avis, il y a également le groupe Meetup SoftwareCraftsmanship ou des conférences comme Ncraft où vous pourrez échanger avec des personnes ayant la même passion que vous pour le développement de logiciels.
Pour les curieux, concernant Ncraft et notre implication, c’est par ici.

Rétrospectives

De la même manière que les sessions de partage sont essentielles afin de permettre une montée en compétences de l’équipe, il est primordial de pouvoir prendre du recul vis-à-vis de soi-même (en tant qu’équipe), afin de pouvoir évoluer et ne pas rester dans les erreurs passées.

Ces sessions de rétrospectives ont pour but d’éclaircir les points positifs comme les points négatifs et d’en définir des lignes d’améliorations.

Nous retrouvons celles-ci dans la méthodologie Scrum où elles prennent la forme de rétrospectives de Sprint, qui ont pour axe de travail principal le dernier Sprint, afin d’en dégager des actions permettant d’améliorer la productivité de l’équipe.

Pour un format idéal, elles doivent se passer en dehors de l’endroit de travail habituel des développeurs, loin de leurs ordinateurs afin d’apporter un cadre propice aux échanges et plus décontracté.

nos-posts-its

Pour notre part, nous nous retrouvons dans un café en amenant nos posts-its de trois couleurs différentes, jaune pour les points négatifs, orange pour les points positifs ainsi que vert pour les points d’améliorations à apporter. Puis nous procédons à 1 heure d’échanges en repassant dans un premier temps les points d’améliorations qui ont été établis à la dernière rétrospective en vérifiant si nous les avons suivis ou non en continuant sur les retours concernant le dernier sprint réalisé.

Test Driven Development

La pratique du TDD est mise en exergue et fortement recommandée par les artisans du logiciel. Cette pratique consiste à rédiger les tests dans un premier temps, avant d’écrire le code.

Le code écrit en TDD suit une boucle fixe :

  1. Ecrire un test et le faire échouer
  2. Ecrire le code lié et faire fonctionner le test
  3. Remanier le code pour améliorer sa qualité et sa maintenabilité en s’assurant que le test reste fonctionnel
tddd

Le gain des tests n’est plus à prouver, ils apportent un confort non négligeable pour le développeur  :

  • Ils garantissent le bon fonctionnement d’une fonctionnalité
  • Ils assurent la maintenabilité de l’application
  • Ils permettent de s’assurer la non régression de l’application lors d’un remaniement du code

Mon retour d’expérience

equipe
Notre équipe en mode MSDOS camera

Sensibilisé au craft depuis quelques mois maintenant, d’abord par mon équipe et tout particulièrement par mon manager, je connaissais déjà quelques principes sur le papier, en appliquais quelques uns sans réellement pousser la chose.

Adopter l’esprit craft au sein d’une équipe en tant que développeur est extrêmement jouissif. Je me suis passionné par tout cet aspect tournant autour des méthodologies agiles, qui apportent une valeur ajoutée non négligeable à ce que nous produisons mais aussi à nous mêmes.
Lorsque tout le monde joue le jeu, que le code de chacun est testé, puis joué par une chaîne d’intégration, qu’il passe ensuite par la vérification d’un autre développeur, une sérénité non négligeable se dégage.

Adopté, l’esprit craftsman peut se ressentir de différentes façons. Suivant l’individu et les pratiques mises en place, pour moi, c’est se sentir sûr de ce que l’on produit, connaître où l’on se situe, pourquoi fait-on ce que l’on fait, avoir une volonté de partage et d’entraide débordante et ne jamais se sentir seul. En soi, être le maillon d’une équipe solide.

Conclusion

En outre, l’esprit craftsman est de toujours se remettre en question, de voir sur le long terme et d’être à l’écoute des nouvelles technologies et méthodologies permettant de produire un logiciel de meilleure qualité, qui soit le plus robuste possible.

Si vous adhérez à ces principes et que vous sentez l’esprit de craftsman surgir de vous, n’attendez plus, signez le manifeste des artisans du logiciel

Là où nous avons principalement abordé l’aspect “équipe” et “évolution collective”, ce ne sont pas les seuls axes d’améliorations possibles.

La seconde partie de ce billet rentrera plus en détails sur la technique, en parlant des bonnes pratiques de développement, par la mise en exergue des standards de code (Clean Code) et de ce qu’ils peuvent apporter.

Cédric Burceaux, craftsman, développeur, scribe & troubadour à ses heures perdues.

Auteur / autrice

S’abonner
Notification pour
2 Commentaires
Le plus récent
Le plus ancien
Commentaires en ligne
Afficher tous les commentaires

[…] applications. Ainsi, même si les équipes sont très performantes, ont développé une culture software craftsmanship et devops, le Time To Market global peut être mauvais dans le cas où une équipe a prévu de […]

[…] ces dites valeurs, nous retrouvons beaucoup de valeurs portées par le mouvement software craftsmanship, que l’on pourrait également nommer le mouvement des développeurs […]