Reprise du message précédent :
j'ai jamais gouté à xdebug, du coup ca me manque pas,  
mais je vais essayer tiens

Débugger du code à coup de printf, var_dump, console.log, c'est la pauvreté du dev ça.
Alors que foutre un point d'arrêt dans ton code et faire du pas à pas dans ton IDE c'est quand même plus efficace.

On n'est pas du tout dans un contexte front, ni la conversation actuelle, ni ce topic !    
 
Même si ce topic c'est spécialisé dans le front ces quelques dernières pages, ça reste un topic de dev web d'un point de vue général, front et back
 
OOps, on est dans la catégorie HTML / CSS, effectivement
 
J'ai toujours mal considéré ce topic alors    
 
Désolé  

Je suis pas du tout de cet avis. J'ai toujours été super à l'aise avec du debug à coup de log et pas avec un debugger.
C'est vraiment personnel je trouve.
D'ailleurs quand j'avais lu l'excellent bouquin "Coders at work" http://www.codersatwork.com/ t'avais en gros la moitié qui utilise un debuger, les autres à coup de log.
Donc ce choix n'a rien à voir avec la qualité du dev

Tu debug objectivement beaucoup mais alors beaucoup plus vite/efficacement avec un debugger quand même ...Je sais que c'est vendredi mais quand même

Pas nécessairement, et ça dépend de ce que tu debug

Sauf à avoir un debugger temporel genre rr, mais c'est généralement pas le cas.

Débugger tout le temps à coup de log est contreproductif, tu perds un temps fou à comprendre ce qu'il se passe, alors qu'un bon debugger des familles fait le taf.
Je débug avec les 2, à coups de logs quand j'ai besoin de connaitre des valeurs pour des actions appellées 1000x mais pour un truc appelé 1 fois je sort le point d'arrêt

Bof, je suis moyennement d'accord.
Ecrire un console.log et faire F5 n'est pas forcément plus long que d'aller chercher ton JS dans chrome chercher la ligne etc. et mettre ton point d'arrêt.

ouais mais le console.log va pas te permettre de savoir ce qu'il se passe sur d'autres variables
et autre avantages, tu vas dans la console et tu peux exécuter une commande JS en utilisant les variables qui se trouve dans ta fonction où tu es actuellement arrêté. Ca peut rendre service parfois.

Faut voir de quoi on parle aussi...

- afficher le contenu d'un array d'une fonction basique qu'on est en train de coder en live ? oui un log est surement suffisant

- Trouver/analyser un bug complexe alors qu'on sait même pas où regarder/poser des logs avec un gros framework des familles qui génère une stack monstrueuse ? => debugger, ya même pas à argumenter

Bref ca dépend de la grosseur du projet, de la chiantitude du bug à corriger, de si on sait où regarder à la base et de la facilité du debugger à utiliser.

Exemple, dans nodejs, un console.log et utiliser le debugger chrome est quasiment aussi facile/rapide.. Sauf que coté debugger j'ai accès en live à la stack, les watchers, etc

 
Avec un bon editeur/IDE, tu fais ca directement depuis le dit editeur/IDE.
Si t'as un editeur miteux, tu peux toujours rajouter

pour que le debugger du navigateur stoppe automatiquement a cet endroit.

et donc pour des boucles , tu fais next next  next ho putain chuis trop loin
 
pour tout ce qui est problème asynchrone, l'usage est aussi limité
 
Les cas ou je sors debugguer plutôt qu'un console.log amélioré sont rares

Je suis intéressé par ton truc pour le faire direct dans l'IDE, j'utilise intelliJ, j'ai pas trop cherché mais lancer mon JS en débug est plus chiant qu'autre chose

https://www.jetbrains.com/help/webs [...] n=old_help

C'est bien ce que j'avais essayé, j'ai trouvé ça plutôt chiant et pas pratique
 
ps : le truc du debugger; dans le code c'est magique je connaissais pas merci

Tu peux pas revenir en arrière dans la stack et recommencer dans ce cas? Ou un point d'arrêt conditionnel?

Sacré vendredi. Du moins j'espere

 
that

Une de mes armes favorites reste le conditional breakpoint avec un console.log comme expression.

Dans safari t'as même pas besoin de ce hack, les breakpoints peuvent être configurés comme des probes (exécutent une série d'actions mais n'arrêtent pas le programme): https://webkit.org/blog/5435/breakpoint-options/

On ne supporte que Chrome 64 bit pour notre application, je ne touche jamais aux autres navigateurs.

