Les erreurs que commettent les développeurs juniors
Livrer du code qui fonctionne est le minimum requis. Ce n'est pas l'objectif.
J'ai une fois passé en revue une pull request qui a pris 45 minutes à comprendre. La logique était correcte. Les tests passaient. Mais le code avait été écrit comme si seul l'auteur allait un jour le lire.
Quand j'ai fait mon retour, le développeur a dit : « Mais ça marche. »
Il avait raison. Ça marchait. C'était précisément là le problème.
Les développeurs juniors se concentrent souvent sur les compétences techniques. Mais les véritables lacunes résident souvent dans les habitudes et l'état d'esprit.
Voici les erreurs subtiles qui vous ralentissent :
Écrire pour soi plutôt que pour les autres Le code est lu bien plus souvent qu'il n'est écrit. Une fonction que vous écrivez aujourd'hui pourrait être modifiée par trois personnes différentes sur deux ans. Si un inconnu ne peut pas comprendre votre code en 30 secondes, vous avez échoué.
Copier du code sans le comprendre Utiliser Stack Overflow ne pose aucun problème. Copier un pattern regex sans savoir comment il fonctionne est dangereux. Vous créez une boîte noire dans votre base de code. Vous ne pourrez pas la déboguer lorsqu'elle tombera en panne.
Ajouter une complexité inutile Les juniors assimilent souvent la complexité à la compétence. Ils appliquent des design patterns à des tâches simples. Une abstraction inutile rend le code plus difficile à déboguer et à modifier. N'ajoutez de l'abstraction que lorsque vous ressentez la douleur de son absence.
Ignorer les messages d'erreur Les messages d'erreur sont une documentation gratuite. Ne foncez pas sur Google dès que vous voyez une stack trace. Lisez l'intégralité du message. Il vous indique souvent exactement quelle ligne a échoué et pourquoi.
Demander de l'aide trop tôt ou trop tard Ne passez pas trois heures bloqué sur un problème de 10 minutes. C'est inefficace. Mais ne sollicitez pas un senior avec une simple capture d'écran sans contexte. Utilisez la règle des 20 minutes : passez 20 minutes à essayer de résoudre le problème. Documentez ce que vous avez tenté. Ensuite, demandez de l'aide en fournissant cette documentation.
Réinventer ce qui existe déjà Avant d'écrire une nouvelle utilité, cherchez dans la base de code. Votre équipe a probablement déjà résolu ce problème.
De mauvais messages de commit Un message de commit comme « fix bug » n'apprend rien à votre équipe. Expliquez ce qui a changé et pourquoi. Considérez l'historique Git comme une documentation.
Traiter les spécifications comme une loi absolue Les spécifications omettent souvent des cas limites. Ne vous contentez pas d'implémenter ce qu'on vous demande. Demandez ce qui se passe quand les choses tournent mal.
S'arrêter au bouton « Merged » Le sens des responsabilités ne s'arrête pas lorsque votre PR est fusionnée. Suivez votre fonctionnalité jusqu'à la QA. Surveillez-la en production. Lisez les rapports d'erreurs.
La plus grande lacune est le sens des responsabilités. Les développeurs seniors ne se contentent pas d'écrire du code. Ils résolvent des problèmes sans en créer de nouveaux.
Arrêtez d'optimiser pour le « terminé ». Commencez à optimiser pour le « bien fait ».