Analyse des erreurs courantes commises par les programmeurs novices, pt. 1

Bonjour le monde! Une fois que vous avez appris tout ce que vous devez savoir et que vous vous êtes enfin mis au travail en tant que stagiaire ou développeur junior, vous pouvez probablement vous détendre, n'est-ce pas ? Non. Tout ne fait que commencer pour vous... Vous êtes entouré de beaucoup de nouveautés et d'incompréhensibles. Comment ne pas tout foutre en l'air dès le départ ? C'est ce dont nous allons parler aujourd'hui. Dans cet article, je veux analyser les erreurs courantes des débutants et donner quelques conseils, basés sur ma propre expérience, sur la façon de les éviter. Alors, commençons sans plus tarder :

1. Peur de demander de l'aide à des collègues plus expérimentés

Nous sommes tous humains. Nous avons tous peur d'avoir l'air stupide, surtout aux yeux de nos nouveaux collègues plus expérimentés. Lorsque les développeurs prennent leur premier emploi, ils sont souvent guidés par cette peur et, avec une oreille lourde, se replient sur eux-mêmes, essayant de tout comprendre par eux-mêmes. De plus, quelqu'un peut être entouré de collègues plus expérimentés, qui, à leur tour, sont capables de l'orienter dans la direction la plus prometteuse, aidant à éviter plus d'erreurs et de "bosses sur la tête" inutiles. Alors rappelez-vous : n'ayez pas peur de poser des questions. Vous êtes débutant et tout le monde le comprend parfaitement. Lorsque vous demandez, personne ne vous battra avec des bâtons. Peut-être même le contraire se produira-t-il : vous vous lierez plus rapidement d'amitié avec vos collègues et commencerez à apprécier une communication plus active avec eux. JE' J'en dirai encore plus : plus vous poserez de questions et discuterez de divers problèmes techniques, plus vite vous pourrez vous débarrasser de votre peau de débutant vert et devenir un expert dans votre domaine. Et encore un conseil. Ne soyez pas étranger àStackOverflow . Je parle spécifiquement de poser des questions sur cette ressource. D'une part, il faut un certain temps pour obtenir une réponse à votre question. Mais d'un autre côté, vous pouvez rapidement apprendre plusieurs approches pour résoudre votre problème et le regarder sous un angle légèrement différent. Je tiens également à noter qu'il y a des avantages pratiques à écrire des commentaires/réponses et à rédiger des questions de clarification sur les questions StackOverflow d'autres développeurs : vous avez la possibilité de débattre et d'approfondir les problèmes, sans parler d'un boost de karma.

2. Ne pas essayer de rechercher des informations par vous-même

Cette erreur pourrait être considérée comme le revers de la précédente.Ici, je veux dire lorsque vous commencez à harceler vos collègues et connaissances à propos de chaque problème ou hoquet que vous rencontrez. Demander, c'est bien, mais n'exagérez pas avec des questions. Sinon, les gens pourraient simplement vous trouver ennuyeux. Si vous êtes confus à propos de quelque chose, la première chose à faire est d'exercer vos compétences de recherche dans le meilleur moteur de recherche - Google. Quelqu'un d'autre a déjà rencontré l'écrasante majorité d'erreurs incompréhensibles et d'autres problèmes. Et vous serez assez surpris si vous googlez votre question et voyez le nombre de personnes qui connaissent un problème similaire, et qui ont déjà reçu des réponses exhaustives que vous pouvez appliquer dans votre propre travail. C'est pourquoi vous entendrez souvent vos collègues répondre par "Google it". Enfiler' Ne vous offusquez pas de cette réponse, votre collègue n'est pas votre professeur personnel qui doit transmettre toutes les subtilités de votre domaine de travail. Les étendues infinies d'Internet seront votre mentor. Parfois, les programmeurs sont également appelésles personnes ayant une ceinture noire dans la recherche Google . Donc, si nous avons un "hoquet", nous cherchons d'abord le problème sur Google. Si aucune solution ne peut être trouvée (c'est rare, mais cela arrive), alors seulement nous commençons à demander à nos collègues. Les questions immédiates visent à obtenir des conseils sur l'approche que vous devriez choisir pour résoudre un problème plutôt que ce que vous feriez lorsque vous rencontrez un ralentisseur ou un message d'erreur incompréhensible. Après tout, ils peuvent voir au-delà de votre approche préférée et prédire immédiatement où une approche donnée mènera à long terme.

