Les mauvaises habitudes sont difficiles à casser et encore plus difficiles si vous ne vous rendez pas compte que ce que vous faites sape votre travail. Si vous le savez mais que vous vous en fichez – ce serait le pire. Mais vous êtes ici, n’est-ce pas ?
En tant que programmeur, j’ai vu beaucoup de mauvaises pratiques, pas seulement autour du code, mais aussi autour des compétences de travail en équipe. J’ai moi-même été coupable de pratiquer plusieurs de ces mauvaises habitudes. Voici mes 35 principales mauvaises habitudes de programmation, organisées en quatre catégories : l’organisation du code, le travail d’équipe, l’écriture du code, et les tests et la maintenance.
Organisation du code
1. Dire, « Je le corrigerai plus tard »
L’habitude de reporter les corrections du code n’est pas simplement un problème de priorités. L’organisation de votre gestionnaire de problèmes peut générer quelques progrès, mais vous devez également avoir un moyen de suivre les petits problèmes qui surgissent. L’ajout de commentaires « TODO » est un moyen rapide de s’assurer que vous ne manquez rien.
2. Insister sur une solution en une seule ligne
Etre obsédé par l’écriture de morceaux de code efficaces et élégants est un trait commun aux programmeurs. C’est comme résoudre un puzzle – vous trouvez une combinaison de fonctions et d’expressions régulières qui transforme 20 lignes de code en 2 ou 3. Malheureusement, cela ne se traduit pas toujours par un code lisible, ce qui est généralement le résultat le plus important. Rendez votre code accessible d’abord, puis intelligent.
3. Faire des optimisations inutiles
Un autre endroit où nous déplaçons souvent nos efforts est celui des optimisations. Cela semble génial de réduire la taille de votre site web de quelques octets, mais le gzip ne compensera-t-il pas de toute façon ? Et les requêtes ne sont-elles pas plus importantes ? Abordez les optimisations à la fin d’un projet, car le plus souvent, les exigences changeront, et votre temps aura été perdu.
« L’optimisation prématurée est la racine de tous les maux. »
-Donald Knuth
4. Se convaincre que les problèmes de style ne sont pas si importants
Si j’ai appris quelque chose au cours des années passées à regarder le code des autres, c’est que le traitement des problèmes de style de codage est la chose que les développeurs sont le plus susceptibles de remettre à plus tard. Il est peut-être difficile pour les codeurs inexpérimentés de voir ce qu’il y a de bon à traiter les problèmes de style, mais avec le temps, il deviendra évident qu’une fois que la qualité du code déraille, un effet boule de neige transformera n’importe quel projet en un désordre complet. Soyez strict sur les meilleures pratiques, même si elles semblent négligeables. Mettez en place des outils de vérification du code et de linting pour vous donner de l’espace pour vous préoccuper des choses plus importantes.
5. Balayer les choses sous le tapis
Soit en attrapant et en ignorant les exceptions, soit en utilisant des bibliothèques qui ne signalent pas les erreurs (comme jQuery), il existe de nombreuses façons de balayer les choses sous le tapis. Mais lorsque l’une de ces erreurs devient une priorité, le défi de la corriger sera bien plus grand, étant donné que vous n’aurez pas la moindre idée de par où commencer. Un moyen facile d’éviter cela est de consigner ces erreurs ignorées afin de pouvoir les étudier plus tard.
6. Utiliser des noms qui n’ajoutent pas d’information
Nommer est difficile, mais il y a un moyen facile de s’assurer que vos noms de variables et de fonctions sont au moins de qualité décente. Tant que les noms ajoutent une sorte d’information que le reste du code ne transmet pas, les autres développeurs auront plus de facilité à lire votre code. La raison pour laquelle la dénomination est si importante est que les noms peuvent donner une idée générale de ce que fait le code. Cela prend plus de temps si vous devez creuser dans les calculs pour comprendre ce que fait un morceau de code, mais un bon nom peut vous aider à comprendre ce que fait le code en quelques secondes.
7. Ignorer les meilleures pratiques éprouvées
Les revues de code, le développement piloté par les tests, l’assurance qualité, l’automatisation du déploiement – ces pratiques, et plusieurs autres, ont prouvé leur valeur dans d’innombrables projets, ce qui explique pourquoi les développeurs en parlent constamment sur leur blog. Une excellente référence pour ces meilleures pratiques est le livre Making Software : What Really Works, and Why We Believe It. Prenez le temps d’apprendre à les faire correctement, et votre processus de développement s’améliorera dans tous vos projets d’une manière qui vous surprendra.
Travail d’équipe
8. Abandonner les plans trop tôt
Un moyen infaillible de rendre votre système impénétrable est de ne pas s’engager dans un plan. Vous pouvez toujours dire, chaque fois que votre code est critiqué, que le plan n’est pas complet. Cependant, le fait d’avoir des modules à moitié terminés conduira à un code étroitement couplé dès que vous essayerez de faire fonctionner ces modules non terminés les uns avec les autres. Ce genre de complication survient également lorsque les rôles de direction d’un projet changent et que les nouveaux responsables décident que l’avoir à leur façon est plus important que la cohérence architecturale.
9. Insister sur un plan qui a peu de chances de fonctionner
De même que l’abandon de vos plans peut causer des problèmes, il en va de même pour s’en tenir à un plan qui ne fonctionne pas. C’est pourquoi vous devez partager vos idées avec votre équipe afin d’obtenir des retours et des conseils lorsque les choses se compliquent. Parfois, une perspective différente peut faire toute la différence.
10. Travailler seul tout le temps
Vous devriez vous efforcer de partager vos progrès et vos idées avec l’équipe. Parfois, vous pensez que vous construisez quelque chose de la bonne façon, mais vous ne l’êtes pas, donc une communication constante est très précieuse. Il est également bénéfique pour les autres personnes que vous travailliez avec elles. Leur travail s’améliore souvent lorsque vous discutez des idées avec eux et que vous encadrez les membres les moins expérimentés de votre équipe, qui sont plus susceptibles d’être bloqués.
11. Refuser d’écrire du mauvais code
Il arrive un moment dans la vie de chaque développeur où les délais vous obligeront à écrire du code terrible, et c’est correct. Vous avez essayé d’avertir votre client ou votre manager des conséquences, mais ils insistent pour s’en tenir à la date limite, alors maintenant il est temps de coder. Ou peut-être y a-t-il un bug urgent qui ne peut pas attendre que vous trouviez une solution propre. C’est pourquoi il est important d’être polyvalent en tant que programmeur et d’être capable d’écrire aussi bien du mauvais code très rapidement que du bon. Avec un peu de chance, vous pourrez revisiter le code et rembourser la dette technique.
12. Blâmer les autres
Ce n’est pas un secret que l’arrogance est un trait trop commun chez les développeurs et autres professionnels techniques. Assumer la responsabilité de vos erreurs est une vertu qui vous fera briller parmi vos pairs. N’ayez pas peur d’admettre que vous avez fait une erreur. Une fois que vous l’aurez accepté, vous pourrez vous concentrer sur les raisons de cette erreur et sur la manière de l’éviter. Si vous ne l’admettez pas, l’apprentissage devient impossible.
13. Ne pas partager avec votre équipe ce que vous avez appris
Votre valeur en tant que développeur n’est pas seulement placée sur le code que vous écrivez, mais aussi sur ce que vous apprenez en l’écrivant. Partagez vos expériences, écrivez des commentaires à ce sujet, faites savoir aux autres pourquoi les choses sont comme elles sont, et aidez-les à apprendre de nouvelles choses sur le projet et ses subtilités.
14. Être trop lent à donner du feedback aux managers/clients
L’un des traits de caractère les plus précieux de tout artisan réside dans le fait de s’assurer que tout le monde est sur la même longueur d’onde concernant le travail, autant que possible. La raison de cette démarche n’est pas pour que votre manager puisse remplir des feuilles de calcul. C’est aussi pour votre propre bénéfice : Vous aurez moins d’insécurités et réduirez les incertitudes sur la durée de vie et l’avenir du projet.
15. Ne pas utiliser suffisamment Google
La meilleure façon de résoudre rapidement un problème complexe est de ne pas avoir à le résoudre du tout. En cas de doute, utilisez Google. Bien sûr, vous pouvez plutôt déranger l’ingénieur à côté de vous, mais il sera rarement en mesure de donner une réponse aussi détaillée que Stack Overflow, sans compter que vous interromprez également son travail.
16. Survaloriser votre style personnel
Toujours chercher à coordonner votre style de travail et la configuration de votre environnement avec votre équipe. Idéalement, tous les membres de votre équipe devraient travailler dans des conditions similaires et suivre le même style de codage. Faire les choses à votre façon peut être plus amusant, mais les collègues peuvent ne pas être habitués à votre style de codage, et s’il est inhabituel, il sera plus difficile pour le développeur suivant de travailler sur ce que vous avez construit.
17. Avoir un attachement personnel à votre code
Lorsque quelqu’un fait des commentaires sur votre code, ne le prenez pas personnellement. Votre code devrait reposer sur des bases solides, c’est-à-dire que vous devriez être en mesure d’expliquer pourquoi vous l’avez écrit de cette façon. S’il a besoin d’être amélioré, ce n’est qu’un reflet de la correction du code, pas de vous-même.
Écrire du code
18. Ne pas savoir comment optimiser
Une bonne stratégie d’optimisation demande une certaine expérience pour être correcte. Il faut explorer, analyser et connaître chaque système impliqué dans un processus. Informez-vous sur ces choses. Apprenez la complexité algorithmique, l’évaluation des requêtes de base de données, les protocoles et la façon de mesurer les performances en général.
19. Utiliser le mauvais outil pour le travail
Vous ne pouvez pas en savoir plus, mais la raison pour laquelle vous devez continuer à apprendre est que chaque nouveau problème apporte un contexte différent et nécessite un outil différent – un plus applicable à la tâche à accomplir. Soyez ouvert aux nouvelles bibliothèques et aux nouveaux langages. Ne prenez pas de décisions basées strictement sur ce que vous savez.
20. Ne pas s’embêter à maîtriser vos outils et votre IDE
Chaque nouvelle touche de raccourci, raccourci ou paramètre que vous apprenez en utilisant les outils avec lesquels vous travaillez tous les jours aura un effet plus positif sur votre vitesse de codage que vous ne le pensez. Il ne s’agit pas de gagner quelques secondes en utilisant un raccourci clavier ; il s’agit de réduire le changement de contexte. Plus vous passez de temps sur chaque petite action, moins vous aurez de temps disponible pour réfléchir à ce que vous faites et à ce qui va suivre. Maîtriser les raccourcis vous permettra de libérer votre esprit.
21. Ignorer les messages d’erreur
Ne supposez pas que vous savez ce qui ne va pas dans votre code sans même lire un message d’erreur, ou que vous le découvrirez assez rapidement. Avoir plus d’informations sur un problème est toujours mieux, et prendre le temps de rassembler ces informations vous fera gagner plus de temps à long terme.
22. Romantiser votre boîte à outils de développeur
Parfois, votre éditeur préféré ou votre outil de ligne de commande n’est pas le meilleur outil pour le travail à accomplir. Visual Studio est excellent pour les IDE d’écriture, Sublime est excellent pour les langages dynamiques, Eclipse est excellent pour Java, et ainsi de suite. Vous pouvez aimer vim ou emacs, mais cela ne signifie pas que c’est le bon outil pour chaque travail.
23. Coder en dur des valeurs au lieu de les rendre configurables
Toujours penser à ce que les changements pourraient venir et comment y faire face. La dette technique augmentera à un rythme monstrueux si vous ne séparez pas les pièces mobiles du reste de votre travail. Utilisez des constantes et des fichiers de configuration lorsque cela est approprié.
24. Réinventer la roue tout le temps
Ne pas écrire du code dont vous n’avez pas besoin. Peut-être que quelqu’un d’autre a déjà passé beaucoup de temps sur votre problème, et il pourrait avoir une solution bien testée que vous pouvez réutiliser. Épargnez-vous des problèmes.
25. Copier/coller aveuglément du code
Comprendre le code avant de le réutiliser. Parfois, vous ne remarquez pas immédiatement tout ce que le code fait au premier coup d’œil. Vous en apprendrez également plus sur un problème lorsque vous prendrez le temps de lire le code en détail.
26. Ne pas prendre le temps d’apprendre comment les choses fonctionnent vraiment
Toujours saisir l’occasion d’élargir vos connaissances en réfléchissant au fonctionnement des choses et en lisant sur leurs problèmes sous-jacents. Vous pourriez gagner du temps en ne vous donnant pas la peine de le faire maintenant, mais ce que vous apprendrez sur un projet sera plus important à long terme que de le réaliser réellement.
27. Avoir une confiance excessive dans votre propre code
Il est dangereux de supposer que juste parce que vous avez écrit quelque chose, il doit être génial. Vous apprenez plus sur la programmation à mesure que vous travaillez sur de nouvelles choses et gagnez de l’expérience, alors jetez un coup d’œil à votre ancien code de temps en temps et réfléchissez à la façon dont vous avez progressé.
28. Ne pas penser aux compromis de chaque conception, solution ou bibliothèque
Chaque produit a ses points fins que vous ne découvrirez qu’en l’utilisant et en l’analysant. Le fait de voir quelques exemples d’utilisation d’une bibliothèque ne fera pas de vous un maître en la matière, et cela ne signifie pas non plus qu’elle est parfaitement adaptée à toutes les situations qui se présenteront dans votre projet. Soyez continuellement critique envers tout ce que vous utilisez.
29. Ne pas demander de l’aide quand vous êtes coincé
Garder une boucle de rétroaction courte sera toujours moins douloureux pour vous. Demander de l’aide ne signifie pas que vous êtes incompétent. Les bonnes personnes verront votre effort et l’admission de votre ignorance comme une volonté d’apprendre, et c’est une grande vertu à avoir.
Tests et maintenance
30. Écrire des tests pour passer
Écrire des tests dont on sait qu’ils passeront est nécessaire. Ils rendront le refactoring et la réorganisation d’un projet beaucoup plus sûrs. D’un autre côté, vous devez aussi écrire des tests dont vous savez qu’ils ne passeront pas. Ils sont nécessaires pour faire avancer le projet et garder la trace des problèmes.
31. Ne pas tenir compte des tests de performance pour les cas critiques
Préparer une configuration de tests de performance automatisés à peu près au milieu du processus de développement d’un projet afin de vous assurer que vous n’avez pas de problèmes de performance qui s’intensifient.
32. Ne pas vérifier que votre build fonctionne
Il est rare qu’un build passe mais ne fonctionne pas vraiment, mais cela peut arriver, et il pourrait être gênant de corriger le problème plus vous attendez pour l’examiner. Tester rapidement chaque build est une habitude importante à avoir.
33. Pousser de grands changements tardivement, ou partir après avoir fait un grand push
C’est là que l’excès de confiance vous mènera, et il peut falloir se faire brûler plusieurs fois pour apprendre pourquoi vous ne devriez pas le faire, alors suivez mon conseil maintenant et assurez-vous d’être toujours là quand votre build finit par casser.
34. Désavouer le code que vous avez écrit
Soyez prêt à soutenir le code que vous avez écrit. Vous êtes la personne la plus apte à aider les autres à le comprendre. Vous devriez vous efforcer de faire en sorte que votre code reste lisible pour vous-même et pour les autres dans de nombreuses années.
35. Ignorer les exigences non fonctionnelles
Lorsque vous essayez de livrer quelque chose, il peut être facile d’oublier certains domaines importants comme les performances et la sécurité. Gardez une liste de contrôle pour ceux-ci. Vous ne voulez pas qu’ils gâchent votre fête parce que vous avez établi vos délais sans penser à ces préoccupations non fonctionnelles.
Quelles sont vos pires habitudes de programmation ?
Comme on le dit souvent, nous sommes des créatures d’habitudes. Améliorer la façon dont vous travaillez grâce à des habitudes est un excellent moyen d’éviter de devoir trop réfléchir à chaque situation. Une fois que vous avez assimilé une bonne façon de faire quelque chose, cela devient sans effort.