Écris pas de bugs, mec

Tout ingénieur logiciel, chef de projet ou QA a déjà connu cette situation : une échéance approche à grands pas et le logiciel présente encore des problèmes. Une page ne charge pas, une API renvoie systématiquement une erreur ou un utilisateur peut lire des messages qui ne lui sont pas destinés. Ces problèmes sont appelés « bugs », en référence à un petit insecte qui s'introduit dans un ordinateur, touche la carte mère et finit grillé avec la machine. Personne n'écrit de bugs intentionnellement.

Et pourtant... les bugs arrivent.

Chaque jour. Partout.

Même dans les meilleures équipes.

La question est la suivante :

Pourquoi surviennent-ils ? Et que pouvons-nous faire pour les réduire sérieusement ?

Analysons cela de plus près.

Pourquoi les bugs surviennent-ils ?

1. Une fonctionnalité n'a pas été pleinement développée

Le développement de logiciels est une forme d'art : il nécessite une réflexion approfondie sur des milliers de composants interagissant entre eux, ainsi que de la créativité pour ajouter, supprimer ou modifier ces éléments afin d'apporter la meilleure solution à un problème informatique.

Si un peintre utilise la mauvaise peinture sur une toile sèche, l'œuvre finira par s'estomper. De la même manière, si un développeur n'implémente pas correctement un composant, le logiciel se comportera de façon erratique.

Parfois, la cause profonde est simple : de mauvaises habitudes.

• Précipiter les échéances sans réfléchir aux conséquences

• Ignorer la structure et les bonnes pratiques

• Copier-coller des extraits de code sans les comprendre

• Transformer des correctifs temporaires en bidouillages permanents

Lorsque le code est produit dans l'urgence, sans revue par des membres seniors ou sans tests appropriés, ce n'est qu'une question de temps avant qu'un bug n'apparaisse. Gardez à l'esprit qu'un mauvais code est rarement le fait de mauvais développeurs ; c'est souvent le résultat d'un mauvais environnement : pression, attentes floues ou manque de soutien. En fin de compte, le développeur n'avait pas les ressources nécessaires pour finaliser correctement la fonctionnalité.

2. Absence (ou insuffisance) de tests d'intégration

Chaque module peut réussir son test individuel.

Mais connecter des modules sans tests d'intégration, c'est la porte ouverte au chaos.

Tester chaque brique individuellement ne garantit pas que la maison ne s'effondrera pas.

C'est en testant la structure et la manière dont les pièces s'assemblent que s'opère le véritable contrôle qualité.

3. Des paquets tiers qui cassent

Les bibliothèques et frameworks externes accélèrent le développement, jusqu'à ce qu'ils se retournent contre vous.

• Les mises à jour introduisent des changements radicaux (breaking changes)

• Les dépendances deviennent obsolètes

• Des failles de sécurité s'immiscent discrètement

Si vous ne gérez pas les versions avec soin et ne surveillez pas vos dépendances, vous bâtissez votre projet sur du sable.

Les développeurs ne sont pas les seuls responsables

Éviter les bugs est un effort d'équipe.

Et les managers ont un rôle plus important qu'on ne le pense.

Voici ce que vous pouvez faire, en tant que chef de projet ou manager, pour aider votre équipe à écrire un code meilleur et plus propre :

1. Donnez des instructions claires

Des tickets flous sont une recette infaillible pour générer des bugs.

Des objectifs vagues mènent à des solutions approximatives.

Soyez spécifique.

Définissez ce qui doit être fait, pourquoi c'est important et ce que les parties prenantes attendent. Détaillez toutes les étapes nécessaires pour atteindre l'objectif. Définissez l'état initial et le résultat attendu. Expliquez comment vous en êtes venu à la conclusion qu'une action était nécessaire. De plus, si vous remarquez qu'un ticket n'a pas été pleinement implémenté par manque de spécifications, décrivez clairement ce qui doit être ajouté ou modifié pour répondre aux attentes.

2. Vérifiez le ticket

Avant de faire passer une tâche à l'étape suivante, vérifiez qu'elle est réellement terminée.

Il est extrêmement frustrant pour un ingénieur QA de recevoir un ticket à tester, pour s'apercevoir que la fonctionnalité n'existe même pas. Son rôle est d'imaginer différents scénarios de test, d'analyser une solution sous plusieurs angles et de tester le résultat d'actions possibles. Ce n'est pas son rôle de renvoyer sans cesse les tickets aux développeurs en leur demandant de faire un meilleur travail.