3. Copier et coller aveuglément

Mais googler les problèmes et leurs solutions a ses pièges. Par exemple, copier et coller aveuglément .Cela se produit généralement lorsque vous trouvez un problème similaire (mais peut-être pas exactement le même) et une solution associée, par exemple, sur StackOverflow. Vous saisissez cette solution et la copiez-collez sans entrer davantage dans les détails. Et puis vous ou vos collègues découvrez des bogues étranges ou un comportement incorrect dans votre code. Et personne ne peut immédiatement deviner d'où ils viennent. Finalement, bien sûr, l'endroit avec le code copié sera trouvé, et vous ne serez certainement pas félicité pour votre solution. Par conséquent, lorsque vous trouvez une solution prête à l'emploi sur StackOverflow (ou ailleurs), vous devez d'abord bien comprendre le quoi, le comment et le pourquoi. Peut-être recherchez-vous la fonctionnalité pertinente sur Google et lisez la documentation correspondante. Et ce n'est qu'après avoir fait cela que vous devriez l'ajouter à votre projet.

4. S'en tenir à la mauvaise solution

Lors de la rédaction d'une solution, vous constaterez parfois qu'elle devient de plus en plus compliquée, pour finalement arriver à une impasse. Et puis vous essayez de rendre la solution encore plus élaborée afin de la faire fonctionner d'une manière ou d'une autre au lieu de chercher une autre alternative plus appropriée. Peut-être avez-vous l'impression d'avoir investi beaucoup de temps et d'efforts et avez-vous donc décidé que, quoi qu'il arrive, vous n'abandonnerez pas et vous résoudrez le problème avec votre approche existante. Ce n'est pas tout à fait la bonne attitude. Du moins en programmation. Plus tôt vous essayez une approche différente, plus vous gagnerez de temps à la fin. N'ayez donc pas peur d'expérimenter et d'essayer d'autres approches, quel que soit le temps que vous avez investi dans votre approche actuelle. De plus, en essayant plusieurs approches et en approfondissant le sujet, vous

5. Peur de poser des questions sur votre mission actuelle

Travailler sur un projet de développement logiciel revient généralement à effectuer des tâches spécifiques. Par exemple, dans Jira. Ces tâches ne sont pas toujours décrites clairement et en détail. Les descriptions de tâches sont généralement rédigées par des chefs d'équipe, qui sont aussi de simples mortels. Ils peuvent oublier d'ajouter quelque chose ou ne pas tenir compte du fait que vous n'êtes pas familier avec telle ou telle fonctionnalité. Ou peut-être n'avez-vous aucun accès au projet (par exemple, accès à la base de données, au serveur de journalisation, etc.). Et maintenant, vous avez reçu la tâche, l'avez étudiée pendant plus de deux heures, mais vous êtes toujours assis là, à regarder l'écran avec perplexité. Au lieu de continuer à essayer sans succès de comprendre cela, vous devriez commencer à demander des éclaircissements ou des conseils à celui qui a créé la tâche. Par exemple, dans l'application que votre équipe utilise pour la communication (par exemple, Microsoft Teams), vous pouvez poser des questions ou faire un commentaire direct concernant la tâche. D'une part, si vous écrivez votre question dans un message personnel, vous obtiendrez probablement une réponse plus rapidement, puisque la personne verra immédiatement votre question. D'autre part, en posant une question dans Jira, vous établissez la preuve que vous faites quelque chose, à savoir analyser le problème. Il existe un moyen d'accélérer ce processus : posez votre question dans un commentaire dans Jira puis dans un DM, déposez un lien vers votre commentaire et demandez à y jeter un œil.

6. Placer des attentes irréalistes envers le chef d'équipe

Encore une fois, c'est le revers du point précédent. Le chef d'équipe est le chef d'une équipe de développement. En règle générale, votre chef d'équipe consacre la majeure partie de son temps à divers types de communication. Pourtant, il écrit aussi du code pour ne pas tout oublier de la programmation. Vous l'aurez compris, la vie d'un chef d'équipe est très chargée. Tirer sur la manche de votre chef d'équipe chaque fois que vous avez besoin d'éternuer ne sera évidemment pas agréable. Imaginez que chaque membre de l'équipe bombarde le responsable avec un tas de questions. Cela pourrait rendre n'importe qui fou, n'est-ce pas ? Et si vous accumulez beaucoup de questions, votre chef d'équipe devra passer beaucoup de temps à vous répondre. Que peut-on faire pour réduire le nombre de questions adressées au chef d'équipe :

