Analyse des erreurs typiques des programmeurs débutants : partie 1

Bonjour le monde! Une fois que vous avez appris tout ce dont vous avez besoin et que vous avez finalement été embauché en tant que stagiaire ou junior, vous pouvez probablement vous détendre, n'est-ce pas ? Peu importe comment c'est ! Tout ne fait que commencer... Il y a beaucoup de choses nouvelles et incompréhensibles autour de vous, et comment ne pas se tromper comme ça dès le départ ? C'est de cela dont nous parlerons aujourd'hui. Dans cet article, je souhaite examiner les erreurs courantes commises par les débutants et donner quelques conseils tirés de ma propre expérience sur la façon de les éviter. Alors commençons sans plus attendre :

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

Nous sommes tous humains et nous avons tous peur de paraître stupides, surtout aux yeux de nos nouveaux collègues plus expérimentés. Une fois qu'ils ont obtenu leur premier emploi, les développeurs cèdent souvent à cette peur et se replient inconsolablement sur eux-mêmes, essayant de tout comprendre par eux-mêmes. Dans le même temps, une personne peut être entourée de collègues plus expérimentés qui, à leur tour, seront en mesure de la guider dans un premier temps sur le chemin le plus correct, ce qui contribuera à éviter davantage d'erreurs et de « bosses » inutiles. N'oubliez donc pas : n'ayez pas peur de poser des questions : vous êtes un débutant, et tout le monde le comprend parfaitement. Si vous le demandez, personne ne vous frappera avec des bâtons. C’est peut-être même l’inverse : vous vous lierez plus rapidement d’amitié avec vos collègues et commencerez à communiquer plus activement avec eux. J'en dirai plus : plus vous posez et discutez de diverses questions techniques, plus vite vous pourrez sortir de la peau d'un débutant vert et devenir un expert dans votre domaine. Et encore un conseil. Ne négligez pas StackOverFlow . Dans ce contexte, j'entends 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 immédiatement découvrir plusieurs approches pour résoudre le problème actuel et l'examiner sous un angle légèrement différent. Je voudrais également noter qu'écrire des commentaires-réponses, clarifier les questions sur StackOverFlow d'autres développeurs, en plus d'un plus en karma, présente un avantage pratique : vous avez la possibilité de discuter et de comprendre ce problème plus en profondeur.

2. N'essayez pas de rechercher des informations par vous-même

Peut-être que cette erreur est l’envers de la précédente. Je veux dire quand vous commencez à attaquer vos collègues et connaissances pour chaque problème ou problème. Poser, c’est bien, mais il ne faut pas aller trop loin dans les questions, sinon vous risquez de vous ennuyer. La première chose à faire si un point incompréhensible apparaît est d'appliquer vos compétences de recherche dans le meilleur moteur de recherche - Google. Quelqu'un a déjà rencontré la grande majorité des erreurs incompréhensibles et d'autres problèmes. Et vous serez assez surpris si vous recherchez sur Google et voyez le nombre de personnes qui connaissent un problème similaire et qui ont déjà reçu des réponses complètes pouvant être utilisées dans leur travail. Sur cette base, vous pouvez souvent entendre un collègue répondre à une question : « Google ». Vous ne devriez pas être offensé par cette réponse, car après tout, votre collègue n'est pas un professeur personnel qui doit transmettre toutes les subtilités de votre domaine de travail. Les étendues infinies d’Internet vous aideront dans ce type de mentorat. Parfois, un programmeur est également appelé une personne ceinture noire dans la recherche Google . Par conséquent, lorsque nous sommes bloqués, nous cherchons d'abord le problème sur Google, et si aucune solution n'est trouvée (rarement, mais cela arrive), nous commençons alors à interroger nos collègues. Cela vaut la peine de leur demander tout de suite, non pas en cas de problème ou d'erreur incompréhensible, mais lors du choix d'une approche pour résoudre un problème. Après tout, ils peuvent voir au-delà de la vôtre et dire immédiatement comment telle ou telle approche peut aboutir à long terme.

3. Copier-coller aveugle

Mais rechercher le problème sur Google et, par conséquent, sa solution comporte des pièges. Par exemple, copier-coller aveugle . Cela se produit généralement lorsque vous trouvez un problème similaire (mais peut-être pas exactement le même) et qu'en dessous, par exemple, sur StackOverFlow, il y a une solution. Vous prenez cette solution, la copiez et la collez vous-même, sans trop entrer dans les détails. Et puis vous ou vos collègues du projet découvrez des bugs étranges ou un comportement incorrect de votre fonctionnalité. Et tout de suite, personne ne sait d’où viennent les jambes. Ensuite, bien sûr, une place avec ce code sera trouvée, et vous ne serez certainement pas félicité pour cette décision. Par conséquent, lorsque vous trouvez une solution toute faite sur StackOverFlow (ou ailleurs), vous devez tout d'abord l'analyser en détail, de quoi il s'agit, comment et pourquoi. Peut-être recherchez-vous cette fonctionnalité sur Google et consultez-la documentation. Et seulement après cela, implémentez-le dans votre projet.

