Il est de certaines catégories de bugs qui ne devraient jamais arriver en production. Ce n’est déjà professionnel de les livrer, mais en prime l’image du produit peut être désastreuse auprès de l’utilisateur, avec les conséquences qu’on sait. Dans les pires cas l’entreprise peut ne pas y survivre.
Voici dans cet article une liste non exhaustive de ces bugs et en conclusion quelques bonnes pratiques pour éviter de les voir.
La NullPointerException
La NullPointerException, ou équivalent quelque soit le langage, est un grand classique des erreurs qu’on trouve dans de très nombreux programmes. Et pourtant elle est en géénéral très facile à déboguer et corriger. Il s’agit vraiment de l’erreur de débutant qu’on ne devrait plus voir dans aucun programme.
Alors de temps en temps elle apparaît dans des conditions plus subtiles, certes, comme par exemple pour le langage java des objets non sérialisables dans une session HTTP, mais tout de même, la voir dénote de graves faiblesses au niveau de la programmation.
En fait le seul endroit où elle est acceptable est dans une assertion qui contrôle que l’objet testé ne doit pas être null. De telles vérifications devraient être faites dans toute API qui se respecte.
Les ressources non libérées après usage
Ici on ne va pas parler des pointeurs en C qui sont un cas bien plus complexe, mais des cas simples comme les flux fichiers et autres connexions à la base de données. Dans de nombreux cas on constate que le programme a ouvert un flux fichier ou une connexion sans la fermer après utilisation. Alors au début le programme continuera à fonctionner, jusqu’à ce qu’il plante car trop de fichiers sont ouverts ou parce que la base de données n’accepte plus de connexions.
Ce genre d’erreur est là encore simple à détecter avec des outils du type FindBugs ou équivalents suivant les langages. D’ailleurs tout développeur qui se respecte devrait régulièrement auditer son code avec ce genre d’outil. Premièrement il apprendra beaucoup de choses sur le langage, et deuxièmement il améliorera ainsi la qualité de son code de manière significative.
Pour l’utilisateur, un tel bug se traduit par une application qui subitement se met à planter, le laissant sans autre possibilité que de la redémarrer. Et si l’application en question fonctionne sur un serveur web, ce sont tous les utilisateurs qui perdront leur travail en courus. Ça fait bien…
L’application qui plante dès le premier démarrage
Là encore c’est un grand classique : vous livrez une application à un client, et, manque de chance, elle plante au premier démarrage. C’est le meilleur moyen de perdre des clients, soit dit en passant, car les utilisateurs restent systématiquement sur leur première impression…
Ce bug survient généralement parce que les développeurs ont un environnement « sale » sur leur machine, pollué notamment par tous les outils installés sur leur machine. En particulier, les jeux de données dont ils disposent ne reflètent pas toujours ce qu’a l’utilisateur, et le cas de la base « vierge » est rarement testé.
C’est pourquoi avant de livrer une application il faut toujours tester le cas d’une installation vierge si le cas doit se produire pour certains utilisateurs. Alors certes le cas se produira moins dans le cas d’une application de type Software as a Service (SaaS) mais il faudrait toujours être capable de faire repartir l’application sur une base vierge… parce que le besoin peut survenir un jour ou l’autre !
À noter que le bug peut être parfois mineur voire uniquement cosmétique, mais là encore vous renverrez une image déplorable de votre travail… et c’est bien dommage. Donc n’oubliez pas de soigner la présentation de votre application !
Corollaire : l’application qui ne s’installe pas correctement
On ne le répétera jamais assez : une application ne doit pas s’installer à la main, hormis pour le cas d’un exécutable autoporté. Autrement dit c’est aux équipes de développement de fournir une procédure d’installation automatisée, et ce que votre application soit au format SaaS ou devant fonctionner chez un client final.
Par ailleurs la procédure d’installation et de démarrage de l’application doit être vérifiée très régulièrement, aussi bien dans le cas d’une installation initiale que de la mise à jour.
En aucun cas il ne faut fournir un manuel d’installation d’une cinquantaine de pages aux équipes de production ou aux utilisateurs finaux car c’est le meilleur moyen d’avoir des erreurs non reproductibles. Pour être tombé récemment sur un tel cas j’ai passé deux jours à déboguer avec le support une installation de leur logiciel, avant d’abandonner et de tout reprendre de zéro sur une machine vierge…
En bref
Certains bugs sont complexes à traiter et sont « normaux », dans le sens où aucun être humain n’est infaillible. Par contre on ne devrait en aucun cas voir les bugs évoqués ci-dessus dans une application en production, or ça arrive trop souvent. Et pourtant il est relativement simple de les éviter en maximisant la couverture de tests de l’application, qui devrait être au minimum de 80%, et en automatisant les procédures d’installation… bref en faisant correctement du DevOps.
Mais pour y arriver tout le monde doit jouer le jeu, y compris le management qui est trop souvent tenté de demander aux gens de développeer de nouvelles fonctionnalités pour hier. Et donc si une application est pétrie de tels bugs, il faut bien se dire que tout le monde est responsable, et pas uniquement les développeurs comme les chefs ont trop souvent tendance à le croire. À bon entendeur…
Besoin de tester ton niveau en développement informatique ?
Cet article vous a plu ? Vous aimerez sûrement aussi :
- La démarche DevOps
- Entrepreneurs, pourquoi c’est important de bien payer vos développeurs
- Les tests automatisés
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
