Analyse des erreurs courantes commises par les programmeurs débutants, pt. 2

Re-bonjour à tous ! Nous continuerons à considérer les problèmes auxquels un programmeur jeune et immature peut être confronté dans son premier emploi. La première partie peut être trouvée ici . Nous allons continuer.

13. Non-respect des directives de style de codage.

Les équipes de développement s’en tiennent généralement à un seul style de codage. Autrement dit, les développeurs individuels suivent certaines règles écrites ou non écrites pour garantir que leur style de codage ne diffère pas des autres. N'essayez pas de vous démarquer avec un style de codage distinctif : cela ne vous donne pas une belle apparence. Si vous êtes nouveau dans le projet, vous devez immédiatement vérifier s'il existe une documentation définissant les directives générales de style de codage. Il se peut que vous deviez demander et importer dans votre IDE certains fichiers de style pour votre projet spécifique (par exemple, IntelliJ IDEA), afin que l'EDI puisse fournir les bonnes astuces de style de codage. Par exemple, le style peut nécessiter l'utilisation du modificateur final dans la mesure du possible. Le fichier de style permet à IntelliJ IDEA de surligner en jaune toutes les variables où cela n'est pas respecté.

14. Être découragé par les erreurs

Les erreurs sont quelque chose auquel il faut s’habituer. Ils l’ont été, le sont et le seront. Peu importe que vous soyez un débutant ou un architecte sérieux, vous ferez toujours des erreurs. Le nombre et la gravité de vos erreurs peuvent changer, mais elles vous accompagneront tout au long de votre carrière. Parfois, vous avez du mal à faire fonctionner quelque chose toute la semaine, vous faites une erreur, puis c'est vendredi soir et vous rentrez chez vous comme un chien battu, sans pouvoir réparer cette foutue erreur. C'est un sentiment indescriptible, mais qui ne devrait pas vous décourager. Après tout, une autre différence importante entre un développeur expérimenté et un novice réside dans la manière dont il gère les erreurs. Les développeurs expérimentés ne les prennent pas à cœur, mais les considèrent plutôt comme une expérience. Personne ne vous grondera pour avoir commis une erreur. C’est normal – tout le monde se retrouve parfois dans le pétrin. Encore une fois, vous pouvez demander de l’aide à vos collègues. Et n'oubliez pas les personnes comme les chefs de projet (PM). Si vous êtes bloqué sur quelque chose, vous devez immédiatement contacter le PM. Il ou elle peut vous aider à trouver quelqu'un qui est un expert dans le domaine problématique. Dans tous les cas, le PM doit être tenu informé de tout problème que vous rencontrez sur le projet. C'est le travail du PM d'aider à résoudre toutes sortes de problèmes, y compris la communication et les interactions entre les membres de l'équipe. Pour résumer : des erreurs arrivent , ne les laissez pas vous tuer. Acceptez-les plutôt comme un défi pour vous et vos compétences. En fin de compte, ce n'est qu'une partie du travail.

15. Échec de la mise en œuvre de la sécurité des threads.

Rien de bon ne se crée facilement. Chaque développeur doit comprendre que l'écriture de fonctionnalités spécifiques, qu'il s'agisse d'un module ou simplement d'une méthode, nécessite un plan concernant ce qui sera fait et comment. En règle générale, lors du développement de fonctionnalités de toute complexité, vous devez respecter la procédure suivante : De nombreuses erreurs qui surviennent dans le code écrit par des programmeurs débutants sont liées aux étapes de cette procédure. Bien sûr, vous ne pouvez pas exclure qu'il y ait des moments où vous devez écrire rapidement du code sans hésitation dès que vous voyez la tâche. Mais cela ne fonctionne généralement que pour certaines tâches et méthodes mineures dont la mise en œuvre est évidente et ne nécessite pas beaucoup de réflexion. La procédure de développement mentionnée ci-dessus est plus adaptée aux tâches complexes et volumineuses qui peuvent être divisées en sous-tâches. Ce n'est pas une bonne idée de commencer à écrire du code sans bien comprendre ce que vous voulez écrire. Tout d’abord, vous devez soigneusement réfléchir et tout planifier. Il peut également être utile de prendre une feuille de papier et un crayon et d’essayer d’esquisser vos idées de mise en œuvre. Je fais toujours cela lors de la planification de fonctionnalités complexes. Un programmeur passe la plupart de son temps non pas à écrire du code, mais plutôt à réfléchir à la manière de structurer les fonctionnalités requises . En effet, une fois que vous avez tout planifié et pensé, écrire du code devient un processus purement mécanique et sans tracas.

