Beaucoup de choses qui semblent complètement évidentes pour un développeur expérimenté ne le sont pas pour un débutant. Je ne parle pas d'écrire du code, de connaître les modèles, etc. Cela s'applique à la façon de penser en général: comment résoudre le problème, comment demander, comment ne pas susciter la colère des mentors de vos aînés . Aujourd'hui, nous allons essayer d'en parler.
Les méthodes de pensée rationnelle (ici) sont des questions qui doivent être posées à chaque étape de la réflexion sur un problème. Avec leur aide, vous pouvez rapidement prendre la bonne décision et construire plus efficacement votre travail.
Question 1. Quelle est la raison?
Selon la loi de la méchanceté, lorsque vous lancez l'application pour la première fois, quelque chose ne fonctionnera certainement pas. Vous devez d'abord essayer de déterminer vous-même la cause de l'erreur. La façon la plus simple est de regarder la console. Peut-être que le texte d'erreur sera suffisant pour comprendre comment le corriger.
Question 2. Ai-je fait tout ce que j'ai pu?
Même si le texte d'erreur n'a pas aidé, ne vous précipitez pas vers les personnes ayant une question. Vous devez d'abord vous assurer que tout ce qui est possible a été fait. Vous pouvez vérifier quelque chose comme ceci:
- J'ai vérifié la documentation de l'application pour une solution à ce problème
- J'ai googlé et je n'ai rien trouvé
- J'ai googlé en anglais et je n'ai rien trouvé
- Aucun des conseils trouvés ne m'a aidé.
Si la réponse est oui partout, passez au paragraphe suivant.
Question 3. Je semble perplexe. Pourquoi?
Vous pouvez demander une solution à votre mentor / mentor / patron / ami. Peut-être que vous avez juste oublié de parler d'elle. Cependant, la question ne doit pas se limiter aux mots «quelque chose ne fonctionne pas», toutes les données d'entrée disponibles doivent y être incluses. Une question bien conçue fait gagner du temps à votre mentor et vous aide à travailler plus efficacement. Essayez de vérifier que la question est «complète»:
- Texte d'erreur spécifié
- Un cas est indiqué dans lequel vous avez rencontré une erreur (jusqu'aux commandes de lancement)
- Les méthodes de solution éprouvées sont indiquées.
Profit! Dans les plus brefs délais, vous recevrez une solution au problème et un profond respect de la part de vos collègues. Alors, passons au développement des tâches.
Question 4. Ma solution résout-elle complètement le problème?
Parlons maintenant de la façon de terminer une tâche. Astuce: la bonne question pour vous.
S'il s'agit d'un bug, cela vaut la peine d'être vérifié: le problème est-il résolu ou masqué? Par exemple, il existe une fonction qui doit renvoyer un nombre, mais elle renvoie (soudainement) une chaîne. En convertissant le résultat à l'emplacement de l'appel de fonction, vous pouvez masquer le problème. Mais, peut-être, il vaut la peine de faire la transformation à l'intérieur et de résoudre ainsi complètement le problème.
Une fonctionnalité ou un bug, ne soyez pas paresseux à la fin pour vérifier tous les cas possibles. Comme le montre la pratique, l'expression «devrait fonctionner» provoque de terribles bugs et un mécontentement encore plus terrible du côté de la réception.
Question 5. Pourquoi suis-je sûr de cela?
Voyons immédiatement un exemple: il est temps d'intégrer différentes parties d'une grande application. Le backend associé à la tâche junior est développé depuis longtemps. Il lance une fonctionnalité de son côté et ... tout se bloque! Assez rapidement, il détermine que le backend est gelé. On pourrait immédiatement dire: «Le problème n'est pas de mon côté», abandonner la tâche et vaquer à nos occupations. Mais le Rational Junior pensera: «Si la tâche backend est marquée comme terminée, elle a probablement été testée. Pourquoi suis-je sûr que le problème est dans le backend? " Peu importe de quel côté est le problème. Il est important qu'il ne vienne pas chez un autre développeur sans vérifier le comportement de son côté.
Question 6. Pourquoi cela at-il été fait?
Il faut tenir pour acquis que des gens raisonnables travaillent et n'écriront pas de bêtises (au moins exprès). Quand il semble que quelqu'un a écrit une ligne dans le code qui est superflue, vous devriez réfléchir à deux fois avant de la supprimer. Même si cela résout complètement le problème. Les moyens les plus probables de ne rien sauter:
- Afficher le dernier message de validation modifiant cette ligne
- Afficher la tâche de validation (souvent indiquée dans le message de validation)
- Voir qui a fait le commit et lui demander, après avoir parlé de sa tâche
En conclusion, je veux ajouter une chose: il n'est pas nécessaire de suivre toutes les alliances de cet article, mais il faut penser constamment et penser de manière indépendante .