Navigation

Toutes les catégories

Filtrer par auteur

Voir les derniers articles

La meilleure méthode pour résoudre un bug

En développement web, un bug se définit comme la différence entre le comportement attendu et le comportement obtenu. Il ne s’agit pas d’une erreur dans le code à proprement...

Publié par Sebastien Turbe

En développement web, un bug se définit comme la différence entre le comportement attendu et le comportement obtenu. Il ne s’agit pas d’une erreur dans le code à proprement parler, mais de son symptôme. Débugger, c’est donc chercher et corriger l’origine d’un bug. Véritable bête noire des développeurs, ces problèmes existent sous une multitude de formes. Si nous avons tous, à un moment donné, été confronté à un bug, sa résolution ne se fait pas toujours sans mal.

Alors comment résoudre un bug ? Une résolution de bug intervient en deux phases : l’identification du bug et sa correction.

 

Phase 1 : Identifier le bug

identifier un bug

Souvent, nous sautons cette première étape et passons directement à la deuxième, ce qui est un mauvais réflexe. La première phase est au moins aussi importante que la seconde, car très souvent la correction est plus facile à mettre en œuvre une fois que la cause du bug est identifiée.

Pour identifier la cause première d’un bug, vous devez l’observer et le comprendre, en suivant les étapes ci-dessous.

 

Etape 1 : Reproduire le bug

Cette étape concerne la reproduction des conditions qui ont conduit au bug. Parfois, il est très facile à reproduire, parfois non : vous devez recueillir le maximum d’informations sur l’état du système au moment où le bug s’est produit. Pour ce faire, les logs sont votre meilleur allié car ils permettent de suivre ce qui a mal tourné. Vous pouvez également demander à la personne qui a détecté le bug.

Cette première étape aide à comprendre le bug, mais elle est également utile pour vérifier s’il a été corrigé ou non, en reproduisant les mêmes conditions que celles qui ont conduit au bug initial et en vérifiant qu’il ne se produit plus.

 

Étape 2 : Comprendre le bug

Cette étape est fortement corrélée à la précédente. Les différents mécanismes utilisés pour reproduire le bug ne permettent pas toujours d’en comprendre la cause. Par exemple, si vous avez un bug chaque fois que vous cliquez sur un bouton d’envoi, il suffit de cliquer sur le bouton pour constater et reproduire le bug. Cela ne signifie pas que vous avez réussi à comprendre l’erreur.

De manière générale, la reproduction d’un bug à partir d’une interface graphique n’est pas très utile et vous devez creuser davantage.

 

Étape 3 : Comprendre le comportement attendu

Grâce aux étapes précédentes vous savez pourquoi le bug est apparu, mais vous ne savez peut-être pas le comportement que l’application doit avoir une fois le bug résolu.

Pour répondre à cette question, vous devez recueillir des informations. Vous pouvez vous référer à la documentation, au cahier des charges, ou au chef de projet. Vous devez vous assurer du comportement attendu avec votre chef de projet.

 

Étape 4 : Délimiter le problème

Le but de cette étape est de localiser la partie du code qui provoque le bug. Commencez par identifier le module en cause et continuez votre enquête jusqu’à ce que vous trouviez la fonction avec la ligne de code causant le problème.

Les techniques suivantes peuvent vous aider à délimiter le problème :

  • Utilisez les logs : si vous avez de la chance, les logs pointeront directement vers la bonne partie du code à l’origine du problème
  • Ajoutez des logs s’ils n’existent pas, afin de les analyser ensuite
  • Éliminer la corrélation matérielle
  • Testez, pour vérifier la mise en œuvre de certaines parties du code

Si vous n’arrivez pas à délimiter le problème, il est très probable que votre application présente de sérieux problèmes conceptuels ou architecturaux, le genre de problèmes qui vont vous demander beaucoup de temps…

À savoir
Parfois, la ligne de code qui soulève l’exception est innocente – vous devez vérifier les blocs de code proches de cette ligne et ceux qui sont en interaction avec elle, ce qui nous fait passer à l’étape suivante.

 

Étape 5 : Auditer le code

Une fois que vous avez identifié le bloc de code qui pose problème, vous devez inspecter les autres parties du code (fonctions, modules, etc.) en interaction avec lui pour les raisons suivantes :

  • Ces parties peuvent être la source du problème ; votre bug peut être dû à de mauvaises données transmises par une autre fonction ou un autre module au bloc en question
  • La cause de votre bug dans le bloc de code identifié peut avoir le même effet sur les blocs en interaction.
  • La correction que vous avez l’intention de mettre en œuvre peut avoir des effets secondaires sur ces parties. Il est préférable de les détecter à ce stade pour les éviter.

 

Phase 2 : La correction du bug

correction de bug

Étape 6 : Mettre en œuvre la correction

Vous êtes un développeur, faites votre travail et corrigez le bug que vous avez heureusement identifié lors de la phase précédente. Bon courage !

 

Étape 7 : Tester la correction

Ici l’idée est de reproduire, une fois de plus, les conditions qui ont conduit au bug et de confirmer que, cette fois, plutôt que d’avoir le bug, vous avez le comportement attendu.

Validez ensuite qu’aucune régression n’a résulté de votre correction. Rien de pire que de créer de nouveaux bugs en en corrigeant un. Le résultat de l’audit de l’étape cinq doit être exploité à ce niveau et il faut écrire les tests adéquats.

 

Étape 8 : Nettoyer le code

Notez que cette étape commence à l’étape quatre lorsque nous délimitons le problème.

Pendant que vous résolvez le bug, vous pouvez sans doute l’améliorer : par exemple, vous pouvez ajouter des logs (s’ils n’existent pas) ou remanier des parties dupliquées. Le simple fait de formater le code pour en améliorer la lisibilité est d’une grande aide pour le prochain développeur qui travaillera sur cette partie à l’avenir.

 

Étape 9 : Signaler le bug

Utilisez un système de traçage des bugs ; générez un rapport de bug contenant :

  • la description du bug,
  • les causes de celui-ci,
  • le comportement attendu,
  • la résolution.

Ces systèmes sont très utiles : si le bug se reproduit, il sera facilement résolu. De plus, vous pouvez déléguer une partie de la résolution à d’autres membres de l’équipe en suivant les changements effectués ou l’évolution de la résolution du bug.

 

Vous avez relevé des bugs sur votre site ou votre application mais n’avez pas les compétences nécessaires pour le résoudre ? Des développeurs freelances sont disponibles sur Codeur.com. Trouvez l’expert dans le langage dont vous avez besoin en publiant votre projet gratuitement.

5
/
5
(
1

vote

)
Lire la suite de l'article

Newsletter WebActus

Abonnez-vous pour recevoir notre sélection des meilleurs articles directement dans votre boîte mail.

Nous ne partagerons pas votre adresse e-mail.

Articles similaires

Webmarketing

Hotmail intègre le Facebook Chat à son site web

Lors de la dernière mise à jour d’Hotmail (datant de septembre 2010), j’étais passé à coté de cette news. Hotmail avait intégré le Facebook Chat pour le rendre...

Publié le par Team WebActus
Webmarketing

Icons8 : un moteur de recherche pour télécharger des icônes gratuites

Focus sur un nouvel outil qui ravira les webdesigners : Icons8 ! Un moteur de recherche pour télécharger des icônes gratuites, de toute taille,...

Publié le par Ludwig Herve