16. Surmenage

du film "Fight club" (1999) Peut-être que chaque débutant pense qu’en travaillant tard dans la nuit, il commencera à accomplir davantage de tâches et se verra confier davantage de responsabilités. Je le pensais aussi, mais plus maintenant. J’ai remarqué qu’il arrive un moment où l’on atteint sa limite, où l’on cesse d’être capable de penser adéquatement. Vous commencez à devenir assez ennuyeux et à ressentir un brouillard mental. Il faut une heure pour faire des choses que vous pourriez faire en 10 minutes si votre esprit était frais. Presque sans exception, après avoir franchi cette ligne de fatigue, vous rencontrez un problème qui semble insurmontable. Mais lorsque vous arrivez au travail le lendemain matin, vous résolvez le problème en un clin d'œil. Alors, lorsque vous sentez que vous avez atteint ce point, ne veillez pas tard. Rentrez chez vous et reposez-vous bien. Après tout, si vous restez à votre bureau jusque tard dans la nuit, non seulement vous n'obtiendrez pas de résultats particulièrement remarquables pendant ces heures de tourment, mais en même temps vous risquez un repos médiocre (insuffisant) avant le prochain jour de travail, lorsque vous ' Je vais encore foirer. Pensez à votre santé : est-ce que cela vaut la peine de la mettre ainsi à mal en début de carrière ? Je crois que non. Être malade coûte cher. Et pensez à votre employeur. En vous surmenant, vous aggravez la situation non seulement pour vous-même, mais aussi pour votre employeur. Qui a besoin d’un collaborateur perpétuellement somnolent, qui, épuisé, ne parvient pas à mettre en œuvre l’algorithme de tri le plus simple ? Oui, il y a sans aucun doute des moments où vous avez une échéance serrée, des moments où tout s'est mal passé et des moments où – et c'est mon préféré – « nous en avons besoin hier ». Mais ces situations sont généralement rares, et une fois que vous les avez surmontées, vous devez vous asseoir et réfléchir attentivement à la manière dont elles auraient pu se produire et comment les éviter à l’avenir.

17. Négliger les compétences en anglais

De nombreux développeurs en herbe donnent la priorité à l’apprentissage de la technologie et reportent à plus tard l’apprentissage de l’anglais. Il s'agit d'une grave erreur, car bien souvent, un programmeur est parfaitement adapté à un poste junior (ou à un stage), mais n'obtient pas le poste en raison de ses faibles compétences en anglais. Oui, bien sûr, il y a des cas où l'on peut se passer de l'anglais. En règle générale, ces personnes sont embauchées localement pour des projets dans des pays non anglophones. Mais les entreprises locales ne paient pas les mêmes salaires que les entreprises étrangères. Et il sera très, très difficile d’obtenir un salaire décent, même sur la durée. C'est pourquoi il ne faut pas ignorer l'anglais. Plutôt que de mettre l’anglais en veilleuse, il faut l’apprendre pour se concentrer immédiatement sur des projets anglophones. En effet, réfléchissez-y une minute : l’anglais est actuellement la langue du commerce international. Quel que soit le pays dans lequel vous allez, vous pouvez trouver une langue commune avec d’autres si vous connaissez l’anglais. Il en va de même dans les projets de développement. Peu importe où le projet est basé : Allemagne, Australie, France ou ailleurs — toute la communication, toutes les tâches, la documentation, etc. seront en anglais. Et si vous y réfléchissez une seconde, vous conviendrez que c'est très pratique, n'est-ce pas ?

