Software Craftsmanship
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
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.
Objectifs
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.
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
Revue de code
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
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
Rétrospectives
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é.
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 :
- Ecrire un test et le faire échouer
- Ecrire le code lié et faire fonctionner le test
- Remanier le code pour améliorer sa qualité et sa maintenabilité en s’assurant que le test reste fonctionnel
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
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.
[…] 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 […]