Stratégie de débogage de framework javascript externe

Question

En travaillant avec Extjs, GeoExt et OpenLayers, j'ai de plus en plus tendance à rencontrer des problèmes qui n'entraînent pas d'erreurs javascript directes (IE, FF ou similaire). Il pourrait s'agir de fonctionnalités ne fonctionnant pas, comportement inattendu et ainsi de suite.

Ma stratégie habituelle consiste à réduire le code à un minimum en espérant découvrir où le problème se pose - Firebug et l'outil de débogage IE sont généralement d'excellents compagnons. Google et divers forums sont toujours d'une grande aide - SI un problème similaire a été documenté par un autre utilisateur et SI le problème a été formulé de manière à ce que je le trouve. Mais quand il s'agit d'utiliser des frameworks plus grands tels que Extjs et OpenLayers, je trouve cela très difficile quand mon débogage me conduit dans le monde des frameworks de méthodes mystérieuses. Poser des questions ici et dans d'autres forums peut donner des résultats fantastiques, mais parfois je ne peux pas indiquer quel est le problème - seulement le résultat que je vois sur l'écran. En utilisant plusieurs frameworks, il peut y avoir des interférences entre eux, un comportement inattendu lors de l'utilisation de ces frameworks et en général compliquant le débogage.

Que me conseillez-vous de faire dans ces situations? Que faites-vous normalement - J'aimerais ramasser un tour ou deux :)

Answer 1

Je ressens votre douleur. J'utilise beaucoup YUI et parfois les erreurs sont aspirées dans une fosse sans fin de code YUI qui ne génère pas d'erreur en soi mais ne fait pas ce que je pense qu'il devrait faire. Dans les cas où j'ai la chance qu'une erreur soit lancée dans un code étranger, je regarde la pile d'appels de Firebug et commence le débogage à la première place de la chaîne où je trouve mon propre code.

Dans le cas des erreurs de déglutition de la fosse sans fond, alors j'ai recours à l'établissement de points d'arrêt dans mon code à des endroits suspects et mon chemin à travers. Firebug est très, très utile ici car il vous permet de définir dynamiquement des points d'arrêt et des points d'arrêt conditionnels. Dans les deux cas ci-dessus, je ne réduis jamais au minimum mon problème car le bug peut être dû à la complexité. En outre, la définition des points d'arrêt est beaucoup plus facile. A propos de la seule fois que je réduis mes problèmes au minimum, c'est quand je dois poster ici ou sur comp.lang.javascript.

Maintenant, si le bug n'apparaît que dans IE, j'abandonne habituellement pour la journée, je rentre chez moi et je reviens demain. C'est une stratégie étonnamment efficace jusqu'à ce que mon patron décide que nous devons pousser le code pour vivre ce soir (dans ce cas, je pleure juste à l'intérieur).