Du traducteur: George Alan Hamel dans son article
partage sa propre expérience et parle de ce qui devrait être guidé par le développeur dans le processus de débogage.
Les outils modernes du développeur sont très étendus, il y a donc beaucoup de choix - des outils de débogage. Beaucoup d'entre eux sont automatisés, mais, malheureusement, cela ne fonctionnera pas pour commencer le débogage par gravité - il y a encore beaucoup de travail manuel. Parfois, il semble que le problème ne devrait tout simplement pas être, c'est impossible, tout devrait fonctionner. Mais ça ne marche pas. Afin de ne pas perdre de temps et de cellules nerveuses supplémentaires, j'ai trouvé des règles de débogage simples pour moi-même, que j'utilise. Je pense que quelqu'un pourrait les trouver controversés. Néanmoins, ils m'aident.
Skillbox recommande: "Mobile Developer PRO . "
Nous vous rappelons: pour tous les lecteurs de «Habr» - une remise de 10 000 roubles lors de l'inscription à un cours Skillbox en utilisant le code promo «Habr».
Règle 1. Il y a toujours une raison
Malgré des déclarations comme «C'est impossible», «Cela ne devrait pas fonctionner comme ça», «Il n'y a aucune raison pour que ce code ne fonctionne pas.»
Il y a toujours une raison, qu'il s'agisse d'un code de travail incorrect ou d'erreurs de compilation. Toujours. Même si le vérificateur dit que tout va bien. Parfois, nous plongeons trop profondément dans le code, perdant la vue d'ensemble. La plupart des applications classiques ou Web sont complexes. Tous comprennent de nombreux éléments. Parfois trop, alors nous pouvons faire une erreur dans l'un d'eux et l'oublier ou ne pas le remarquer.
Prenez du recul, respirez profondément. Regardez à nouveau le code. Ne vous fiez pas uniquement aux outils. Utilisez le cerveau et la logique. Pensez à la façon dont l'élément en cours sur lequel vous travaillez affecte tout le reste. Dans la plupart des cas, l'erreur appartient à la classe PMSIS (le problème se situe entre la chaise et la table).
Et pour l'amour du ciel, lorsque vous corrigez quelque chose, ne corrigez pas immédiatement dix erreurs potentielles. Sinon, vous serez confus, il sera extrêmement difficile de trouver une vraie erreur. Le débogage nécessite parfois un peu de patience: faites de petits changements pas à pas. Soyez méthodique et précis comme un scalpel, pas comme un fusil de chasse.
Règle 2. RTFM & WTFV
La plupart des développeurs sont des gens intelligents. Parfois même trop malin, au détriment de soi. Nous pensons tous que nous n'avons pas besoin de tutoriels de base, car vous pouvez immédiatement commencer à étudier des choses avancées.
Oui, bien sûr, dans certains cas, il n'y a pas de problème, en plus, nous apprenons au fur et à mesure que nous mettons en œuvre divers projets. Mais une situation peut se produire lorsque vous serez engagé dans un projet vaste et complexe pendant plusieurs semaines, puis il se trouvera que tout est basé sur la mauvaise prémisse - une erreur qui rend impossible tout travail supplémentaire. Cela peut s'appliquer au cadre, au langage, à l'outil. Vous perdez juste du temps.
Par conséquent, apprenez la règle qui, en anglais, ressemble à Lire le manuel F *** ing ou Regarder la vidéo F *** ing (d'où les abréviations dans le sous-titre).
Parfois, vous manquez juste un moment critique, une bagatelle, nécessaire pour le travail. Vous devez au moins vous familiariser brièvement avec les informations de base sur le produit que vous utilisez. Dans ma pratique, il y a eu de nombreux cas où les développeurs ont dépassé les délais en raison de lacunes dans la connaissance du langage ou des outils. Et c'étaient de bons spécialistes, ils ont simplement sauté à la fin du livre, manquant des mots importants de l'auteur au début.
De nouveaux frameworks apparaissent presque tous les jours, des langages ou leurs nouvelles versions sont également sortis avec une régularité enviable. Pour utiliser efficacement ces outils, nous devons comprendre comment ils fonctionnent.
Règle 3. Veuillez utiliser les règles 1 et 2.
Vous avez donc lu l'article et commencé à travailler. Après quelques heures, vous rencontrez le manuel, qui est important pour notre travail, et ... sautez-le. Non, cela ne fonctionnera pas, utilisez les règles ci-dessus. Personne n'a dit que ce serait facile.
Règle 4. Apprenez les modifications.
Au cours du processus, il arrive que les outils que vous utilisez changent. Si vous êtes un développeur Web, cette déclaration est particulièrement pertinente - les cadres, bibliothèques et outils JavaScript sont très souvent modifiés et mis à jour.
Heureusement, non seulement vous, mais de nombreux autres développeurs utilisent les mêmes outils. Ils partagent des informations sur les problèmes et les développements sur des ressources pertinentes comme Experts Exchange et StackOpen ou sur des forums spécialisés.
Recherchez des informations sur votre problème ou les modifications apportées à l'outil jusqu'à ce que vous le trouviez. S'il n'y a rien, relisez la règle n ° 1.
Règle 5. Reposez-vous et recommencez depuis le tout début.
Dans certains cas, nous ne voyons vraiment pas de forêts derrière les arbres. Plonger dans le code pendant de longues heures nous épuise mentalement et physiquement. Si vous avez déjà passé votre code trois fois et n'avez toujours pas trouvé la cause de l'erreur, alors il est temps de laisser votre cerveau se reposer.
Dans certains cas, une simple promenade en plein air conduit à une nouvelle pensée et aide à trouver immédiatement un problème. Parfois non, mais les tracas, l'agression ou le désespoir ne sont pas les meilleurs assistants de notre entreprise.
Ne regardez pas l'écran. Parlez avec un collègue, asseyez-vous en silence, car le bruit agit négativement. Prenez une collation à la fin. Si le temps le permet, dormez, oubliez votre son et votre sommeil profond. Parfois, j'ai réussi à trouver la réponse à la question qui me tourmentait après le sommeil.
Videz votre tête de toutes les guirlandes et détritus des tentatives précédentes pour trouver une erreur et regardez le problème sous un angle inattendu.
Eh bien ... oui, vous l'avez deviné. Nous revenons à la règle n ° 1.
Skillbox recommande: