Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Atteint de JavaScriptite Aiguë [Cyril Durand]

Expert ASP.net Ajax et WCF, Cyril Durand parle dans son blog de point techniques sur ASP.net, ASP.net Ajax, JavaScript, WCF et .net en général. Cyril est également consultant indépendant, n'hésitez pas à le contacter pour de l'assistance sur vos projets

Actualités

  • Blog de Cyril DURAND, passionné de JavaScript, Ajax, ASP.net et tout ce qui touche au developpement Web Client-Side.

    N'hésitez pas à me contacter pour vos projets .net : architecture, accompagnement, formation, ...

    View Cyril Durand's profile on LinkedIn
    hit counters


    Expertise Commerce server et BizTalk

10 conseils non techniques pour debugger votre application - applicable à toutes technologies

Lorsque l'on code, on passe une grande partie de notre temps à debugger notre code, voici donc 10 conseils que j'applique lorsque je rencontre un problème. Il s'agit de conseils non techniques et qui s'appliquent à tous type de développement.

1. Lire le message d'erreur

Bien souvent le message d'erreur donne la solution ou alors des informations très importantes ! Lisez et relisez le message d'erreur jusqu'a ce que celui-ci ne contienne plus aucun secret. Souvent, le message d'erreur contient le Stack Trace, si vous avez les sources de la méthode qui pose problème, étudier bien cette méthode. Dans le cas d'un Stack Trace .net, vous pouvez utilisez Reflector avec sa fonction Analyze.

2. Reformuler la question / Posez-vous les bonnes questions

Votre application plante ! Ne restez pas bloqué sur ce fait. Chercher à comprendre qu'est-ce qui déclenche ce comportement. Reformulez le problème, expliquez-vous en détail le problème. Pour ma part j'essaye de m'expliquer le problème comme si je l'expliquais à une personne ne connaissant pas l'application.

3. Chercher plus simple

Bien souvent on cherche des explications compliquées, c'est pourtant souvent les explications les plus simples qui fonctionnent le mieux. Commencez donc par éliminer les erreurs simples : connectivité à la base de données, configuration, etc ...
Puis lisez le code qui ne fonctionne pas, faites en sorte de comprendre le chemin qu'est censé prendre votre application. Pour cela on peut utiliser du pas à pas. S'il y a peu de code, faire tourner le code dans votre tête. Pour les applications .net, ou peut utiliser la fonction Analyze de Reflector.

4. Ne vous focalisez pas sur votre clavier

Personnellement, je ne peux pas travailler sans un crayon et un bloc-notes. Je gribouille beaucoup dessus, je fais des schémas pour m'expliquer le problème, noter mes idées, etc ...
Ce cahier n'est pas fait pour contenir des notes importantes sur le projet, celles-ci doivent être accessible à tous les contributeurs du projet. Ce bloc-notes doit contenir seulement des idées, schémas d'explication, etc ...
Ceux qui me connaissent savent à quel point j'utilise du papier pour faire des schémas & co, schémas qui deviennent illisible au bout de 10 min mais permettent de bien illustrer les concepts.

5. Comprendre et réécrire le code 

Si votre code bug le minimum est de comprendre le code : pour cela lisez-le et faites le jouer dans votre tête ou sur papier !
- Si le code est court et que vous savez ce que dois faire le code mais que vous comprennez pas ce que le code fait actuellement, réécrivez-le. Rajouter des commentaires pour qu'un collègue ne supprime pas lui aussi votre code lors du prochain debug ...
- Si vous ne savez pas exactement ce que dois faire le code, renommez les variables, exploser votre longue méthode en petites méthodes, utilisez la POO, ...
Sur ce sujet, je vous conseille vivement de lire ce post :
>> http://weblogs.asp.net/fredriknormen/archive/2008/10/12/is-it-important-to-write-good-code.aspx

Bien choisir le nom de vos variables est important, je passe beaucoup de temps à chercher le bon mot, si après coup je trouve que le nom est mal choisis, je le renomme même lorsque le code est "finit" et que l'application fonctionne bien.

6. Reproduire et simplifier le problème :

