Apprendre la logique du code

Bonjour,

Je suis développeur Front-End depuis un certain temps et je m'intéresse de plus en plus au Back-End.
Pour le moment je n'ai pas les ressources nécessaires pour une vrai formation. Je suis entrain de m'auto-former en suivant divers tutos vidéos sur les framework PHP, la POO, JQUERY, AJAX, etc... Mais j'ai remarqué quelque-chose. Lorsque je suis face à un débuguage de code (JS ou PHP), je me sens bloqué. Certes je n'ai pas encore assez d'expérience, mais je pense qu'il doit y avoir une méthode de réflexion "rapide" (plus ou moins répétitive) pour débuguer le code d'un autre ou installer un module dans lequel il faut modifier du code pour qu'il marche comme on le veut.

J'essai de connaître les "réflexes" à avoir dans ce cas.
Ce genre de chose, on l'apprend quand on fait une école de DEV et qu'on a le temps de s'éxercer.

Est-ce que quelqu'un connaîtrait une méthode de réflexion lorsque l'on est face au code (surtout quand ce n'est pas le sien et qu'il n'est pas commenté) ?
Est-ce que quelqu'un connaitrait également un site qui met à disposition des exercices de différents niveau avec leurs réponses, pour que je puisse m'entraîner ? j'en est trouvé sur Google, mais je ne sais pas ce qu'ils valent. Je cherche des exercices de qualité et diversifiés.

Merci par avance pour votre aide,
Bien cordialement,

hlcgperso a écrit :
Bonjour,

Je suis développeur Front-End depuis un certain temps et je m'intéresse de plus en plus au Back-End.
Pour le moment je n'ai pas les ressources nécessaires pour une vrai formation. Je suis entrain de m'auto-former en suivant divers tutos vidéos sur les framework PHP, la POO, JQUERY, AJAX, etc... Mais j'ai remarqué quelque-chose. Lorsque je suis face à un débuguage de code (JS ou PHP), je me sens bloqué. Certes je n'ai pas encore assez d'expérience, mais je pense qu'il doit y avoir une méthode de réflexion "rapide" (plus ou moins répétitive) pour débuguer le code d'un autre ou installer un module dans lequel il faut modifier du code pour qu'il marche comme on le veut.

J'essai de connaître les "réflexes" à avoir dans ce cas.
Ce genre de chose, on l'apprend quand on fait une école de DEV et qu'on a le temps de s'éxercer.

Est-ce que quelqu'un connaîtrait une méthode de réflexion lorsque l'on est face au code (surtout quand ce n'est pas le sien et qu'il n'est pas commenté) ?
Est-ce que quelqu'un connaitrait également un site qui met à disposition des exercices de différents niveau avec leurs réponses, pour que je puisse m'entraîner ? j'en est trouvé sur Google, mais je ne sais pas ce qu'ils valent. Je cherche des exercices de qualité et diversifiés.

Merci par avance pour votre aide,
Bien cordialement,

Bonjour,
L'une des premières choses que fait un développeur lorsqu'il est confronté à un programme dont il n'est pas l'auteur est de se procurer le code source dudit programme.
Pour javascript, c'est assez simple dans la mesure où ce code figure soit directement dans le source de la page HTML, soit dans un fichier externe lié à cette page et que l'on peut télécharger.
Si la page est générée dynamiquement via PHP, Java, ASP, etc. c'est plus délicat car ce code réside sur le serveur et n'est pas, a priori, accessible sauf à faire ami-ami avec le responsable du site et le soudoyer pour obtenir ledit code.
La seconde étape consiste ensuite, après avoir parcouru visuellement le code, à l'exécuter "pas à pas", c'est à dire instruction par instruction, via le debogueur correspondant, après avoir placé un "point d'arrêt" à l'endroit à partir duquel on veut démarrer / reprendre l'analyse.
Là aussi, les choses diffèrent selon qu'il s'agit de javascript ou de langage dynamique.
Pour javascript, les navigateurs récents permettent tous de tracer l'exécution du code, de façon intégrée mais avec plus ou moins de facilité ou stabilité de l'outil.
Pour PHP et consorts, cela nécessite par contre d'avoir recours à un éditeur de code tel qu'Eclipse ou autre, permettant de lancer un serveur et exécuter le code à tracer.
Là aussi, les EDI (Eclipse, etc.) sont plus ou moins performants et stables pour cette tâche.
Pour résumer, le traçage du code est quasiment incontournable pour connaître tous les méandres d'un code existant car la simple lecture de ce code ne permets qu'une approche grossière. Se représenter mentalement l'enchaînement des instructions peut s'avérer (très) fastidieux.
À noter également que certains outils se sont spécialisés dans la rétro documentation orientée code et fournissent des diagrammes type UML ou des ordinogrammes permettant de visualiser les enchaînements et plus particulièrement les instructions de branchement telles que les IF, WHILE, etc.
Ceci concerne essentiellement les langages dynamiques tels que Java, par exemple. Peut-être en existe-t-il pour javascript, mais je n'ai pas fait de recherche à ce sujet.
Concernant la formation stricto sensu, le web regorge de tutoriels, y compris en français, et un certain nombre d'ouvrages HTML / CSS sont disponibles pour apprendre les fondamentaux du développement web. Je te conseillerai donc de t'investir sur ces fondamentaux dans un premier temps et notamment bien saisir la distinction et la façon de faire cohabiter "techniquement" la couche contenu (balises HTML) et la couche présentation (CSS), sans te préoccuper de javascript, PHP ou autre.
Dans un second temps, tu pourras apprendre / tester javascript, de façon interne ou externe à la page HTML.
Troisième niveau, l'apprentissage d'un langage dynamique tel que PHP, Java, ASP, etc. permettant d'élargir nettement les possibilités de construction des pages HTML, notamment en accédant aux bases de données.
Pour chacun de ces niveaux, tu trouveras par ailleurs des tutoriels vidéos, parfois très bien réalisés et didactiques, permettant d'approfondir un point particulier.
Vidéos disponibles sur Youtube et autres plateformes du même genre. Perso j'apprécie celles mises en ligne par Graphikart, car très détaillées et précises, mais il en existe une multitude d'autres de qualité.
Les intervenants sur le forum t'en indiqueront sûrement un certain nombre.

hlcgperso a écrit :
Est-ce que quelqu'un connaîtrait une méthode de réflexion lorsque l'on est face au code (surtout quand ce n'est pas le sien et qu'il n'est pas commenté) ?

1) Pleurer
2) Demander à son patron si c'est une mauvaise blague
3) Pleurer
4) Essayer de déléguer la tâche et se décharger de toute responsabilité

