Bien que je ne puisse pas énumérer tous les pièges, souvent, formuler une question et la transformer en un problème à part entière prend souvent tellement de travail que, au moment où vous l'avez suffisamment préparée, vous avez répondu à votre propre question plus en détail le temps qu'il aurait fallu autrement.
Je ressens la même chose pour plus de 75% des questions que je poste.
Cependant, ce n'est pas un argument pour ne pas prendre la peine de le faire. C'est effectivement un débogage de canard en caoutchouc. Vous trouvez des réponses aux questions qui, selon vous , pourraient surgir en réponse à votre question; ce qui signifie que vous envisagez le problème du point de vue de différentes personnes; ce qui signifie que vous pensez au problème dans toutes les directions possibles; qui est la meilleure façon de trouver la faille.
Au mieux, vous avez prouvé de façon concluante que vous ne pouvez clairement pas trouver la réponse ici. Au "pire", vous finissez par répondre à votre propre question. Faites attention aux citations, car ce n'est pas mal du tout. C'était peut-être un peu inefficace, mais résoudre le problème lentement est mieux que de décider rapidement de ne pas s'attaquer au problème . Vous aurez plus vite à résoudre le problème éventuellement.
Exemple:
Quand j'étais un développeur débutant, j'ai traité de nombreuses fois avec la page ASP.Net eror . J'avais besoin de Google le message pour comprendre ce qui ne va pas. Cela pourrait prendre plusieurs heures avant que je trouve la bonne solution. En gros, j'ai commis chaque erreur dans le livre et j'ai ensuite dû gérer les conséquences de devoir déboguer les problèmes.
Maintenant, quand une erreur survient, je connais déjà les "suspects habituels" de ce qui pourrait causer le problème. Ma liste mentale de "suspects habituels" est effectivement basée sur les problèmes avec lesquels j'ai le plus de problèmes au cours de ma carrière. Sans avoir au préalable effectué le travail fastidieux sur les jambes de Google, je n'aurais jamais fait cette liste mentale . Mais maintenant que j'ai cette liste mentale, le dépannage est beaucoup plus rapide.
En outre, bien que je ne puisse pas tout à fait mettre le doigt dessus, la réactivité d'une conversation libre ne peut être égalée par aucune forme de discussion textuelle sur Internet à laquelle je peux penser.
Je suis un peu en désaccord ici. Vous avez raison, la communication Internet est moins sensible, mais vous avez tort (à mon avis) de penser que cela est mauvais pour vous.
En tant que développeur isolé, vous dépendez du débogage du canard en caoutchouc. L'ingrédient clé pour faire fonctionner le RDD est que vous anticipez les questions que le canard en caoutchouc peut avoir pour vous. Vous ne pouvez évidemment pas vous fier à ce que dit le canard en caoutchouc.
Lorsque vous traitez avec des systèmes de messagerie lents (publication sur StackOverflow ou communication en écrivant des lettres), vous êtes intrinsèquement incité à vous assurer de bien faire les choses dès la première fois. Parce que le besoin de corriger une erreur sera un processus lent et ardu.
En comparaison, considérons que les systèmes de messagerie rapide (conversation, messagerie instantanée) permettent de corriger immédiatement quelque chose. La capacité de corriger rapidement quelque chose rend les gens moins incités à s'assurer que c'est correct.
Quatre cas d'espèce:
- Lorsque je fais ma propre analyse / liste de tâches en tant que développeur, j'utilise toujours un crayon et du papier. J'ai remarqué que je dissimule les hypothèses et les mensonges lorsque je tape mes notes, parce que mon esprit pense que «je peux facilement résoudre ce problème plus tard». Cependant, avoir à corriger quelque chose que vous avez écrit sur du papier est ennuyeux, vous devez rayer des choses et écrire entre les lignes et le document paraît tellement pire quand il porte des gribouillis. Ecrire sur papier me fait vérifier les faits avant de m'engager à l'écrire. Cela attrape beaucoup de malentendus tôt, avant même d’écrire du code qui produirait des bugs.
- Ma grand-mère était secrétaire (âge de la machine à écrire). Faire une faute de frappe dans un document officiel signifiait avoir à taper à nouveau la page entière. Ma tante est secrétaire (âge du traitement de texte). Elle peut compter sur un correcteur orthographique automatique et les erreurs peuvent être corrigées facilement et avec un minimum d'effort. Sans surprise, ma grand-mère fait beaucoup moins de fautes de frappe et de fautes d'orthographe que ma tante.
- Auparavant, les jeux vidéo étaient imprimés sur des cartouches. Corriger un bogue après la publication était presque impossible. Vous devez réimprimer toutes les cartouches, les distribuer à tous les fournisseurs et espérer que ceux-ci pourront en quelque sorte entrer en contact avec les clients qui ont déjà acheté le jeu. Cela coûterait des tonnes d'argent (le double du coût de production physique) et n'atteindrait toujours pas certains clients. Aujourd'hui, à l'ère des correctifs Internet, les développeurs de jeux ont montré qu'ils investissaient beaucoup moins dans le test de leurs jeux afin d'éviter les bogues de publication, car il est beaucoup plus facile de simplement appliquer directement un correctif à chaque client. L'impact d'une erreur est minimisé à un point tel qu'il est préférable de régler quelques problèmes après coup, plutôt que d'avoir à tester tous les problèmes possibles. les erreurs qui pourraient survenir.
- J'habitais dans un appartement au troisième étage, sans ascenseur, et je devais souvent garer une ou deux rues de mon immeuble. Je n'ai presque jamais oublié de prendre quelque chose dans ma voiture. Maintenant, je vis dans une maison avec ma voiture juste à côté de moi dans l'allée. J'oublie de prendre des choses dans ma voiture tout le temps .
L'idée sous-jacente est qu'un système d'échange difficile incite les gens à effectuer des échanges corrects et vérifiés . La sévérité de la peine (= processus de correction difficile) vous apprend à ne pas commettre d'erreur.
En outre, le fait de cacher des détails pour poser une question bien définie élimine la possibilité que quelqu'un repère des problèmes auxquels vous n'aviez pas pensé.
Lorsque vous créez un MCVE , vous ne devez pas simplement le créer et le poster dans la question. Vous devez d'abord le faire vous - même , afin de pouvoir isoler le problème. Et puis, quand vous pensez que le problème ne peut plus être réduit, et que vous n'en voyez toujours pas la cause; alors vous avez une question valide pour StackOverflow.
Exemple:
J'ai toujours un deuxième Visual Studio en cours d'exécution avec une application de console simple appelée Sandbox. Chaque fois que je rencontre un problème technique, je copie le code incriminé dans le bac à sable et commence à jouer avec.
- Que se passe-t-il quand je change ce réglage?
- Puis-je reproduire le problème si je raccourcis le code?
- Quels paramètres permettent / impossible de reproduire le problème?
Dans 90% des cas, je trouve la cause du problème parce que le bac à sable m'a aidé à examiner le code incriminé sans être distrait par le contexte (ou par exemple toute incertitude sur les valeurs associées à différentes parties du code).
Dans les 10% restants, il me reste un code minimal pour reproduire le problème, qui constitue un exemple parfait d'extrait de code à publier sur StackOverflow.
Dernier point mais non le moindre, je ne veux pas publier tout mon projet pour que le monde entier le regarde pour le reste de l'éternité, pour des raisons évidentes.
Lorsque vous avez déjà votre MCVE, vous ne devriez pas avoir trop d’informations personnelles (ou d’entreprise). Si vous le faites, puisque le code est minimal, il est facile de renommer les choses en un exemple plus basique foo / bar / baz.