Pas d'accord (cf + haut).

Nan mais les gars si vous connaissez pas bien vos stacks au point de devoir avoir besoin d'un debugger pour fouiller les tréfonds d'un framework bloaté, le pb c'est pas le debugger en fait

tu fais du web qui ne s'execute que sur une plateforme ?  et tu viens me dire que safari ios n'est pas si pourri ?  
joli vendredi

C'est vendredi

La stack ca permet par exemple de savoir quel event a lance l'execution du code.
Pas besoin d'un framework bloate pour avoir besoin de ca.

 
Ou peut être qu'on bosse pas sur une appli simpliste

 
Oui.
 
Et je dis que les perfs js de safari mobile ne sont pas pourries, oui.

 
J'ai bossé sur des projets à 700kloc, j'ai pas eu besoin de debugger
+ sérieusement lisez le bouquin c'est très intéressant.

 
Le nombre de lignes de code comme mesure de complexité, sacré vendredi décidément  

De la même manière que certains préfèrent un IDE à un éditeur, le choix des outils de debug c'est personnel.
Y a aucune mesure objective sur ce sujet, ça dépend des technos, des projets, de la connaissance du projet par le dev...

J'ai travaillé sur un logiciel à 30MLOC: c'est sur que c'est facile.

Quand tu fais une single page app et que c'est très dynamique, tu ne vas pas t'amuser à recharger la page pour inspecter la valeur d'une nouvelle variable. Oui ça marche, mais c'est très lent.

ma question c'était plutot pour du dev back, donc php/python/.net/java/node.js
 
parce que la question pour moi c'est comment connecter le debugguer si la machine de dev n'héberge pas le serveur de dev

En php, xdebug peut se connecter à distance

Je te laisse relire avec le doigt le passage où j'ai écris "ça dépend des technos"

 
Oui mais pas facilement... Par exemple pour faire cela avec un ec2, il faut mettre un tunnel SSH en place sur le port 9000. Ça pose aussi un problème si plusieurs personnes dev en même temps sur le même serveur...

Sur la JVM y a pas vraiment de différence entre se connecter à un serveur d'application local ou distant.
Après ça peut être plus ou moins chiant d'accéder au port à travers ton réseau, en effet.
 
Mais en pratique à moins de devoir debugger un truc qui dépend d'une architecture que tu peux pas reproduire facilement sur ta machine de développement, je vois pas trop pourquoi tu ferais ça.
Avec un framework récent qui embarque le serveur d'application, c'est facile d'avoir des tests qui couvrent les fonctionnalités de bout en bout. Ça devrait normalement suffire, mais si tu veux vraiment pousser la chose il y a Docker.

Ben si ta machine de dev est sous win et que tu déploies sous Linux par ex  
Du coup ça veut dire Virtualbox, et en pratique les mêmes contraintes qu'un serveur distant

Non parce que t'as pas de notion de partage d'environnement avec d'autres dev (bon après ça dépend de ce que t'appelles un env de dev sur un serveur distant aussi ).

tu as raison, alignons le vocabulaire :
- serveur de dev : serveur à usage exclusif du developpeur qui bosse dessus (je sais que dans certaines boite y'a aussi un environnement appelé Dev qui sert à plusieurs dev, mais bon)
- serveur d'intégration : serveur où plusieurs dev bossent en meme temps

Pour le serveur de dev (exclusif), tu as plusieurs choix :
- la machine de dev est le serveur (ie l'IDE tourne sur le meme OS que le serveur)
- la machine de dev hoste le serveur de dev dans une VM (tu peux y accéder via le portmapping)
- la machine de dev est connectée à un environnement dans le cloud, genre un linode, un beanstalk/EC2, etc... (tu peux y accéder via un tunnel SSH)

si t'es pas dans le cas #1, t'as 2 challenges :
- déployer ton code sur le serveur de dev (d'après les réponses, une grosse partie des gens se base sur Git en fait)
- connecter ton débugguer / te connecter à l'executable pour le monitorer / executer tes tests (là les réponses étaient plus floues)

le cas 1 peut présenter le challenge que tu peux dev sur un OS différent que celui sur lequel tu déploies

le but de certaines questions de mon "sondage" c'était de savoir comment vous gérer ces problématiques là...y'a déjà eu pas mal d'éléments de réponse

La machine de dev connectée à un environnement dans le cloud, ça me semble être une fausse bonne idée. Ta connexion internet saute, tu peux plus bosser