18. Poursuite de la technologie à la mode

Lorsque les développeurs commencent leur chemin, ils essaient souvent de se tenir au courant des dernières technologies. est-ce la bonne chose à faire? D'un côté, oui : les dernières technologies, les projets... Mais est-ce que cela vaut la peine d'en faire une priorité absolue ? Peut-être vaut-il mieux privilégier la « boîte à outils classique » pour un spécialiste de votre domaine ? La nouveauté est certes une bonne chose, mais il ne faut pas oublier les technologies fondamentales de votre domaine. Et seulement alors, après avoir acquis un peu d’expérience et une connaissance approfondie des bases, vous pourrez essayer quelque chose de nouveau. Considérez également que les nouvelles technologies peuvent être supérieures dans certains domaines subtils, mais elles peuvent perdre des avantages dans d’autres. Jusqu'à ce qu'un développeur novice comprenne ces compromis, il est préférable de s'en tenir aux solutions éprouvées. Par exemple, si un programmeur développe une application qui interagit avec certaines données, ne vous précipitez pas pour utiliser la dernière solution NoSQL simplement parce qu'elle est à la mode. Une base de données SQL ordinaire éprouvée (MySQL, PostrgreSQL, etc.) dispose très probablement d'une documentation détaillée et de solutions sur StackOverFlow pour tout problème potentiel :)

19. Apprendre plusieurs technologies et/ou langues différentes à la fois

Nous avons parlé plus haut de débutants essayant d'apprendre les technologies à la mode. Eh bien, qu’en est-il de l’étude simultanée de plusieurs technologies ou langues ? Évidemment, vous avez entendu parler de programmeurs qui connaissent plus d’un langage de programmation et maîtrisent de nombreuses technologies. Mais je soulignerai rapidement que ces personnes sont loin d'être novices en matière de programmation. Ce sont des gens qui ont derrière eux de nombreuses années d’expérience. Ils ont maîtrisé leur technologie d'origine et sont ensuite allés de plus en plus loin. Les débutants qui tentent de tout maîtriser d'un coup doivent se rappeler de l'excellent proverbe : « poursuivez deux lièvres et vous n'attraperez ni l'un ni l'autre ». La conséquence peut être que vous ne maîtriserez bien aucun sujet, mais que vous n’apprendrez les sujets que superficiellement. Il y aura plus de demande pour un spécialiste connaissant profondément une seule langue que pour celui qui connaît un peu tout. Donc, si vous souhaitez connaître de nombreux langages et technologies, vous devez les aborder avec sagesse. Pour commencer, vous devez choisir une langue de base que vous devez apprendre en profondeur. Et alors seulement devriez-vous commencer à étudier d’autres domaines. Par exemple, devenez un gourou de Java, puis apprenez Python comme deuxième langage. Après cela, vous pourriez apprendre quelque chose sur React/Angular pour le frontend. Dans ce cas, nous parlons de technologies qui ne sont pas interchangeables, comme C# et Java, mais plutôt complémentaires, élargissant ainsi vos opportunités de carrière. Mais encore une fois, je le répète : il ne faut pas essayer de tout apprendre d'un coup. Vous devez y aller de manière séquentielle. Attrapez un lièvre à la fois, pour ainsi dire.

20. Objectifs mal formulés

Comment vous fixez-vous des objectifs ? Devenir un développeur sympa ? Rappelez-vous ceci une fois pour toutes : vous devez vous fixer des objectifs concrets, ou en d’autres termes, des objectifs réalisables. De quoi je parle ? Par exemple, vous vous fixez l’objectif : « Je veux devenir riche ». Mais comment savoir si vous avez atteint cet objectif ? Ou comment mesurez-vous à quel point vous êtes sur le point d’y parvenir ? Eh bien, si vous fixez l'objectif « Je veux gagner un million de dollars », c'est un peu plus clair, n'est-ce pas ? Une fois que vous avez gagné 10 000 $, vous êtes 10 000 $ plus près de votre objectif : il ne vous reste plus que 990 000 $ à parcourir. Il reste encore beaucoup à accomplir, mais vous pouvez sentir vos progrès et comprendre où se trouve la ligne d'arrivée, vous serez donc motivé pour continuer. En termes de carrière, que diriez-vous de vous fixer un objectif plus concret ? Par exemple : je souhaite devenir chef d’équipe. Ou un développeur senior. Ou finalement un architecte. Eh bien, chaque grande tâche doit être divisée en petites sous-tâches. On ne devient pas chef d'équipe au début de sa carrière. Fixez des délais si possible et approprié, et concentrez-vous sur l’étape actuelle.