Si vous réussissez à reproduire le problème dans votre application mais que vous ne voyez pas d'où vient le problème. Créez une application (ou une autre page pour ASP.net) "bidon" dans laquelle vous rajoutez (ou supprimez) différentes parties du code jusqu'à avoir le minimum de code pour reproduire le problème. Ainsi vous vous concentrerez sur l'essentiel.
Il ne faut surtout pas hésitez à créer des applications "bidons", la à encore, ceux qui me connaissent savent que j'aime faire des projets "inutiles" juste pour démontrer un concept.

7. Prendre l'air / dormir / manger

Au bout de 2/3 heures de recherche d'un problème vous n'avez plus les idées claires, vous vous êtes surement lancé sans succès dans de nombreuses pistes sans résultat et vous allez surement vous focalisez sur des hypothèses aberrantes. Dans ce cas il est bon de faire une pause, de dormir un peu ou alors de reprendre des forces !

8. Partez du principe que le bug est dans VOTRE code

Combien de fois j'ai entendu : "grrrr c'est encore un bug de window/.net" puis après quelques temps, il s'est avéré que le bug se trouvait bel et bien dans notre code.
Ne partez jamais du principe que le bug se trouve dans le framework .net ou le système d'exploitation, ce genre de bug arrive mais il est beaucoup plus fréquent que le bug vienne de vous ou de votre collègue ce qui revient (presque) au même.

9. Partager le problème

Si au bout de quelques heures de debug vous ne voyez pas de solution, n'hésitez pas à partager le problème avec un collègue, de préférence choisissez un collègue qui connaisse peu le projet, cela vous forcera à lui réexpliquer le problème de zéro : le contexte, etc ...  On revient ainsi au point N°2.
Cela m'est arrivé plus d'une fois que l'on commence à m'expliquer le souci et que l'on me dise merci avant même que je comprenne ce que me voulait ce collègue.
Si malgré tout, vos collègues ne trouvent pas d'explications, utilisez les forums. Dans ce cas soyez le plus explicite possible. Précisez le contexte, le type d'application, ce que vous avez déjà essayé, etc ...

10. Comprendre les bidouilles quand elles fonctionnent

Quand on debug, il arrive que l'on change un paramètre de l'application pour tester sans vraiment comprendre son incidence, on espère juste que ce paramètre va magiquement résoudre le problème.
Lorsque cela fonctionne, il faut comprendre pourquoi ce paramètre à résolu le problème ! Lire la documentation associée est souvent un bon point de départ. Si cela ne suffit pas pour comprendre l'action du paramètre : faites une application "bidon" qui mettra en évidence l'action de ce paramètre, retour au point 6.

Je vois souvent des personnes qui bidouillent les CSS jusqu'a ce que cela fonctionne, au final les règles CSS contiennent plus de choses inutiles qu'utiles. Chaque règle CSS étant plus ou moins liée à d'autre règle, la bidouille non comprise va entrainer une autre bidouille non comprise et ainsi de suite. Au final, le fichier CSS sera construit sur des bidouilles ce qui rend toute modification très complexe voir impossible, vous allez alors demander de l'aide auprès de personnes connaissant bien CSS qui ne pourra pas grand chose si ce n'est reprendre de 0 votre fichier CSS.

C'est particulièrement visible dans le cas d'une feuille de style CSS, mais le problème peut s'appliquer pour tous types de développement.


Et vous ? Vous avez d'autres conseils de debug ?

Posted: mercredi 22 octobre 2008 12:17 par cyril
Classé sous : , ,
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

NeuroCypher a dit :

T'as bien raison.

# octobre 22, 2008 14:41

Promesses a dit :

Je trouve que ce genre de conseils est manquant dans le monde du développement.

On ne s'attache à la technique rien que la technique et on peut rester des heures sur un problème flagrant.

Merci pour ce post.

# octobre 22, 2008 16:20

Mat a dit :

tout à fait d'accord avec vous les gars.

# octobre 23, 2008 10:35

mranchin a dit :

Très bon post

je rajouterai:

Observer (log, indicateurs diverses...) avant de trop faire de théories.

Diviser pour conquérir (éliminer au fur et à mesure)

Changer une seule chose à la fois avant de tester

Reproduire dans un test le bug

Si le bug n'est pas corrigé il n'est pas corrigé même si on arrive plus à le reproduire

# octobre 23, 2008 18:08

nickadele a dit :

Bon post !

Ca sent le vévu ;)

# octobre 24, 2008 14:10
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01