ABC du Craft – Petit guide de survie pour développeurs en quête de sens

Introduction : la claque du monde pro

Entre ce qu’on fait à l’école et ce qu’on vit en entreprise, le contraste est souvent brutal. J’ai fait des projets à l’école, comme beaucoup d’entre vous. Mais ces projets, ils n’avaient rien à voir avec ceux du monde pro.

À l’école, le code est souvent un exercice éphémère : une fois la note attribuée, il est aussitôt jeté. En entreprise, c’est tout l’inverse. Le code que l’on produit est amené à vivre, à évoluer, à être maintenu, pendant parfois longtemps. Il a un impact concret sur les utilisateurs , les équipes et parfois même sur des enjeux critiques. C’est là que commence vraiment le métier de dev .

J’ai réalisé cette différence lors de mon premier projet professionnel, dans le secteur de la sûreté nucléaire. Le niveau d’exigence y était particulièrement élevé. Il ne s’agissait plus simplement d’écrire du code fonctionnel, mais du code fiable, robuste et sécurisé. Le moindre écart pouvait avoir des conséquences majeures.

Ce fut un choc formateur. J’ai alors pris conscience que ma formation, bien que précieuse, ne m’avait pas entièrement préparé à ces réalités. La rigueur, la responsabilité et l’anticipation sont des compétences que l’on développe réellement sur le terrain, dans le cadre exigeant du développement de logiciel.

Alors j’ai dû apprendre, sur le tas. Le client attendait des résultats. Moi, j’avais plein de questions. L’agilité ne m’a pas sauvé (même si j’étais dans une équipe Agile). Les réponses, je les ai cherchées ailleurs.

C’est là que j’ai découvert ce qu’on appelle le Software Craft , ou en français, l’Artisanat Logiciel.

A comme Apprentissage Continu

On apprend tout le temps. C’est une évidence, mais ça vaut le coup de le marteler. Moi, j’ai fini mes études sans connaître Git. Sans débuggeur. Juste avec des print. Je vous jure. Pour gérer les versions ? Des mails. Version_finale_bis_v3. Le folklore complet.

Depuis, j’ai appris. Et je continue. Parce que la curiosité, ça s’entretient. Parce qu’on veut faire mieux. Parce qu’on veut comprendre ce que font les autres, et comment on pourrait s’en inspirer. On se fixe des objectifs – moi, par exemple, ne pas faire exploser une centrale nucléaire. Chacun ses défis. Mais surtout, on n’est jamais seul. C’est ce que j’ai constaté moi-même à mon arrivée chez KAIZEN. On apprend en avançant, mais aussi grâce aux autres : des mentors, des expertes, des collègues disponibles pour relire, guider, challenger, partager ce qu’ils savent. Ce compagnonnage, cette communauté de savoirs vivants, c’est ce qui fait toute la différence. Parce qu’apprendre, oui. Mais apprendre bien, et apprendre ensemble, c’est encore mieux.

Aujourd’hui, dans cet article , vous apprenez peut-être quelque chose. Vous écoutez, vous pratiquez, vous itérez. Et tout ça, c’est de l’apprentissage.

Ce que j’aime, c’est que le Craft promeut cette idée de compagnonnage. On apprend auprès de gens qui savent. Pas une fois, mais tout le temps. On ne devient pas "maître du code" en sortant de l’école. On le devient, peut-être, après des années. Et encore.

 

 

B comme Best Practices (ou pas)

Y a-t-il des "bonnes pratiques" absolues ? Ça dépend des contextes.

Prenons l’IDE : il y a des bonnes raisons de ne pas l’utiliser. Trop lourd, pas adapté au travail à distance, etc. Git ? Même chose. Compliqué, parfois peu performant. GitHub ? Même chose. On pourrait en discuter longtemps…

Même Python – mon langage de cœur – a des défauts.

Rien n’est parfait. La seule chose qu’on peut dire, c’est que tout dépend du contexte.

Et pour comprendre le contexte ? On discute. On choisit ensemble. On fait des compromis. C’est ça, la seule vraie best practice : trouver un consensus !

 

 

C comme Clean Code (ou plutôt C comme Code Review)

Je vous ai présenté un bout de code Python bien moche. Et vous avez réagi : "pas d’exception", "print au lieu de logs", "hardcoding d’URL", "HTTP sur FTP", etc. Et surtout : mélange français/anglais. Encore une fois, ça dépend du contexte.

    import requests

def recuperer_le_bundle() :
           url = "http://toto-ftp.service.corp.com"
           response = request.get(url)
          print("received bundle")
          return response.json()

Le clean code, c’est important. Mais pour moi, la vraie question, c’est : pour qui on code ? Pour la machine ? Ou pour les autres humains ?

N’importe quel idiot peut écrire du code qu’une machine comprend. Les bons programmeurs sont ceux qui peuvent écrire du code que les autres humains comprennent..

- Robert C. Martin