1. Si nous parlons de devenir développeur senior , alors le premier petit objectif serait de trouver un stage ou un emploi en tant que développeur junior dans une entreprise.
2. Ensuite, vous pouvez vous fixer des objectifs pour approfondir vos connaissances sur certaines technologies. En ce qui concerne Java, vous pouvez vous préparer à la certification Oracle niveau 1. Nous établissons un calendrier pour notre préparation et abordons l’objectif.
3. Ensuite, par exemple, vous pourriez vous fixer comme objectif d'améliorer votre anglais d'un niveau (disons, de B1 à B2). Nous élaborons un plan d'apprentissage, planifions le temps et avançons vers l'objectif.

C'est ainsi que nous pouvons atteindre notre objectif ultime étape par étape (tout en acquérant de l'expérience en développement logiciel).

21. Théorie sans pratique

C'est un fait incontestable que nous devenons de meilleurs professionnels en étudiant les nouvelles technologies et en approfondissant des sujets que nous connaissons déjà. Mais au début du voyage, les développeurs se rendent rarement compte que dévorer des livres techniques les uns après les autres n’apporte pas d’énormes avantages si les nouvelles connaissances ne sont pas mises en pratique. J'ai personnellement rencontré cela plus d'une fois. Si vous consacrez beaucoup de temps à un livre mais que vous ne le mettez pas en pratique, alors presque toutes les connaissances nouvellement acquises sont oubliées : il ne vous reste qu'un vague souvenir général de la façon dont tout fonctionne. Le résultat est une perte de temps considérable sans résultat tangible. Pourquoi devrions-nous perdre notre temps ? La vie ne dure pas éternellement. Ce qu'il faut retenir, c'est que lorsque vous apprenez une nouvelle technologie, vous ne devez pas vous attarder sur la théorie : écrivez les exemples donnés en parallèle de votre lecture, expérimentez la nouvelle technologie. C’est le seul moyen d’amener votre cerveau à retenir les informations. Oui, vous consommerez les nouveaux documents plus lentement, mais vous assimilerez beaucoup plus de ce que vous lisez. De plus, si vous maîtrisez bien une technologie, la suivante sera encore plus facile à maîtriser (tout comme pour l'apprentissage des langues).

22. Perfectionnisme excessif

La plupart des développeurs sont des perfectionnistes : des gens qui recherchent la perfection. Cela signifie que leur code doit également être parfait. Votre code a donc été écrit, testé, peaufiné, et il semble qu'il soit temps de le soumettre à la branche principale. Mais vous n'êtes toujours pas satisfait du code, alors vous commencez à le tordre d'une manière ou d'une autre, en consacrant beaucoup de temps à cet effort. Et dans ce cas, le temps, c'est l'argent de votre client. Les programmeurs débutants sont plus sensibles à cette quête de perfection. Les développeurs expérimentés sont habitués au sentiment que le code ne sera jamais parfait et qu’ils devraient essayer de mieux l’écrire. Mais en même temps, ils ne vont pas aux extrêmes pour se rapprocher de « l’idéal ». Alors, n’oubliez pas d’apprendre à trouver un juste milieu : ne pas négliger et ne pas essayer de recréer la Joconde en code.

23. Ne pas penser à l'architecture

Permettez-moi de le répéter : vous ne devriez pas écrire de code compliqué. Outre la lisibilité et les performances, vous devez également réfléchir à la manière dont votre code pourrait affecter le reste de votre application dans son ensemble. Par exemple, dans quelle mesure sera-t-il difficile d’étendre votre code, etc. Le problème est que les développeurs novices, en raison de leur manque d'expérience, peuvent ne pas comprendre immédiatement comment leurs nouvelles fonctionnalités affecteront l'application à l'avenir. Cette prévoyance demande certainement beaucoup de pratique pour se développer. Mais que doivent donc faire les novices ? Vous n'écrivez pas de code ? Dans ces situations, divers paradigmes de programmation nous viennent en aide. Par exemple, les principes SOLID ou divers modèles de conception qui peuvent vous transmettre des pratiques utiles. Ces paradigmes doivent également être traités avec prudence et ne pas être poussés trop loin. Mais comment déterminer le moment où vous en faites trop ? C’est là qu’une révision du code par un collègue plus expérimenté vous aidera. En apportant un regard neuf et objectif, votre collègue peut vous orienter dans la bonne direction.

24. Syndrome de l'imposteur

Le syndrome de l’imposteur est un phénomène psychologique dans lequel une personne est incapable d’attribuer ses réalisations à ses qualités, capacités et efforts personnels. Malgré les preuves externes de leurs performances constantes, les personnes sensibles à ce syndrome continuent de croire qu'elles sont des fraudeurs et qu'elles ne méritent pas le succès qu'elles ont obtenu. De nombreux développeurs souffrent de ce syndrome. Peut-être que cela nous donne la persévérance qui nous pousse vers de nouvelles connaissances et technologies. Vous regardez des collègues plus expérimentés et plus accomplis et vous vous sentez mal à l'aise, comme si vous ne valiez pas votre salaire. Croyez-moi, ce n'est pas vrai. Il y a et il y aura toujours des développeurs meilleurs ou pires que vous. Quelqu’un d’autre vous regarde et se sent mal à l’aise, pensant qu’il ne deviendra jamais comme vous. Et c'est normal. Les commentaires de votre équipe, les révisions de code et les discussions aident à combattre un peu ce sentiment. Croyez-moi, l'opinion d'un étranger vous surprendra agréablement, mais seulement si vous ne négligez pas réellement votre travail et votre développement professionnel. Si vous négligez ces choses, vous avez choisi le mauvais métier. Dans ce métier, vous devez toujours apprendre quelque chose de nouveau et viser le meilleur. Mais je pense que les gens rassemblés ici sont loin d’être paresseux. Au lieu de cela, les gens ici avancent résolument vers leur objectif le plus cher. Si cela vous décrit, alors vous n’avez rien à craindre.

25. Faire rarement des commits

N'oubliez pas d'effectuer des commits souvent ! Pas toutes les demi-heures, remarquez. Si vous passez une semaine à implémenter certaines fonctionnalités, vous ne devriez pas effectuer un seul commit le vendredi soir, mais, disons, cinq commits. Presque toutes les tâches importantes peuvent être divisées en tâches plus petites pour plus de commodité. Vous accomplissez donc ces petites tâches et vous vous engagez. Et n'oubliez pas d'envoyer immédiatement ces commits au serveur distant. Sinon, vous risquez de faire des commits toute la semaine, puis votre ordinateur aura une panne matérielle le vendredi à midi, et vous aurez alors perdu une semaine entière pour rien ! Mais si vous avez téléchargé vos commits sur un serveur distant, vous devez simplement extraire la branche avec votre dernier commit sur un autre ordinateur et continuer à travailler. Encore une chose : ne soumettez pas de nouvelles fonctionnalités à un serveur de production en direct le vendredi soir. Faites-moi confiance. Vous n'en avez pas besoin. Il est fort probable que des erreurs inattendues apparaissent et vous passerez votre week-end à les corriger. Et ce n'est pas amusant. Vous devez vous reposer le week-end. Je suppose que c'est tout pour aujourd'hui. PS Un dernier conseil : écrivez beaucoup de code. PPS Écrivez une quantité INSANEMENT grande de code, car c'est le seul moyen d'acquérir l'expérience indispensable.