4. Lancer la mauvaise solution

Lors de la rédaction d’une solution, il arrive parfois qu’elle devienne de plus en plus complexe et finisse par aboutir à une impasse. Et vous essayez de compliquer les choses de plus en plus afin de résoudre ce problème d'une manière ou d'une autre en utilisant cette approche au lieu d'essayer de chercher une autre alternative plus réalisable. Peut-être que vous vous sentez simplement désolé pour l’énergie et le temps que vous avez dépensés, et alors vous décidez : quoi qu’il arrive, n’abandonnez pas, mais résolvez le problème de cette façon. Ce n’est pas tout à fait la bonne approche. Du moins en programmation. Plus tôt vous essayerez une approche différente, plus vous gagnerez du temps. N'ayez donc pas peur d'expérimenter et d'essayer d'autres approches, malgré le temps que vous avez investi dans celle-ci. De plus, ce seront des points pour votre expérience, puisque vous essayerez plusieurs approches et mieux étudierez ce domaine.

5. Peur de poser des questions sur la tâche en cours

Travailler sur un projet se résume généralement à accomplir certaines tâches (Tâches). Par exemple, dans Jira . Et ces tâches ne sont pas toujours décrites en détail et clairement. Ils sont généralement rédigés par des chefs d’équipe, et ce sont également des personnes, si cela se produit. Ils peuvent également oublier d'ajouter quelque chose ou ne pas tenir compte du fait que vous n'êtes pas très familier avec telle ou telle fonctionnalité. Eh bien, soit vous n'avez aucun accès au projet (par exemple, accès à la base de données, au serveur de journaux, etc.). Et maintenant, après avoir reçu la tâche, après l'avoir étudiée pendant plus de quelques heures, vous êtes toujours assis et regardez l'écran avec perplexité. Et au lieu de continuer à comprendre cela en vain, vous devriez commencer à poser des questions suggestives/clarificatrices au créateur de cette tâche. Disons, dans une application que vous utilisez pour communiquer en équipe (par exemple, Microsoft Teams) ou directement en tant que commentaire sous cette tâche. D'une part, si vous écrivez une question dans un message personnel, la réponse sera probablement plus rapide, puisque la personne verra la question immédiatement. En revanche, en posant une question dans Jira, vous avez la preuve que vous faites quelque chose, à savoir analyser le problème. Il existe un moyen d'accélérer ce processus : posez une question sous forme de commentaire dans Jira et envoyez un lien vers ce commentaire dans un message privé avec une demande de consultation.

6. Attendre trop du chef d’équipe

Encore une fois, c’est le revers du point précédent. Un chef d’équipe est une personne qui dirige une équipe de développement. En règle générale, la plupart du temps d'un tel membre de l'équipe est consacré à divers types de communications. Et en même temps, il écrit aussi du code pour ne pas oublier de quoi il s’agit. Eh bien, comme vous l'avez compris, c'est un personnage très occupé. Et des contractions excessives à chaque éternuement ne le rendront évidemment pas heureux. Imaginez si chaque membre de l'équipe le bombardait de questions. Alors tu peux devenir fou, non ? Et il ne sera pas surprenant qu'avec de nombreuses questions de votre part, il vous réponde longtemps. Que pouvez-vous faire pour réduire le nombre de questions posées au chef d'équipe :

• Étudiez plus en profondeur la documentation de ce projet pour réduire le nombre d'angles morts.
• Posez des questions aux autres membres de l’équipe. Il est fort possible qu'ils soient aussi familiers avec cette fonctionnalité que le responsable, voire plus, car très probablement l'un d'entre eux a écrit cette fonctionnalité.

Alternativement, dans l'EDI, vous pouvez consulter les annotations : qui et quand a modifié le code pour la dernière fois dans une certaine ligne. De cette façon, nous découvrirons qui aurait le plus raison de poser cette question. Comme vous l'avez probablement déjà compris, lorsque vous posez des questions au chef d'équipe, ainsi que lorsque vous posez des questions à des collègues, vous devez essayer de garder le juste milieu - ne pas avoir peur de poser des questions, mais aussi ne pas les harceler avec un nombre excessif.

7. Peur des révisions de code

