Un développeur web junior peut coder très vite, mais il fera souvent beaucoup plus d’erreurs qu’un senior. Quelques erreurs de logique peut être, mais surtout des erreurs méthodologiques, qui peuvent faire perdre beaucoup de temps et rendre beaucoup plus difficile la maintenance de l’applicatif. Les erreurs d’un développer web junior sont souvent les mêmes : manque de planification, refus de l’abandon, etc. Trouver un développeur peut ainsi être fastidieux.
Nous nous sommes appuyés sur un article publié par Samer Buna sur Medium pour vous proposer un tour des 20 erreurs classiques d’un développer web junior. Un must read pour tout développeur web junior, mais également pour les personnes qui travaillent avec eux.
1) Ecrire le code sans planifier quoi que ce soit
En général, un contenu rédactionnel de haute qualité ne peut pas être créé facilement. Cela nécessite une réflexion et des recherches approfondies. La création de programmes informatiques ne font pas exception. L’écriture de programmes de qualité est un processus où il faut suivre des étapes : penser, rechercher, planifier, écrire, valider, modifier. Malheureusement, il n’y a pas de bon acronyme pour cela. L’une des erreurs les plus courantes en tant que programmeur débutant est de commencer à écrire du code sans beaucoup de réflexion ni de recherche. Bien que cela puisse fonctionner pour une petite application autonome, cela a un effet négatif sur les applications plus volumineuses. Tout comme vous devez réfléchir avant de dire quelque chose que vous pourriez regretter, vous devez réfléchir avant de coder. Le codage est aussi un moyen de communiquer vos pensées. La programmation consiste principalement à lire le code précédent, à rechercher ce qui est nécessaire et comment l’intégrer au système actuel, et à planifier l’écriture de fonctions avec de petits ajouts. L’écriture réelle des lignes de code ne représente que 10% de l’ensemble du processus. La programmation est une créativité basée sur la logique pas seulement sur les lignes de code.
2) Trop planifier avant d’écrire le code
Oui, planifier avant de plonger dans l’écriture du code est une bonne chose, mais même de bonnes choses peuvent vous desservir lorsque vous en faites trop. Ne cherchez pas un plan parfait, cela n’existe pas dans le monde de la programmation. Votre plan changera de toute façon en court de route, mais ce à quoi il sert est de vous forcer à rester structuré. Cela conduit à plus de clarté dans votre code. Trop de planification est une perte de temps. Nous parlons seulement de la planification de petites fonctionnalités. C’est ce que nous appelons l’approche en cascade, qui est un plan linéaire avec des étapes distinctes qui doivent être terminées une par une.
L’écriture de programmes doit être une activité réactive. Vous ajouterez des fonctionnalités auxquelles vous n’auriez jamais pensé dans un plan en cascade. Vous devez corriger les bugs et vous adapter aux changements. Cependant, vous devez planifier un minimum vos prochaines fonctionnalités. Faites-le très attentivement car trop peu de planification et trop de planification peuvent nuire à la qualité de votre code. Il faut choisir le bon dosage.
3) Sous-estimer l’importance de la qualité du code
Si vous ne pouvez vous concentrer que sur un seul aspect du code, ce devrait être sa lisibilité. Un code pas clair ira directement à la poubelle. Ne sous-estimez jamais l’importance de la qualité du code. Votre travail principal en tant que codeur est de communiquer clairement les implémentations de toutes les solutions sur lesquelles vous travaillez. Même les petites choses comptent. Par exemple, si vous n’êtes pas cohérent avec votre indentation, vous devriez simplement arrêter le code.
Une autre chose simple est l’utilisation de longues lignes. Tout ce qui dépasse 80 caractères est beaucoup plus difficile à lire. Vous pourriez être tenté de placer une longue condition sur la même ligne pour garder un bloc plus visible, c’est une erreur. Ne jamais aller au-delà de la limite de 80 caractères. Beaucoup de problèmes simples comme celui-ci peuvent être facilement résolus avec des outils de mise en forme. En JavaScript, nous avons deux excellents outils qui fonctionnent parfaitement ensemble : ESLint et Prettier. Voici quelques autres erreurs liées à la qualité du code :
- Utiliser plusieurs lignes dans une fonction ou un fichier. Vous devez toujours fractionner le code long en plus petits morceaux qui peuvent être testés et gérés séparément.
- Utilisation de noms de variables courts et génériques. Donnez à vos variables des noms descriptifs et non ambigus.
- Utiliser des raccourcis et des solutions de contournement pour éviter de passer plus de temps autour de problèmes simples.
- Penser que plus il y a de code mieux c’est. Un code plus court est meilleur dans la plupart des cas. Ecrivez des versions plus longues que si elles rendent le code plus lisible. Par exemple, n’utilisez pas de guillemets intelligents et d’expressions juste pour garder le code plus court. Supprimer du code inutile est la meilleure chose que vous pouvez faire dans n’importe quel programme.
4) Choisir la première solution
Alors que la première solution que vous trouvez peut être tentante, les meilleures solutions sont généralement découvertes dès que vous commencez à vous pencher sur toutes les solutions possibles. Si vous ne pouvez pas trouver plusieurs solutions à un problème, c’est probablement un signe que vous ne comprenez pas complètement le problème. Votre travail en tant que programmeur n’est pas de trouver une solution au problème, mais de trouver la solution LA plus simple au problème. Par « simple », nous voulons dire que la solution doit fonctionner correctement et fonctionner de manière adéquate, tout en restant suffisamment simple à lire, à comprendre et à maintenir.
5) Le « non-abandon »
Une autre erreur courante est de s’en tenir à la première solution même après avoir identifié que ce n’est peut-être pas l’approche la plus simple. Ceci est probablement lié psychologiquement à la mentalité du «non-abandon». C’est une bonne mentalité à avoir dans la plupart des activités, mais cela ne devrait pas s’appliquer à la programmation. En fait, quand il s’agit de programmation, la « bonne » mentalité échoue souvent. Dès que vous commencez à douter d’une solution, vous devriez envisager de repenser le problème, peu importe combien vous avez investi dans cette solution. Les outils de contrôle de source comme GIT peuvent vous aider à expérimenter de nombreuses solutions différentes.
6) Ne pas utiliser Google
Il y a surement des moments où vous avez perdu du temps alors que vous auriez pu chercher la solution sur Google. À moins d’utiliser une technologie de pointe, lorsque vous rencontrez un problème, il y a de fortes chances que quelqu’un d’autre rencontre le même problème et trouve une solution. Économisez-vous un peu de temps et utilisez Google. Parfois, Google révèle que ce que vous pensiez être un problème ne l’est pas vraiment, et ce que vous devez faire n’est pas de le réparer, mais plutôt de l’adapter. Ne présumez pas que vous savez tout pour choisir une solution à un problème. Google va vous surprendre. Cependant, faites attention à ce que vous recherchez sur Google. Un autre signe d’un débutant est de copier et d’utiliser du code tel quel sans le comprendre. Bien que ce code puisse résoudre correctement votre problème, vous ne devez jamais utiliser une ligne de code que vous ne comprenez pas complètement.
7) Planifier pour le futur
Il est souvent tentant de penser au-delà de la solution que vous écrivez. Toutes sortes de scénarios vont apparaître dans votre tête avec chaque ligne de code que vous écrivez. Mais ce serait une erreur d’utiliser cela dans chaque cas. N’écrivez pas de code dont vous n’avez pas besoin aujourd’hui. Ecrire une fonctionnalité parce que vous pensez que vous pourriez en avoir besoin dans le futur est tout simplement inutile. Toujours écrire la quantité minimale de code dont vous avez besoin aujourd’hui pour la solution que vous implémentez.
8) Ne pas utiliser les bonnes structures de données
Lors de la préparation des interviews, les programmeurs débutants mettent généralement trop l’accent sur les algorithmes. Il est bon d’identifier de bons algorithmes et de les utiliser en cas de besoin, mais les mémoriser ne contribuera pas à votre génie. Cependant, mémoriser les forces et les faiblesses des différentes structures de données que vous pouvez utiliser dans votre language fera certainement de vous un meilleur développeur. Cet article n’est pas destiné à vous apprendre les structures de données mais voici tout de même quelques exemples :
Utilisation de listes (tableaux) à la place de cartes (objets) pour gérer les enregistrements
L’erreur de structure de données la plus fréquente est probablement l’utilisation de listes au lieu de cartes pour gérer une liste d’enregistrements. Nous parlons ici d’une liste d’enregistrements où chaque enregistrement a un identifiant qui doit être utilisé pour rechercher cet enregistrement. En JavaScript, la structure de liste la plus courante est un tableau et la structure de carte la plus courante est un objet (il y a aussi une structure de carte en JavaScript moderne). L’utilisation de listes sur des cartes pour gérer des enregistrements est souvent erronée. La principale raison pour laquelle cela est important est que lorsque vous recherchez des enregistrements en utilisant leurs identifiants, les cartes sont beaucoup plus rapides que les listes.
Ne pas utiliser de stacks
Lors de l’écriture d’un code nécessitant une forme de récursion, il est toujours tentant d’utiliser des fonctions récursives simples. Cependant, il est généralement difficile d’optimiser le code récursif, en particulier dans les environnements mono-thread. Par exemple, l’optimisation d’une fonction récursive qui retourne deux ou plusieurs appels sur elle-même est beaucoup plus difficile que l’optimisation d’une fonction récursive qui renvoie simplement un seul appel à lui-même. Ce que nous avons tendance à négliger en tant que débutants, c’est qu’il existe une alternative à l’utilisation de fonctions récursives. Vous pouvez simplement utiliser une structure de stack.
9) Écrire des commentaires sur des choses évidentes
La plupart des commentaires peuvent être remplacés par des éléments mieux nommés dans votre code. Par exemple, au lieu du code suivant :
Le même code peut être écrit sans commentaires comme celui-ci :
Le simple fait d’utiliser de meilleurs noms pour les fonctions et les arguments rend la plupart des commentaires inutiles. Parfois, vous êtes tout de même forcé dans des situations où la seule clarté que vous pouvez ajouter au code sont des commentaires. C’est à ce moment-là que vous devez structurer vos commentaires pour répondre à la question du POURQUOI ce code plutôt que la question de QU’EST-CE QUE fait ce code ? Voici un exemple de commentaires inutiles qui ajoutent seulement des parasites au code :
Ne devenez pas ce programmeur. N’acceptez pas ce code. Supprimez ces commentaires si vous devez les traiter. Si vous employez des programmeurs qui écrivent des commentaires comme ceux-ci, posez-vous les bonnes questions.
10) Ne pas écrire des tests
Si vous pensez que vous êtes un programmeur expert et que votre réflexion vous donne la confiance nécessaire pour écrire du code sans tests, vous êtes un débutant. Si vous n’écrivez pas de tests dans le code, vous testerez probablement votre programme d’une autre manière, manuellement. Si vous créez une application web, vous actualiserez et interagirez avec l’application après chaque ligne de code. Il n’y a rien de mal à tester manuellement votre code. Toutefois, vous devez tester manuellement votre code pour déterminer comment le tester automatiquement. Si vous testez avec succès une interaction avec votre application, vous devriez revenir à votre éditeur et écrire du code pour effectuer automatiquement la même interaction la prochaine fois que vous ajouterez du code au projet. Vous êtes un être humain. Vous allez oublier de tester toutes les validations précédemment réussies après chaque changement de code. Laissez faire cela par un ordinateur. Si vous le pouvez, commencez par deviner ou concevoir vos validations avant même d’écrire le code pour les satisfaire. Le développement piloté par les tests (TDD) n’est pas simplement une « hype ». Cela affecte positivement la façon dont vous pensez vos fonctionnalités et comment créer un meilleur design pour elles. TDD n’est pas fait pour tout le monde et cela ne fonctionne pas bien pour tous les projets, mais si vous pouvez l’utiliser (même partiellement), vous devriez le faire.
11) Ne pas remettre en question le code existant
Sauf si vous êtes un super codeur qui travaille toujours en solo, il ne fait aucun doute que vous rencontrerez des codes sans queue ni tête dans votre vie. Les débutants ne le reconnaîtront pas et ils supposent généralement que c’est un bon code, car il semble fonctionner et il fait partie du code depuis longtemps. Ce qui est pire, c’est que si le mauvais code utilise de mauvaises pratiques, le débutant pourrait être tenté de répéter cette mauvaise pratique ailleurs dans le code. Certains codes semblent mauvais, mais ils peuvent avoir une condition particulière qui oblige le développeur à les écrire de cette façon. En tant que débutant, vous devez simplement supposer que tout code non documenté que vous ne comprenez pas a plus de chance d’être mauvais. Si l’auteur de ce code a disparu depuis longtemps ou ne s’en souvient plus, recherchez ce code et essayez de tout comprendre. C’est seulement quand vous comprendrez complètement le code que vous arriverez à vous faire une opinion de s’il est bon ou non.
12) Observer les meilleures pratiques
Le terme «meilleures pratiques» est réellement préjudiciable. Cela implique qu’aucune autre recherche n’est nécessaire. Il n’y a pas de meilleures pratiques. Il y a probablement de bonnes pratiques à l’instant T et pour ce langage de programmation. Une partie de ce que nous avons précédemment identifié comme étant les meilleures pratiques en matière de programmation sont qualifiées aujourd’hui de mauvaises pratiques. Vous pouvez toujours trouver de meilleures pratiques si vous investissez suffisamment de temps. Cessez de vous préoccuper des meilleures pratiques et concentrez-vous sur ce que vous pouvez faire de mieux. Ne faites pas quelque chose à cause d’une citation que vous avez lue quelque part, ou parce que vous avez vu quelqu’un d’autre le faire, ou parce que quelqu’un a dit que c’est une bonne pratique. Défiez toutes les théories, connaissez toutes vos options et ne prenez que des décisions éclairées.
13) Obsession de la performance
Bien que la programmation ait changé de façon significative depuis que Donald Knuth a écrit la déclaration ci-dessus, elle contient encore de précieux conseils aujourd’hui. La bonne règle à retenir à ce sujet est la suivante : si vous ne pouvez pas mesurer le problème de performances avec le code, n’essayez pas de l’optimiser. Si vous optimisez avant d’exécuter le code, il y a de fortes chances que vous le fassiez prématurément. Il y a aussi une grande chance que l’optimisation que vous faites soit complètement inutile. Toute optimisation non évidente qui est effectuée sur un code existant sans mesures est considérée comme nuisible et doit être évitée. Ce que vous pensez être un gain de performance, pourrait s’avérer être une source de nouveaux bugs inattendus. Ne perdez pas votre temps à optimiser les problèmes de performance non mesurés.
14) Ne pas cibler l’expérience de l’utilisateur final
Quel est le moyen le plus simple d’ajouter une fonctionnalité à une application ? Regardez-le de votre point de vue et de comment il s’intègre dans l’interface utilisateur actuelle. Soyez l’un de ces développeurs qui se mettent à la place de leurs utilisateurs. Ils imaginent ce dont les utilisateurs de cette fonctionnalité ont besoin et comment ils peuvent se comporter. Ils réfléchissent aux moyens de rendre la fonctionnalité facile à trouver et à utiliser, et non à la manière de faire en sorte que la fonctionnalité existe sans aucune réflexion sur la possibilité d’utiliser cette fonctionnalité.
Donald Knuth (1974)
15) « Réinventer la roue »
C’est un point délicat. La programmation n’est pas un domaine bien défini. Les choses changent très vite et de nouvelles exigences sont introduites très rapidement. Par exemple, si vous avez besoin d’une roue qui tourne à différentes vitesses en fonction de l’heure de la journée, au lieu de personnaliser la roue que nous connaissons tous peut-être devons-nous la repenser. Ce qui est génial avec les «roues» logicielles, c’est que la plupart d’entre elles sont gratuites et ouvertes pour que vous puissiez voir leur design interne. Vous pouvez facilement juger les roues de codage en fonction de leur qualité de conception interne. Utilisez des roues open-source si vous le pouvez qui peuvent être débogués et corrigés facilement. N’incluez pas une bibliothèque entière juste pour utiliser une ou deux fonctions. Le meilleur exemple à ce sujet est la bibliothèque lodash en JavaScript. Si vous avez juste besoin de mélanger un tableau, il vous suffit d’importer la méthode shuffle. N’importez pas toute la librairie lodash.
16) Avoir la mauvaise attitude envers des avis sur votre code
Un signe d’un codeur débutant est qu’il considère souvent les avis sur le code comme une critique. Si vous ressentez cela, vous devez changer cette attitude tout de suite. Regardez chaque avis sur le code comme une opportunité d’apprentissage. Et, le plus important, est d’avoir des critiques constructives. Dans le code, vous en apprendrez chaque jour. La plupart des avis vous apprendront quelque chose que vous ne saviez pas. Parfois, la critique ne sera pas opportune et ce sera à votre tour de leur apprendre quelque chose. Cependant, si quelque chose n’est pas évident à partir de votre code, alors peut-être qu’il doit être modifié. Si vous avez besoin d’apprendre quelque chose à ceux qui vous critique, sachez simplement que l’enseignement est l’une des activités les plus enrichissantes que vous puissiez faire en tant que programmeur.
17) Ne pas utiliser le contrôle du code source
Les débutants sous-estiment parfois la puissance d’un bon système de contrôle de source / révision. Le contrôle de la source ne consiste pas seulement à pousser vos changements pour que les autres puissent les développer. Le contrôle de la source concerne l’historique clair. Le code sera remis en question et l’historique des progrès de ce code aidera à répondre à certaines des questions les plus difficiles. C’est un autre canal pour communiquer vos implémentations et aident les futurs responsables de votre code à comprendre comment le code a atteint l’état dans lequel il se trouve actuellement. Soyez précis avec vos messages, mais gardez à l’esprit qu’ils doivent être des résumés. N’incluez rien d’inutile dans vos messages de validation. Par exemple, ne répertoriez pas les fichiers qui ont été ajoutés, modifiés ou supprimés dans vos récapitulatifs. Le contrôle de la source concerne également la découvrabilité. Si vous rencontrez une fonction et que vous commencez à questionner son besoin ou son design, vous pouvez trouver le commit qui l’a introduit et voir le contexte de cette fonction. Les validations peuvent même vous aider à identifier quel code a introduit un bogue dans le programme. Git propose même une recherche binaire dans commits (la commande bisect) pour localiser le seul commit coupable qui a introduit un bug.
18) Surutilisation de la programmation par état partagé
L’état partagé est une source de problèmes et devrait être évité, si possible. Si cela n’est pas possible, l’utilisation de l’état partagé doit être réduite au strict minimum. En tant que programmeur débutant, vous n’avez peut-être pas réalisé que chaque variable que nous définissons représente un état partagé. Il contient des données qui peuvent être modifiées par tous les éléments dans la même portée que cette variable. Plus la portée est globale, plus la durée de cet état partagé est mauvaise. Le gros problème avec l’état partagé commence lorsque plusieurs ressources doivent changer cet état ensemble dans la même boucle d’événements.
19) Avoir la mauvaise attitude à propos des erreurs
Les erreurs sont une bonne chose, elles signifient que vous faites des progrès. Les programmeurs experts aiment les erreurs, les débutants les détestent. Si voir ces merveilleux petits messages d’erreur rouges vous dérange, vous devez changer votre attitude. Vous devez les regarder comme des aides et vous devez les utiliser pour progresser. Certaines erreurs doivent être considérées comme des exceptions. Les exceptions sont des erreurs définies par l’utilisateur que vous devez planifier. Certaines erreurs doivent être laissées. Elles ont besoin de planter l’application afin de les faire sortir.
20) Ne pas prendre de pauses
Vous êtes un humain et votre cerveau a besoin de pauses. Ce n’est pas quelque chose que vous pouvez compromettre. Intégrez quelque chose dans votre flux de travail pour vous forcer à faire des pauses. Prenez beaucoup de pauses, mais plus courtes. Laissez votre bureau et faites une courte promenade. Utilisez ce moment pour réfléchir à ce que vous devez faire ensuite. Revenez au code avec des yeux tout neufs.
Nous espérons que cet article vous a aidé à ne pas tomber dans les pièges courants lorsque vous êtes un développeur junior. Avez-vous d’autres astuces à nous partager ? N’hésitez pas à nous laisser un petit commentaire ci-dessous.
Si le sujet du codage vous intéresse, je vous invite fortement à parcourir ces articles :