• Explorez la documentation du projet plus en profondeur pour réduire le nombre d'angles morts.
• Adressez vos questions aux autres membres de votre équipe. Ils peuvent être aussi familiers avec cette fonctionnalité que le responsable, voire plus, puisque la fonctionnalité a très probablement été écrite par l'un d'entre eux.

Alternativement, vous pouvez consulter les annotations dans l'IDE pour savoir qui et quand le code d'une ligne spécifique a été modifié pour la dernière fois. C'est précisément ainsi que vous pouvez savoir qui est la personne la plus appropriée pour poser votre question. Comme vous le savez probablement déjà, lorsqu'il s'agit de questions au chef d'équipe, tout comme pour les questions aux collègues, vous devez essayer de trouver un juste milieu - n'ayez pas peur de poser des questions, mais n'en posez pas trop d'eux.

7. Peur des revues de code

Une revue de codeest une telle étape qui se produit avant que vous ne soumettiez votre code à une application commune (à une branche partagée, par exemple, master ou dev). Cette vérification est effectuée par un développeur qui n'est pas impliqué dans la tâche, dont les yeux neufs peuvent détecter des erreurs, des inexactitudes ou des défauts dans votre style de code qui sont passés inaperçus lorsque vous avez initialement écrit votre code. S'il y a des critiques, elles sont laissées en commentaires sur certaines parties du code. Dans ce cas, le développeur qui a écrit le code doit corriger les erreurs identifiées dans l'examen (ou discuter de ses décisions avec l'examinateur, éventuellement le convaincre qu'elles sont correctes). Ensuite, le code est soumis à révision encore et encore jusqu'à ce que le réviseur n'ait plus de commentaires. Le réviseur agit comme une « passerelle » avant que le code ne soit validé. Le défi est que de nombreux programmeurs novices perçoivent la révision du code comme une critique et une condamnation. Ils n'apprécient pas les revues de code et en ont peur. Ils ne devraient pas. Les révisions de code sont exactement ce qui nous permet d'améliorer notre code. Après tout, nous recevons des informations importantes sur ce que nous faisons mal et sur ce à quoi il convient de prêter attention. Vous devez considérer chaque révision de code comme faisant partie de la courbe d'apprentissage, quelque chose qui peut vous aider à vous améliorer. Lorsque quelqu'un commente votre code, il partage avec vous son expérience et ses meilleures pratiques. Personnellement, je ne crois pas que l'on puisse devenir un bon programmeur sans passer par des revues de code. Parce que vous n'êtes même pas conscient de la qualité de votre code et si un étranger expérimenté signalerait des erreurs. Je n'apprécie pas les revues de code et j'en ai peur. Ils ne devraient pas. Les révisions de code sont exactement ce qui nous permet d'améliorer notre code. Après tout, nous recevons des informations importantes sur ce que nous faisons mal et sur ce à quoi il convient de prêter attention. Vous devez considérer chaque révision de code comme faisant partie de la courbe d'apprentissage, quelque chose qui peut vous aider à vous améliorer. Lorsque quelqu'un commente votre code, il partage avec vous son expérience et ses meilleures pratiques. Personnellement, je ne crois pas que l'on puisse devenir un bon programmeur sans passer par des revues de code. Parce que vous n'êtes même pas conscient de la qualité de votre code et si un étranger expérimenté signalerait des erreurs. Je n'apprécie pas les revues de code et j'en ai peur. Ils ne devraient pas. Les révisions de code sont exactement ce qui nous permet d'améliorer notre code. Après tout, nous recevons des informations importantes sur ce que nous faisons mal et sur ce à quoi il convient de prêter attention. Vous devez considérer chaque révision de code comme faisant partie de la courbe d'apprentissage, quelque chose qui peut vous aider à vous améliorer. Lorsque quelqu'un commente votre code, il partage avec vous son expérience et ses meilleures pratiques. Personnellement, je ne crois pas que l'on puisse devenir un bon programmeur sans passer par des revues de code. Parce que vous n'êtes même pas conscient de la qualité de votre code et si un étranger expérimenté signalerait des erreurs. re faire mal et ce qui vaut la peine de prêter attention. Vous devez considérer chaque révision de code comme faisant partie de la courbe d'apprentissage, quelque chose qui peut vous aider à vous améliorer. Lorsque quelqu'un commente votre code, il partage avec vous son expérience et ses meilleures pratiques. Personnellement, je ne crois pas que l'on puisse devenir un bon programmeur sans passer par des revues de code. Parce que vous n'êtes même pas conscient de la qualité de votre code et si un étranger expérimenté signalerait des erreurs. re faire mal et ce qui vaut la peine de prêter attention. Vous devez considérer chaque révision de code comme faisant partie de la courbe d'apprentissage, quelque chose qui peut vous aider à vous améliorer. Lorsque quelqu'un commente votre code, il partage avec vous son expérience et ses meilleures pratiques. Personnellement, je ne crois pas que l'on puisse devenir un bon programmeur sans passer par des revues de code. Parce que vous n'êtes même pas conscient de la qualité de votre code et si un étranger expérimenté signalerait des erreurs.