La révision de code ou révision de code est une étape avant de télécharger du code vers une application commune (vers une branche commune, par exemple, master ou dev). Cette vérification est effectuée par un développeur qui n'est pas lié à cette tâche, qui peut, avec un regard neuf, découvrir des erreurs, des inexactitudes ou des lacunes dans le style de code qui sont passées inaperçues dans la phase initiale de développement. S'il y a des commentaires, ils sont laissés comme commentaires sur certaines sections du code. Dans ce cas, le développeur qui a effectué cette tâche doit corriger les erreurs en fonction de la révision (ou discuter de ses décisions avec le réviseur, peut-être en le convainquant de la justesse de sa décision). Ensuite, renvoyez-le pour révision, et ainsi de suite jusqu'à ce que le réviseur n'ait plus de commentaires. Le réviseur sert de « filtre » avant de télécharger le code. Ainsi, de nombreux programmeurs débutants perçoivent la révision du code comme une critique et une condamnation. Ils ne l'apprécient pas et ont peur d'elle, et c'est faux. C'est la revue de code qui nous permet d'améliorer notre code. Après tout, nous recevons des informations importantes sur ce que nous faisons de mal et sur ce à quoi nous devons prêter attention. Il est nécessaire de considérer chaque révision de code comme une partie de l’apprentissage, quelque chose qui peut vous aider à vous améliorer. Lorsqu'une personne laisse des commentaires sur votre code, elle partage avec vous son expérience, ses bonnes pratiques. Quant à moi, vous ne pouvez pas devenir un bon programmeur sans passer par une révision de code. Parce que vous ne savez pas à quel point votre code est bon et s'il contient des erreurs du point de vue d'une personne expérimentée de l'extérieur.

8. Tendance aux solutions abstruses

Souvent, différentes tâches/problèmes peuvent avoir plusieurs solutions différentes. Et parmi toutes les solutions disponibles, les débutants utilisent généralement les plus complexes et les plus « abstruses ». Et c'est vrai : si hier encore un programmeur novice étudiait de nombreux algorithmes, modèles et structures de données différents, alors ses mains ont hâte d'en implémenter un. Oui, et je veux, pour ainsi dire, me déclarer. Croyez-moi, j'étais moi-même comme ça et je sais de quoi je parle :) J'ai eu une situation où j'ai passé beaucoup de temps à écrire une fonctionnalité qui s'est avérée très, très complexe. Ensuite, il a été réécrit par un développeur de niveau Senior+. Bien sûr, j’étais intéressé de voir quoi et comment il l’avait changé. J'ai regardé sa mise en œuvre et j'ai été étonné de voir à quel point c'était devenu plus simple. Et le code est devenu trois fois moins grand. Et en même temps, les tests pour cette fonctionnalité n'ont pas changé et n'ont pas échoué ! Autrement dit, la logique générale reste la même. De là, j'en suis arrivé à la conclusion suivante : les solutions les plus ingénieuses sont toujours simples . Après cette prise de conscience, l’écriture de code est devenue beaucoup plus facile et son niveau est devenu sensiblement plus élevé. Alors, quand vaut-il la peine d’utiliser des modèles et des algorithmes, demandez-vous ? Ensuite, leur utilisation sera la manière la plus simple et la plus compacte.

9. L'invention du vélo

Ce concept est également connu sous le nom d’invention de la roue. Son essence réside dans le fait que le développeur implémente sa propre solution à un problème pour lequel des solutions existent déjà, et bien meilleures que celles inventées par le programmeur. En règle générale, inventer votre propre vélo entraînera une perte de temps et une diminution de l’efficacité du travail du développeur, car il se peut qu’une solution qui soit loin d’être la meilleure ne soit pas trouvée, voire qu’elle ne soit pas trouvée du tout. Dans le même temps, nous ne pouvons pas écarter la possibilité d’une décision indépendante. Le programmeur doit naviguer correctement dans les tâches qui peuvent se présenter à lui afin de les résoudre avec compétence et en temps opportun, en utilisant des solutions toutes faites ou en inventant les siennes. D'une part, dans les universités et dans les cours, nous sommes bombardés de tâches de toutes sortes qui devraient nous aider à mettre la main sur la création de vélos. Mais ce n’est qu’un premier coup d’œil. En fait, le but est de développer une pensée algorithmique et une maîtrise plus approfondie de la syntaxe du langage. Et ces tâches aident également à mieux comprendre les algorithmes/structures et, si nécessaire, leur donnent les compétences nécessaires pour mettre en œuvre leurs analogues avancés (mais cela est très rarement nécessaire). Dans la vraie vie, dans la grande majorité des cas, il n'est pas nécessaire d'inventer sa propre roue, puisqu'il existe depuis longtemps des analogues qui satisfont nos besoins. Peut-être qu'en raison de votre expérience, vous ne connaîtrez pas l'existence des implémentations de telle ou telle fonctionnalité dont vous avez besoin. C’est là qu’il faut utiliser le premier point de cet article, à savoir demander l’aide de collègues plus expérimentés. Ils sauront vous guider (par exemple, conseiller dans quelle direction Google) ou vous suggérer une implémentation spécifique (certaine bibliothèque).