Blague à part, le but d'utiliser des librairies/plugins/frameworks est de ne pas réinventer la roue, de laisser à d'autres l'expertise dont on ne dispose pas. En terme de temps, analyser le code d'un autre sans la moindre documentation (réelle ou implicite) peut être aussi gourmand que de le coder. De plus cela demande une grande expertise. Le mieux est d'éviter de se mettre dans ce genre de situation.

hlcgperso a écrit :
installer un module dans lequel il faut modifier du code pour qu'il marche comme on le veut.

Modifier un module ne se fait pas. Selon les systèmes le plugins dispose de hooks pour s'adapter, mais on ne touche pas à son code. Il faut généralement considérer un module/plugin comme une boîte noire: on vérifie que ce qu'on lui donne est correct (directement à l'entrée), et on vérifie que ce qu'il retourne/effectue est cohérent directement à la sortie. Si les résultats sont inattendus, qu'il n'y a pas de doc, de projet avec des bugs listés, etc. c'est qu'il faudrait penser très sérieusement à en utiliser un autre.

Le meilleur réflexe à adopter, est très certainement donc d'éviter de ce mettre dans ce genre de situations en choisissant les bon outils.

Pour ma part, je dirais que la première étape du débogage se passe lors du développement en organisant correctement ses scripts.
Un script mal agencé peut devenir quasiment indebogable dans le sens où il sera parfois plus rapide (et plus sain pour notre santé mentale) de le réécrire entièrement.

Du code bien rédigé se déboguera en s'assurant que chaque étape se déroule convenablement.
Les collègues ont décrit divers solutions assistés et très pratique.
Il reste la solution "manuelle" en plaçant des flags (console log, alert...) à des étapes clés du code et ainsi repérer progressivement la cause du problème.
Modifié par erwan21a (12 Sep 2016 - 14:19)

Bonjour et merci pour vos réponses.
Je suis désolé de répondre aussi tardivement.

Merci sepecat pour ton résumé:)

Je vois que la clé de voûte du débuguage c'est le point d'arrêt.
J'essai d'en mettre un maximum, néanmoins j'ai encore l'impression de passer à côté du problème.
De toute manière, il faut s'expérimenter, encore et toujours pour s'améliorer en débugage apparemment.

Merci encore à vous tous pour votre aide
Bien cordialement,