8. Propension aux décisions obscures

Diverses tâches/problèmes peuvent souvent avoir plusieurs solutions différentes. Et parmi toutes les solutions disponibles, les débutants ont tendance à utiliser les plus complexes et les plus obscures. Et cela a du sens : les programmeurs novices ont appris hier de nombreux algorithmes, modèles et structures de données différents, de sorte que leurs mains sont impatientes d'en implémenter certains. Croyez-moi, j'étais comme ça, donc je sais de quoi je parle :) J'ai eu une situation où j'implémentais certaines fonctionnalités pendant longtemps. Cela s'est avéré très, très compliqué. Ensuite, le développeur senior a réécrit mon code. Bien sûr, j'étais très intéressé de voir quoi et comment il l'a changé. J'ai regardé sa mise en œuvre et j'ai été étonné de voir à quel point c'était plus simple. Et il y avait trois fois moins de code. Et aussi étonnamment, les tests automatisés pour cette fonctionnalité n'ont pas été supprimés ou modifiés ! En d'autres termes, la logique générale est restée la même. De là, je suis arrivé à la conclusion queles solutions les plus ingénieuses sont toujours simples . Après cette réalisation, le codage est devenu beaucoup plus facile et la qualité de mon code est passée à un niveau nettement supérieur. Alors quand vaut-il la peine d'appliquer des modèles de conception et des algorithmes sophistiqués, demandez-vous ? Lors de leur application sera la solution la plus simple et la plus compacte.

9. Réinventer la roue

La roue est une solution durable qui a été inventée il y a longtemps. Dans cet anti-modèle, le développeur implémente sa propre solution propriétaire pour un problème déjà résolu. Parfois, ces solutions existantes sont meilleures que celles proposées par le programmeur. En règle générale, réinventer la roue entraînera une perte de temps et une baisse de productivité, car la solution que vous trouverez peut être loin d'être la meilleure, ou bien, vous pourriez ne pas en trouver du tout. Cela dit, nous ne pouvons pas exclure la possibilité de créer notre propre solution indépendante : si nous le faisions, il ne resterait alors que la programmation par copier-coller. Le programmeur doit être correctement guidé par les tâches de programmation spécifiques qui se présentent afin de les résoudre avec compétence et rapidité, que ce soit en utilisant des solutions toutes faites ou en créant des solutions personnalisées. D'un côté, dans les universités et dans les cours en ligne, nous sommes bombardés de différents types de tâches qui semblent conçues pour nous aider à réinventer les roues. Mais seulement à première vue : le véritable objectif ici est de développer la pensée algorithmique et une maîtrise plus profonde de la syntaxe du langage. Ces tâches vous aident également à mieux comprendre les algorithmes et les structures de données, et vous donnent les compétences nécessaires pour implémenter des homologues plus sophistiqués, si nécessaire (c'est parfois nécessaire, mais c'est extrêmement rare). Dans la vraie vie, vous n'avez pas besoin d'inventer votre propre roue dans l'écrasante majorité des cas, car les roues qui répondent à vos besoins existent depuis longtemps. Peut-être que votre inexpérience vous empêche de connaître l'existence d'implémentations de la fonctionnalité dont vous avez besoin. C'est là qu'il faut prendre les conseils donnés au premier point de cet article, à savoir, demander de l'aide à des collègues plus expérimentés. Ils pourront vous guider (par exemple, vous orienter dans la bonne direction dans votre recherche Google) ou vous suggérer une implémentation spécifique (par exemple, une bibliothèque).