10. N'écrivez pas de tests

Tous les débutants n’aiment pas écrire des tests. Qu’en est-il des débutants : les non-débutants n’aiment pas non plus écrire des tests, mais ils comprennent mieux pourquoi c’est nécessaire. Quand on est complètement vert, on se demande : pourquoi les écrire ? Tout fonctionne et il ne peut y avoir aucune erreur. Mais comment pouvez-vous être sûr que vos modifications ne perturbent pas quelque chose dans une autre partie du système ? Vos collègues n’apprécieront pas que vous imposiez des changements qui perturbent plus qu’ils ne profitent. C'est là que les tests viennent à la rescousse. Plus une application est couverte par les tests, mieux c'est (également appelé pourcentage de couverture). Si l'application est bien couverte par les tests, en les exécutant tous, vous pourrez trouver des endroits qui peuvent être cassés par vos modifications. Et comme je l'ai dit dans l'exemple ci-dessus, lors de la refactorisation de la fonctionnalité, les tests n'ont pas échoué, et tout cela parce que la logique générale n'a pas changé. Cela signifie que les tests peuvent également montrer si la logique d'une certaine fonctionnalité a changé ou non. Ainsi, même si vous n'aimez pas rédiger des tests, ils présentent des avantages incontestables et valent le temps qu'on y consacre.

11. Commentaires excessifs

De nombreux développeurs souffrent de perfectionnisme et les débutants ne font pas exception. Mais parfois, un effet secondaire de ce désir est qu’ils commencent à commenter tout et tout le monde. Même ce qui n'est pas nécessaire, car c'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 une bonne chose, car le code s'avérera beaucoup plus encombré et difficile à lire. Que se passe-t-il si le code a été modifié, mais qu'il n'y a eu aucun commentaire à ce sujet ? Il s'avère qu'il nous trompera et ne fera que nous confondre. Pourquoi alors un tel commentaire ? Habituellement, un code bien écrit n'a pas besoin de commentaires , car tout ce qu'il contient est déjà évident et lisible. Si vous écrivez un commentaire, cela signifie que vous avez déjà gâché la lisibilité du code et que vous essayez d'aplanir la situation d'une manière ou d'une autre. La meilleure approche serait d'écrire initialement du code lisible qui ne doit pas être complété par des commentaires. Je n'ai pas non plus pu m'empêcher de mentionner la dénomination correcte des méthodes, des variables et des classes, à savoir une règle à laquelle j'adhère moi-même : le meilleur commentaire est l'absence de commentaire, et à la place - la dénomination correcte qui décrit clairement ceci ou cela. fonctionnalité dans votre application.

12. Mauvaise dénomination

Souvent, les débutants falsifient les noms des classes, des variables, des méthodes, etc. Par exemple, lorsqu'ils créent une classe dont le nom ne décrit pas du tout son objectif. Ou bien, une variable est créée avec un nom court, quelque chose comme x , et lorsque deux autres variables nommées n et y sont créées , il devient très difficile de se souvenir de ce que fait x . Dans de tels cas, il faut bien réfléchir au code et étudier cette fonctionnalité au microscope (éventuellement à l'aide d'un débogueur) afin de simplement comprendre ce qui s'y passe. C'est là que la dénomination correcte dans le code que j'ai mentionné ci-dessus nous vient en aide. Les noms corrects améliorent la lisibilité du code, permettant ainsi de gagner du temps lors de la familiarisation, car il est beaucoup plus facile d'utiliser une méthode dans laquelle le nom décrit approximativement sa fonctionnalité. Dans le code, tout est constitué de noms (variables, méthodes, classes, objets fichiers, etc.), ce point devient très important lors de la création d'un code correct et propre. Il convient de rappeler que le nom doit véhiculer une signification : pourquoi, par exemple, la variable existe, ce qu'elle fait et comment elle est utilisée. Et je noterai encore et encore que le meilleur commentaire pour décrire une variable est son nom correct. Pour une étude plus approfondie des commentaires et une dénomination correcte, je vous conseille de lire le classique intemporel : « Clean code. Création, analyse et refactoring », Robert Martin . Sur cette note, la première partie de cet article (réflexions) prend fin. À suivre…