Problématique du débogage

Le débogage est une activité complexe, elle peut être coûteuse en temps et avoir un impact économique important pour le client final.


L'impact du débogage sur les projets

Dans le cadre de la gestion de projet, cette activité n'est pas forcément abordée de manière pragmatique :

  • Les bugs sont-ils répertoriés (cause et symptômes... pas seulement les incidents/corrections) ?
  • Le coût des bugs est-il évalué (coût pour les clients, temps de correction) ?
  • Forme-t-on les développeurs à déboguer ?
  • A-t-on les bons outils pour trouver rapidement l'origine d'un problème ?
  • A-t-on les bons outils pour valider le fonctionnement d'un logiciel ?

L'activité de débogage prend un temps significatif lors d'un développement. Pourtant, elle n'est que rarement identifiée de manière explicite, on parle souvent de la séquence :
        Analyse > Spécification > Développement > Tests.

Or, cette séquence ne fait pas apparaître que l'activité de débogage se trouve à la fois dans le "Développement" et les "Tests", deux activités qui ne sont pas forcément menées par la même personne !


Les catégories de bugs

Les bugs se répartissent en grandes catégories :

  • triviaux : symptômes clairement identifiés, causes triviales
  • simples : reproductibles, causes proches des symptômes
  • complexes : reproductibles, causes "éloignées" des symptômes
  • aléatoires : non reproductibles
  • "Heisenberg ou Heisenbug" : bugs qui disparaissent quand on essaie de les tracer, ou quand on utilise un débogueur

Par définition, un ensemble de lignes de code fraîchement écrites/compilées est bogué (environ un 'bug' toutes les 20 lignes).

La réponse d'HookTrack

HookTrack apporte une réponse à cette problématique en mettant en oeuvre 3 principes fondamentaux :

  • Économiser le temps du développeur.
  • Améliorer la courbe d'apprentissage de l'activité "débogage" en la rationalisant.
  • Impacter au minimum le fonctionnement de l'application.

Optimisation du temps passé à déboguer

Accès rapide aux valeurs des variables, paramètres et objets :
         par survol de la souris ou via des IHM dédiées

Code colorisé et interactif, bulle d'aide sur les ressources et les méthodes

Accès rapide au code source concerné dans toutes les IHM HookTrack

Outils efficaces pour l'analyse des temps de réponse et celle des fuites mémoire

Traces ultra détaillées

Possibilité de désactiver dynamiquement les fonctionnalités susceptibles de dégrader les temps de réponse de l'application


Rationaliser l'activité de débogage

Profils d'utilisation prédéfinis et personnalisables : traces, debug et tests d'intégration

Reporting unifié d'alertes et d'erreurs détectées :
        quelle que soit l'erreur détectée (mémoire, natstar, sql, tuxedo, windows), elle est affichée dans une boîte de dialogue qui donne le message d'erreur le plus complet possible, qui affiche la pile des appels et qui permet d'ignorer ou d'afficher le code concerné.

L'ensemble de IHM permet au développeur d'avoir une vision centralisée du contexte d'exécution :
        code - variables - paramètres - objets - typedef - buffers tuxedo - requêtes Sql - segments NCL - Curseur DB ...


Impacter au minimum le fonctionnement de l'application

Vous utilisez vos lanceurs ou '.exe' tels quels : aucune modification de votre application n'est requise.

Aucune variable d'environnement n'est à positionner pour les traces.

Vous pouvez passer à la volée HookTrack en mode "sans interaction" : vous retrouvez ainsi le comportement exact de votre application.

Il n'y a pas de 'préinitialisation' des variables locales : HookTrack ne change pas le fonctionnement de votre application.