Ne demandez pas simplement au développeur « Est-ce que ça marche ? » avant de déplacer un ticket. Demandez-lui plutôt de démontrer que cela fonctionne. De même, lorsqu'un QA approuve un ticket pour la production, demandez-lui rapidement de rejouer son flux de test une dernière fois devant vous.

Vous seriez surpris du temps — et des conflits — que vous économiserez avec une simple vérification confirmant que le ticket est réellement prêt à avancer.

3. Créez une culture d'effort collectif

Écrire un logiciel demande une concentration mentale incroyable pour combiner avec succès différents composants en une fonctionnalité complète. Il n'est pas surprenant que les développeurs moins expérimentés oublient souvent des détails, mais même les seniors peuvent commettre des erreurs de temps à autre.

Avoir une équipe soudée capable d'aider quand les choses se compliquent permet non seulement de gagner du temps, mais aussi d'améliorer la qualité du rendu final. Le code est destiné à être maintenu par d'autres développeurs ; il est donc crucial de vérifier qu'il est maintenable avant de l'envoyer en production.

Les revues de code par les pairs (peer reviews) garantissent le respect des bonnes pratiques et des standards de l'équipe. De plus, elles favorisent l'apprentissage mutuel. Créez une culture où les développeurs se sentent à l'aise pour discuter de leur code et de leurs solutions.

Seul on va plus vite, ensemble on va plus loin.

4. Préservez la concentration des développeurs

Le changement de contexte (context switching) est l'ennemi du travail de fond.

Quand les développeurs restent concentrés sur la même fonctionnalité du début à la fin :

• Ils comprennent mieux les cas limites (edge cases)

• Ils repèrent les incohérences plus tôt

• Ils produisent un code plus stable

Faire sauter les développeurs d'une tâche ou d'un projet à l'autre tue la productivité et multiplie les erreurs.

Laissez-les se concentrer.

5. Motivez vos développeurs

Les bugs se multiplient lorsque les gens se sentent stressés, micro-managés ou constamment interrompus.

Donnez aux développeurs l'espace nécessaire pour une concentration profonde.

Faites-leur confiance pour gérer leur flux de travail.

Encouragez la fierté de produire un code propre et réfléchi.

Des développeurs heureux et concentrés bâtissent de meilleurs produits. C'est aussi simple que cela.

6. La philosophie du post-mortem sans blâme

Des erreurs surviendront. Du moins, si vous développez réellement quelque chose.

Les post-mortems sont un outil essentiel pour gérer ces incidents. C'est un concept reconnu pour documenter un incident et la manière dont il a été résolu, afin d'éviter qu'il ne se reproduise et de savoir comment réagir à des problèmes similaires à l'avenir.

Lorsqu'un bug fait surface, concentrez-vous sur le problème plutôt que sur les personnes impliquées. On ne peut pas « réparer » les gens, mais on peut réparer les systèmes et les processus pour mieux aider les individus à faire les bons choix lors de la conception et de la maintenance de systèmes complexes.

Posez les questions suivantes :

• Qu'est-ce qui a échoué dans le processus ?

• Comment pouvons-nous le corriger ?

• Que pouvons-nous en apprendre ?

Une fois le problème résolu, documentez tout dans un post-mortem, mais ne pointez personne du doigt ! Traitez l'incident comme si n'importe qui dans l'équipe aurait pu commettre cette erreur. Gardez le post-mortem constructif en vous concentrant sur les actions. Une fois les leçons tirées, partagez-les avec l'équipe technique ou via une liste de diffusion interne. Révisez les post-mortems comme vous réviseriez du code.

Les bugs arriveront.

Mais vous pouvez choisir comment y faire face.

Vous ne pouvez pas éliminer tous les bugs.

Mais vous pouvez mettre en place des processus qui les détectent tôt et des cultures qui réduisent leur fréquence.

Chez We Do Dev Work, nous pensons qu'écrire un code propre et fiable n'est pas seulement une question de compétence technique.

C'est une question de communication, de clarté, de concentration et de responsabilité.

Parce qu'un bon développement n'a rien de magique.

C'est une habitude, qui se construit brique par brique.