Savoir-être
Introduction
« A good developper is a developer who can write code that any other developer can understand. » - Sandro Mancuso
La première étape de l’aventure démarre.
Être un bon développeur est une caractéristique relative.
Elle est relative à l’appréciation qui nous est renvoyée par notre environnement.
Mais quel est l’état d’esprit à avoir ?
Quels sont les réflexes, les rituels et l’environnement à mettre en place ?
Comment cultiver une vitalité technique pérenne ?
Cette partie rappelle que le Craftsmanship est avant tout une déontologie. Il intègre les éléments servant à comprendre la posture de l’artisan du code et à l’illustrer. Au-delà du savoir-faire, il est indispensable d’avoir une éthique, une attitude professionnelle et une hygiène technique.
#Manifeste Craftsmanship
#Attitude professionnelle
#Outillage & rituels agiles
Ils vous comprennent vous et votre code !
Manifeste de l’artisan codeur
« Your actions become your habits,Your habits become your values,Your values become your destiny. » - Gandhi
Nous en sommes là ! Lancés dans une quête vers l’excellence technique, un chemin long, difficile, complexe, qui se jouera de nous et nous fera miroiter, par moments, une fin proche et salvatrice. Ne nous leurrons pas, ce type de chemin est sans fin et tout semblant ne serait que mirage condamnant toute bonne volonté à une pâle frustration, un mal de vivre, un spleen technique.
Craftsmanship ou tyrannie de l’efficacité
Le choix de cette image n’est pas aléatoire. On peut assimiler le désert à bon nombre d’entreprises qui, a priori, ne disposeraient pas d’un contexte favorable à l’excellence technique. Pour l’anecdote, on peut se retrouver à rejoindre des entreprises où le développeur n’a pas de droit « administrateur » sur sa machine. Pour l’obtenir, il devrait remplir un formulaire, l’envoyer à un RSSI (responsable sécurité du système d’information), qui devrait lui-même le valider auprès de sa hiérarchie et pour une durée limitée dans le temps.
À la lecture de ces quelques lignes, vous avez, pour certains, décroché un petit sourire compatissant pour l’avoir vous-même vécu, et, pour d’autres, pensé : « pauvre de cette personne, elle n’a pas eu de chance ou elle ne savait pas où elle mettait les pieds ! ». Dans un cas comme dans l’autre, vous n’êtes pas insensible à l’importance d’évoluer au sein d’un environnement favorable. Et on pourrait légitimement se dire qu’à l’image d’une plante qui a besoin de dioxyde de carbone pour grandir, tout développeur qui se respecte a besoin de droits « Root » sur sa machine pour produire.
Cependant, et à la différence des plantes, nous, développeurs, nous ne sommes pas des entités passives, nous pouvons agir, trouver des solutions, sensibiliser notre environnement pour le pousser à changer afin qu’il nous soit favorable. Vous l’avez compris, nous ne devons...
Éthique et attitude codeur responsable
« Proposing a very different mindset for developers and companies, a strong set of technical disciplines and practices, mostly based on Extreme Programming, and with a great alignment with Agile methodologies,Software Craftsmanship promises to take our industry to the next level, promoting professionalism, technical excellence, the death of the production line and factory workers attitude. »- Sandro Mancuso
Fordisme - production line with factory workers - 20e siècle - Jean Luc Le Guellec
La brique est jetée, la révolution a commencé ! Fini l’attitude simple exécutant, et, d’ailleurs, le monde de l’industrie informatique en a observé les dérives, les limites.
-
Désengagement des collaborateurs : être un simple maillon de la chaîne de production, faire son bout de code sans être impliqué dans le pourquoi d’une solution, a été pendant très longtemps le quotidien des développeurs, et pas seulement eux ! Il n’y a pas besoin d’être devin pour connaître la suite : un collaborateur non impliqué est un collaborateur non engagé.
-
Équipes sillonnées et non solidaires sur le rendu final : chacun fait sa partie et peu importe si cela a des répercussions sur les délais ou la solution finale, du moment que la partie confiée s’exécute selon les critères initialement communiqués !
-
Réalisation plutôt qu’innovation : partir du besoin puis l’industrialiser revient à créer une chaîne de production que l’on veillera à optimiser. Comment ? En limitant les marges de manœuvre et la créativité de ses maillons. Dans une telle configuration, il est d’usage de suivre un plan de fabrication préétabli et d’éviter tout écart. Dans le cas contraire, on engendre un coût, considéré à court terme comme étant néfaste à la rentabilité initialement prévue.
Cela crée des structures et des entreprises réticentes au changement qui, en grandissant, deviennent de plus en plus lentes et inaptes à capter les nouveaux usages du marché. Et croyez-moi, j’en parle...
Agile, feedback en continu
En Agile, le feedback est partout !
Boucles de feedback
Grâce au feedback, on reçoit du monde extérieur une évaluation concernant nos activités. Le feedback pourra être tantôt positif, tantôt négatif. Dans les deux cas, il nous donne les moyens de capitaliser sur de bonnes pratiques ou de réajuster le tir en cas de dérives. Le feedback peut provenir d’un client :
-
en mode push, celui-ci viendra vers l’équipe projet et lui fera part de sa recette applicative ;
-
en mode pull, on placera des sondes sur l’application pour analyser l’expérience des utilisateurs.
Sur le volet technique, de nombreuses bonnes pratiques et outils sont disponibles et permettent de créer, en environnement Agile, des boucles de feedback rapides. En voici certains.
-
TDD (Test Driven Development) et BDD (Behavior Driven Development) : feedback sur les intentions de test.
-
Pull Requests et Code Review : feedback automatisé ou provenant d’un père sur les livraisons de code.
-
Intégration et Déploiement continu : feedback sur l’intégration et fiabilité de la chaîne de déploiement.
Les boucles de feedback permettent d’évaluer dans quelle mesure le code que l’on produit est en phase avec l’attente des utilisateurs. Ces boucles sont issues de la combinaison de rituels, de réflexes, d’automatisations et d’outils utiles à des fréquences et des amplitudes plus ou moins courtes. En plus de donner du sens au code fourni, elles permettent de prévenir l’introduction de bugs pouvant endommager le fonctionnement du logiciel.
Dans les prochaines sections, nous allons aborder ces différentes boucles et voir en quoi elles apportent, à tout aspirant artisan du code, les ingrédients nécessaires pour mieux concevoir des logiciels, assurer un apport constant de valeur, professionnaliser la chaîne de développement et bâtir des canaux productifs avec le marché cible.
1. Rituels
a. TDD, BDD, ATDD, CTDD
Le TDD, en tant que méthodologie, fournit une boucle de feedback très courte. Elle peut être de l’ordre de la milliseconde quand on exécute des tests unitaires (fonction, classe bouchonnée, interface de framework...)...
Outillage Craft et DX
« Software craftsmanship is a long journey to mastery. It’s a mindset where software developers (are) […], constantly learning new tools and techniques and constantly bettering themselves (at). »- Sandro Mancuso, convenient version
À vos outils : sortez vos marteaux, vos clés à molette, votre couteau suisse, à chacun son arsenal ! C’est le moment de s’équiper du bon lot d’outils vous permettant de mettre en valeur votre savoir-faire. C’est en constituant une connaissance personnalisée et poussée de votre environnement de développement que l’expérience devient exclusive et que les rituels agiles peuvent prendre du sens.
À petite échelle, c’est entre un développeur qui connaît les raccourcis-clavier pour retrouver une classe ([Ctrl][Shift] T - Eclipse) et un autre qui navigue dans l’arborescence du projet à l’aide de sa souris, ouvrant un à un chaque package, que la différence se fait, que l’expérience de développement (DX) change, que l’art s’incarne.
À plus grande échelle, tout aspirant craft se confrontera, un jour ou l’autre, à la nécessité de manipuler différents outils qui contribueront à booster sa productivité, professionnaliser son rapport au code, améliorer sa DX et réaliser de meilleurs produits. À défaut d’en être averti, et en cumulant un bon nombre de secondes, de minutes, voire d’heures contre-productives à cause de réflexes parasites, tout un chacun se rendra compte de l’importance de pouvoir identifier, à son niveau : les outils qu’il préfère, les habitudes qui permettent de réaliser un maximum d’activités en un minimum de temps et avec un maximum de plaisir.
Mais qu’est-ce que la DX ?
La DX (Developer Experience) est l’équivalent de l’UX (User Experience), dans la mesure où l’utilisateur d’un système donné est un développeur. La DX concerne l’expérience que vit un développeur en utilisant une application donnée, une librairie de développement, un outil, une API, du code produit par lui-même ou par un autre...
Synthèse et exercices
1. Takeaways
1) |
L’excellence technique est un mirage, une cible en perpétuel mouvement. Au mieux, on ne peut qu’y aspirer. |
2) |
Ne baissez pas les bras face aux premiers obstacles, persévérez et trouvez des moyens à votre niveau pour remédier à tout problème. |
3) |
L’ambition de relever le niveau de développement professionnel n’a d’intérêt que si on la place dans un cadre d’apprentissage et de transmission de la connaissance acquise. |
4) |
Un aspirant Artisan du code « apprendra aux autres à trouver la solution plutôt que de la leur servir sur un plat ». |
5) |
La réalisation d’une solution logicielle ne peut faire abstraction du contexte économique qu’elle sert et place ainsi l’artisanat du code au centre de préoccupations non techniques dans le but de trouver le juste équilibre entre code techniquement valable et solution économiquement viable. |
6) |
Savoir dire non, même au client, peut s’avérer salvateur. Analysez la situation, évaluez si le code qui sera produit aura une valeur ajoutée, et assurez-vous que le client obtiendra ce qu’il lui faut et non ce qu’il veut. |
7) |
Vous devez être vaillant, solide, vous devez être une start-up ! |
8) |
Organisez-vous et définissez vos priorités. |
9) |
Ne vous engagez pas sur des challenges qui ne vous motivent pas, cela dégraderait la perception de vos capacités et mettrait éventuellement votre équipe en difficulté. |
10) |
Communiquez ! Dites ce que vous faites et là où vous en êtes. Donnez-vous la chance d’obtenir du feedback des personnes impactées et d’ajuster le tir avant le drame. |
11) |
Les boucles de feedback permettent d’évaluer dans quelle mesure le code que l’on produit est en phase avec l’attente des utilisateurs. |
12) |
Le TDD, en tant que méthodologie, fournit une boucle de feedback très courte. |
13) |
Les rétrospectives constituent une boucle de feedback primordial dans le développement des pratiques d’une équipe agile. |
14) |
En faisant des releases fréquentes, on tend à... |