10. Défaut de passer des tests

Tous les débutants n'aiment pas écrire des tests. Mais pourquoi devrions-nous isoler les débutants, ici ? Les développeurs plus expérimentés n'aiment pas non plus écrire des tests, mais ils comprennent mieux pourquoi les tests sont nécessaires. Lorsque vous êtes complètement vert, vous vous demandez pourquoi vous devriez les écrire. Tout fonctionne, il ne peut donc pas y avoir d'erreur. Mais comment vous assurez-vous que vos modifications n'endommageront pas quelque chose ailleurs dans le système ? Vos collègues n'apprécieront pas si vous introduisez des changements qui font plus de mal que de bien. C'est là que les tests viennent à notre secours. Plus le code d'une application est couvert par des tests, mieux c'est (c'est ce qu'on appelle la couverture de code ou la couverture de test). Si l'application a une bonne couverture de test, vous pouvez exécuter tous les tests pour trouver les endroits qui seront cassés par votre code. Et comme je l'ai dit dans l'exemple ci-dessus, lorsque le développeur senior a refactorisé le code, les tests n'ont pas échoué. C'est parce que la logique générale n'a pas changé. Nous utilisons des tests pour démontrer si la logique de certaines fonctionnalités a changé ou non. Donc, même si vous n'aimez pas écrire des tests, ils sont certainement utiles et valent bien le temps passé dessus.

11. Commentaires excessifs

De nombreux développeurs souffrent de perfectionnisme et les débutants ne font pas exception. Ils ne manifestent parfois qu'une facette de cette propension lorsqu'ils se mettent à commenter tout et tout le monde. Même en faisant des commentaires inutiles, car le code est tellement évident :

Cat cat = new Cat(); // Cat object

Tous les programmeurs débutants ne réalisent pas immédiatement que commenter du code n'est pas toujours bon, car les commentaires superflus encombrent le code et le rendent difficile à lire. Et que se passe-t-il si le code change, mais que les anciens commentaires ne sont pas mis à jour ? Alors ils ne feront que nous induire en erreur et nous confondre. Alors pourquoi faire un tel commentaire ? Habituellement, un code bien écrit n'a pas besoin d'être commenté , puisque tout ce qu'il contient est déjà évident et lisible. Si vous avez besoin d'écrire un commentaire, vous avez déjà gâché la lisibilité du code et essayez de remédier à la situation. La meilleure approche est d'écrire du code lisible dès le départ, c'est-à-dire du code qui n'a pas besoin de commentaires. Je ne peux pas non plus m'empêcher de mentionner la nécessité de suivre les conventions de dénomination correctes pour les méthodes, les variables et les classes. Voici ma règle : Le meilleur commentaire est soit aucun commentaire, soit un nom correct qui décrit clairement la fonctionnalité de votre application.

12. Mauvaise dénomination

Les débutants jouent vite et librement dans leur nommage des classes, des variables, des méthodes, etc. Par exemple, en créant une classe dont le nom ne décrit pas du tout son objectif. Ou ils déclarent une variable avec un nom court, quelque chose comme x . Ils quand deux autres variables nommées n et ysont créés, se rappeler de quoi x est responsable devient très difficile. Face à cette situation, il faut bien réfléchir au code, l'analyser au microscope (peut-être à l'aide d'un débogueur), étudier la fonctionnalité afin de comprendre simplement ce qui se passe. C'est là que les conventions de nommage correctes que j'ai mentionnées ci-dessus viennent à notre aide. Les noms corrects améliorent la lisibilité du code, réduisant ainsi le temps nécessaire pour se familiariser avec le code, car l'utilisation d'une méthode est beaucoup plus facile lorsque son nom décrit approximativement sa fonctionnalité. Tout dans le code est composé de noms (variables, méthodes, classes, objets, fichiers, etc.), ce point devient donc très important lors de la création d'un code correct et propre. N'oubliez pas que le nom doit avoir une signification, par exemple, pourquoi la variable existe, ce qu'elle fait, et comment il est utilisé. Je noterai plus d'une fois que le meilleur commentaire pour une variable est de lui donner un bon nom. Pour une étude plus approfondie des commentaires et une dénomination correcte, je recommande de lire les classiques intemporels :"Clean Code : Un manuel de l'artisanat logiciel agile" par Robert Martin . Sur cette note, la première partie de cet article (mes réflexions) est terminée. À suivre...