Séance de debuggage
Publié le 28 February 2008, par Babozor dans la catégorie Outils
Petite séance de debuggage CSS avec Dame Tartine, qui pour l’occasion essaye de caser le plus grand nombre d’ordinateurs sur une même table.
Le debuggage c’est toujours un peu la galère, même en essayant de faire le code le plus propre possible et le plus cross-plateforme possible, il y a toujours du travail.
Que ce soit pour le CSS ou le javascript… plusieurs OS, plusieurs Browsers: pleins de possibilité de plantages et de merdouilles. Même si il est possible d’émuler plus ou moins certains navigateurs sur certaines machines, le meilleur moyen reste encore d’avoir physiquement ces différents environnements à disposition.
Le debuggage est aussi une galère pour les chefs de projets… puisque difficilement quantifiable, on peut estimer “à la louche” quel temps devrait prendre tel ou tel correction de bug, mais aucune estimation fiable.
Et vous c’est quoi votre méthode de debuggage?
le 28 February 2008 à 15h29
Ca, c’est l’horreur !
C’est un vrai gouffre, des fois sans fond.
Pour éviter au maximum un phase de débugage trop périlleuse, les graphistes doivent tester leurs intégrations sous les divers navigateurs : IE 6/7, FF, Safari, etc…
Ensuite une fois l’intégration intégrée dans le CMS, hop, retest, et généralement, c’est là que ça fait mal.
Les CMS ont leurs propres feuilles de styles et ça peut générer des conflits.
Bref, un gros soucis, on est en train de travailler mains dans la mains avec les graphistes pour que l’intégration se fasse au maximum en utilisant et en surchargeant directement les class, id et div utilisé par le CMS.
A la fin de tout ça, on a une check list. Le site n’est pas releasé tant que tout n’est pas coché.
le 28 February 2008 à 16h00
Perso je fais les tests directement à l’intégration avec IE6, FF2 et Opera 9. Tant qu’un élément ne s’affiche pas exactement comme il faut dans les trois je passe pas à l’élément suivant (sauf sur certain site ou les vieux navigateur sur lequel on décide de n’offrir qu’une sous version du design, sans les possibilités offertes par les CSS 2.1).
Après avec l’expérience il y a certaines erreurs qu’on ne fait plus, les problèmes de haslayout, les différents modèles de boites, les tailles de police en em… que de temps perdu avant d’en maîtriser les subtilités !
Une fois le design fait, je le place dans le CMS et cette fois c’est un check général (Opera 9 et 9.5, FF, IE6 et 7, Safari) pour être bien sûr. Mais en général, quand ça marche dans FF2, c’est bon pour Opera / Safari. Le seul problème c’est les IE (j’enfonce une porte ouverte là non ? ^^).
Pour débuguer si il reste des erreurs :
- CSSVista
- Firebug
- Patiente
le 28 February 2008 à 16h54
Ca me fait tellement chier d’aller sous Windows que mes sites sont pas débuggés pour IE6/7 (et comme X11 fonctionne pas sur mon Mac je peux pas essayer sur OSX). Bon je sais c’est pas bien et je passerais toute une journée cette semaine pr faire ce débuggage ^^
J’essaye dans la limite du possible de réutiliser des styles et des layouts que j’ai déjà utiliser sur d’autres sites, c’est déjà ça à pas débugger à chaque fois.
le 28 February 2008 à 17h35
Très franchement ça dépend du projet, de son importance, si je tiens à rester W3C compliant ou pas…
Sinon, d’une manière générale, je “débuggue” le CSS au fur et à mesure, dès que j’ai fini d’intégrer une nouvelle partie.
En ce qui concerne le PHP, des tests unitaires à base de PHPUnit, et l’utilisation du debuggeur dans Eclipse.
Pour le C/C++, GDB et DDD à fond, avec Valgrind.
le 28 February 2008 à 23h49
La fameuse règle des 80%-20%… C’est encore plus galère sur des gros projets complexes avec beaucoup de pages totalement différentes.
On a un scénario de navigation assez poussés, des testeurs et pas mal de remontées de bugs, à la fois des CDP ou directement du client.
Pour les navigateurs c’est du classique : Firefox, IE6 et 7, Safari, Opera.
Que de temps perdu donc !
le 29 February 2008 à 11h18
Pour limiter le nombre de machine, la virtualisation est très pratique…
Un petite machine virtuelle avec un vieux IE5.5 et windows 2000
Un petite machine virtuelle avec un vieux IE6 et windows XP
…
La seule machine supplémentaire nécessaire c’est un mac avec Safari.
Ensuite évidemment FireFox pour travailler, IE7 pour tester, Opéra pour afiner… on corrige les bugs IE 5.5 puis Safari, puis Firefox !
Il faut de l’entrainement.
le 2 March 2008 à 11h13
@Lucio : Sinon une seule machine virtuelle sous XP + MultipleIE ça permet d’avoir les différentes versions d’IE sous XP sans rien casser.
le 4 March 2008 à 13h25
Idem, virtualisation à gogo.
le 4 March 2008 à 23h44
Salut,
Moi je fais tout à partir de Firefox, en évitant d’utiliser des propriétés ou pseudo-class qui, on le sait, ne seront pas supportées par IE. Et ensuite seulement je commence le débugage sous IE6 et 7. J’apprends toujours. C’est vraiment pas marrant.