Et puis, il y a ces petites choses qu’on ressent sans pouvoir l’expliquer : les "code smells", le fameux "WTF per minute", le code qui pue ou qui surprend. Le code, c’est un espace vivant. Et la meilleure règle ? La règle du boy scout : laisse le code plus propre que tu ne l’as trouvé.

 

 

D comme Design Pattern

Il y en a 26 dans le bouquin de 1994. Puis 40 dans la suite. Puis d’autres encore. Est-ce qu’il faut tous les connaître ? Non. Mais c’est utile.

Pourquoi ? Parce que parfois, on réinvente la roue sans savoir qu’elle existe déjà. Connaître les patterns, c’est pouvoir mettre un mot sur une solution. C’est comme appeler un chat un chat. Ou un singleton, un singleton.

Mais encore une fois : ce ne sont que des outils. Il ne faut pas tomber dans le pattern pour le pattern. On peut très bien bosser sans, et on peut les réinventer sans le savoir. Mais autant gagner du temps, les utiliser pour communiquer ou gagner du temps.

 

 

K comme KISS : Keep It Simple, Stupid

C’est une devise essentielle. Faire simple, c’est difficile. Faire compliqué, c’est flatteur. Mais si tu écris du code trop intelligent, tu ne seras pas assez intelligent pour le débugger.

La complexité inutile est notre ennemie. La citation "évitez les optimisations prématurées" (de Knuth) prend tout son sens ici. Pas besoin de sur-architecturer trop tôt. On garde les choses simples, et on complexifie seulement si nécessaire.

Et rappelez-vous : on nous paie pour écrire du code qui répond à un besoin métier, pas juste pour "coder ". C’est précisément là que le Ccraft rencontre des sujets plus larges comme la compréhension des processus métier ou l’urbanisation du système d’information. Car pour livrer du code qui a du sens, encore faut-il savoir dans quel cadre il s’inscrit. Sur ce point, cet article sur la cartographie des processus propose une approche complémentaire essentielle.

 

 

P comme Pair Programming

Deux cerveaux valent mieux qu’un. Travailler à deux (ou plus), c’est collaborer, partager, progresser. C’est augmenter le fameux bus factor – combien de personnes peuvent partir sans que le projet s’effondre ?

 

Le pair/mob programming, ça s’apprend. Ce n’est pas inné. Il faut s’exercer, dans des dojos, des katas, des meetups. L’expérimentation est la clé. Et dans cette pratique aussi, le software crafter trouve des repères essentiels.

 

 

T comme Test (et TDD)

Les tests, c’est notre filet de sécurité. Comme un système d’assurage en escalade. Pas besoin de faire du free solo à chaque merge (le free solo est une pratique qui consiste à grimper sans aucun équipement de sécurité : ni corde, ni baudrier, ni assureur, en se basant uniquement sur ses compétences techniques, sa force mentale et physique pour progresser).

Le TDD n’est pas une religion. Ce n’est pas LA solution miracle. Mais c’est un excellent outil. Il permet :

• d’écrire du code testable
• de documenter l’usage du code
• de progresser par petits pas
• d’avoir du feedback rapide
• et surtout, de livrer avec confiance.

Mais peu importe la méthode : testez. Toujours. Sinon, vous avancez à l’aveugle. Et dans une équipe, les tests, c’est ce qui permet de transmettre, de faire vivre un projet, même après un turnover complet.

 

 

R comme Refactoring

Changer la structure sans changer le comportement. C’est ça, le refacto.

Et pour bien le faire, il faut des tests. Les deux vont de pair. Le refacto permet au code de rester compréhensible. Il permet de s’adapter au changement. Et ça, c’est fondamental.

 

 

V comme Valeur

Pourquoi on fait tout ça ? Pour livrer de la valeur.

Malheureusement, l’Agilité a parfois échoué à intégrer la notion de technique . Pour beaucoup de développeurs, l’Agilité est devenue un repoussoir. Le Craft est né comme un mouvement réactionnaire : remettre la technique au cœur.

Le Manifeste du Craft dit :

• Des logiciels bien conçus
• Qui ajoutent de la valeur
• Dans une communauté de professionnels
• Par des partenariats productifs

 
C’est beau. Mais ce ne sont pas que des mots. C’est un engagement, une exigence envers soi-même et envers les autres. C’est une posture : élever le niveau.

 

 

Conclusion : LE Craft, c’est Humain

On n’a pas toutes les réponses. On n’a pas la science infuse. Mais on cherche. On progresse. On se remet en question. Le Craft, ce n’est pas une méthode. C’est une démarche. Une éthique. Un engagement vers le mieux.

Et si on le fait bien, on ne fait pas juste du code. On construit une communauté. On élève notre métier.

Le Craft, ça se vit autant que ça se lit. Si cet article vous a parlé, prenez le temps d’écouter la conférence dans son intégralité juste ici : Conférence ABC du Craft au Lyon Craft

Retour aux articles