Le problème avec ton discours c'est ce que tu as dit avant:
Le dire ainsi ce n'est pas pareil que de dire "j'ai utilisé le débogueur pendant 20 ans et au final aujourd'hui je travaille mieux sans". D'autant plus que tu parles de pragmatisme vs idéologie... ben quand tu te trouves à bosser sur une "archi non maitrise", tu fais quoi? Tu la recodes intégralement (idéologie) ou tu sors le débogueur (pragmatisme)? C'est pour ça que ton discours me laisse sceptique car pour moi ça sent le "je sais pas (bien) me servir de cet outil alors je préfère le dénigrer / dire qu'il sert à rien".
Les logs sont super utiles / indispensables. Le débogueur est super utile / indispensable. Pourquoi ne prendre que l'un ou l'autre? Pourquoi pas les deux? C'est très pragmatique...
La méthode pro en PROD c'est d'intercepter le crash depuis son appli pour générer un coredump / minidump, packager tout ça
avec les logs et envoyer le tout sur un serveur avec création de ticket. En tant que dev, tu récupères le tout, et avec un environnement bien foutu (symbol server), en ouvrant ton minidump le compilo va télécharger les mêmes versions de binaires que ce qui a craché en prod + les symboles de débogage. De cette manière tu te retrouves en 1 minute avec le code source sous les yeux, le contexte d'exécution (pile, registres etc...)... et les logs.
Pour être encore plus pro: au prochain crash similaire chez le client, on peut se rendre compte (via la stack trace) que le problème a déjà été corrigé dans une nouvelle version du logiciel. Et en informer le client immédiatement via une popup.
C'est ce que fait tortoise svn par exemple. Si on peut / veut pas mettre un tel système en place soi-même, on peut utiliser bugsplat par exemple.
Partager