Savoir faire, ne veux pas dire le faire correctement.
Vouloir apprendre le développement et devenir développeur est une bonne chose. Aujourd’hui, avoir ces compétences permettent de créer énormément de choses et d’avoir un gros avantage.
Mais faut-il encore les apprendre et les utiliser correctement.
Lorsque tu te formes au développement, on ne te parle pas toujours des bonnes façons de faire, de coder, de pratiquer. Et encore moins des mauvaises habitudes à ne pas prendre.
Si tu n’y fais pas attention, tu vas adopter des automatismes et des façons de faire qui ne sont pas bonnes. Elles te freineront tout au long de ta carrière. Prendre de mauvaises habitudes est un frein lorsque tu travail en équipe et lorsque tu souhaites évoluer et t’améliorer.
Il faut savoir en prendre conscience de ces mauvaises habitudes de développeur et les corriger au plus vite.
Heureusement dans cet article je vais te parler des 12 mauvaises habitudes des développeurs. Ainsi tu pourras voir si tu as (ou non) ces mauvaises habitudes. Si c’est le cas, demande-toi comment tu peux les modifier pour les transformer en bonnes habitudes.
Écrire du code avant de penser,
Lorsque l’on débute dans la programmation, on est tout fou, on veut coder, coder, coder. Parfois sans trop réfléchir avant.
Malheureusement, la programmation doit résoudre des problématiques complexes qui doivent être correctement penser avant d’être codée.
Avant de se lancer dans le code, il faut réfléchir à la solution finale. Modéliser son idée, la schématiser, réfléchir aux différents aspects qui pourraient ne pas fonctionner, quels autres problématiques on peut rencontrer en chemin.
Il faut surtout réfléchir à une structure de code qui soit maintenable, propre, sécurisée, etc. Une fois que toutes ces choses ont été pensé correctement tu peux te lancer dans le code.
Avec l’expérience, plus le problème à résoudre sera facile, moins tu auras besoin de penser. Tu auras certains automatisme et mécanismes qui te permettront de penser rapidement à une solution.
Lorsque je fais face à un problème complexe, qui demande de la réflexion, je sors la tête de mon ordinateur et je prends une feuille de papier. Je note ainsi les choses importants, j’imagine certaines solutions, je schématise mes idées. Cela me permets d’y voir plus claire et par la suite et de coder en sachant où je vais.
Ne pas connaitre les fondements du langage utilisé
Apprendre un nouveau langage est une chose complexe. Chaque langage a sa propre syntaxe, ses propres concepts, ses propres fonctionnalités, …
Pour le maitriser, il est essentiel de bien connaitre tous ses fondements. C’est un peu comme une maison. Toute la maison repose sur les fondations. Si elles ne sont pas solides, tout le reste de la maison ne le sera pas non plus. Et pour réaliser des fondations solides, il faut apprendre à les réaliser.
Il n’y a rien de pire que de coder dans un langage, sans vraiment connaitre les bases de celui-ci. Si tu l’apprends en bricolant quelques bouts de code par-ci par-là, sans les comprendre et en te disant que ça fonctionne, c’est mal parti.
Le risque est de ne pas savoir résoudre correctement une problématique complexe par la suite. Mais aussi de réaliser du code qui ne soit pas maintenable et surtout de ne pas pouvoir travailler en équipe en reprenant le code d’autres personnes.
Lorsque tu apprends les bases d’un langage, fais le étape par étape. Cherche toujours à comprendre ce que tu es en train de faire. Pourquoi tu as fait telle ligne de code ? A quoi sert -elle ? Quel impact elle a sur le reste de ton code ? Est-ce que tu aurais pu le faire différemment ?
Il existe de nombreux sites pour apprendre à coder correctement. Ces sites te montreront les bases à apprendre. Je t’ai fait un article qui te donne une liste de 8 sites qui t’aideront.
Ne pas documenter son code
Bon j’avoue je ne le fais pas tout le temps (voir pas souvent) mais c’est une erreur.
Documenter son code permets aux autres développeurs qui peuvent reprendre le code par la suite de le comprendre. Il te permettra à toi aussi de t’y retrouver dans quelques mois ou années quand tu reprendras un bout de code.
Il m’est déjà arrivé de reprendre un vieux code et d’être perdu. De ne pas savoir à quoi servaient certaines fonctions. On ne va pas se le cacher, lorsque tu reprendras un code que tu as fait il y a un an ou deux, tu seras horrifié. Tu auras tellement progressé que tu te demanderas comment tu as fait pour pondre quelque chose d’aussi moche. Et le pire c’est que tu ne comprendras même plus ce que tu auras fait. C’est pour ça que la documentation pourra t’aider et pourra aider d’autres développeurs s’ils reprennent ton code.
Lors d’un de mes stages, je suis arrivé dans une entreprise où j’étais le seul développeur. L’ancien était parti avant mon arrivé. Il avait commencé à développer un programme avec un Framework JS que je ne maitrisé pas du tout. De plus, le code n’était pas hyper propre.
J’avais vraiment du mal à m’y retrouver et à comprendre ce qui avait été fait. Le code n’était pas documenté. A ce moment-là j’aurais souhaité avoir une documentation qui m’expliquait à quoi chaque partie de code correspondaient.
Tu n’as pas besoin de documenter la moindre ligne de ton code, mais au moins les parties une peu complexes. Avec les IDE actuels, tu as la possibilité d’ajouter des annotations dans ton code, qui généreront automatiquement une documentation. Il est donc moins contraignant de documenter son code.
Ne pas considérer le point de vue et/ou la critique des autres
Haaaa l’égo des développeurs.
Beaucoup de développeurs pensent qu’ils maitrisent tout. Que leur code est parfait, qu’ils utilisent la meilleure technologie du monde et qu’ils font tout bien.
Ils se trompent et c’est bien dommage.
Si tu es développeur, tu dois toujours te remettre en question, apprendre de nouvelles choses, apprendre des autres, écouter les conseils et la critique.
Bien sûr toutes les critiques ne sont pas constructives ou bonnes à prendre. Il faut savoir prendre les bonnes, celles qui te font progresser et évoluer.
Il n’est pas toujours facile d’entendre des critiques, d’entendre dire qu’il vaudrait mieux faire comme-ci ou comme-ça. Mais interroge-toi sur la façon de faire, demande-toi pourquoi on t’a fait une critique sur ton code. Fais des recherches pour comprendre s’il existe une meilleure façon de faire.
Il existe de nombreuses façons de résoudre un même problème. Chaque développeur a sa propre vision des choses et sa façon de penser. C’est aussi la beauté du développement. Certaines personnes ne réfléchissent pas du tout de la même manière et vont avoir des angles d’attaque différents pour un même problème. Discuter de ces différentes visions te permettra de t’ouvrir, de voir les choses différemment et penser différemment.
Ne pense pas non plus qu’une personne moins expérimentée que toi ne peut rien t’apporter. Au contraire, elle aura une vision moins technique que toi et apportera de nouvelles solutions, peut-être plus simple. Les conseils des personnes moins expérimentées sont toujours bons à prendre.
Pour les autodidactes, il peut être plus difficile d’écouter les conseils des autres. Les personnes qui ont tout appris toute seules peuvent avoir tendance à être plus réfractaire aux conseils et enseignements extérieurs ainsi qu’aux méthodes d’apprentissages académique classique. Il faut donc faire attention à cet aspect et savoir se remettre en question.
Copier-coller du code trouvé sur internet
Tout développeur a déjà vécu cette expérience. Tu es bloqué sur un problème, tu vas faire quelques recherches sur internet et tu tombes sur un bout de code qui a l’air de résoudre ton problème parfaitement. Tu le copie-colle comme un gros bourrin dans ton code et ça fonctionne.
Alors pourquoi ne pas le faire ?
Tout simplement parce qu’en faisant comme ça, tu ne comprends pas comment marche ton code et tu seras incapable de corriger l’erreur si elle se reproduit plus tard ou même d’améliorer ton code. De plus, si tu ne maitrise pas les tenants et les aboutissants de ton code, tu prends le risque d’introduire des failles dans ton code.
Peut-être que le bout de code récupéré est très bien pour une certaine situation mais n’est pas tout à fait adapté à la tienne.
Bien sûr, tu peux récupérer du code que tu trouves sur internet, le copier-coller (pour ne pas le réécrire à la main). Mais il faut que tu le comprennes. Il faut que tu comprennes chaque ligne que tu écris, à quoi sert chaque fonction et chaque variable. Et surtout que tu sois capable de le modifier pour l’adapter correctement à ton code et au problème que tu résous.
Ne penser qu’à l’argent
Etre développeur, c’est avoir des connaissances pour créer énormément de choses, bonnes ou mauvaises. Avec de telles connaissances, il est possible de développer des bouts de scripts, des sites pour récupérer certaines informations confidentielles sur les clients pour les revendre ou bien d’autres choses illégales.
Il est facile de franchir la barrière de la légalité lorsque l’on est développeur.
Mais pourquoi franchir la ligne de la légalité ?
Pour se faire de l’argent. Sur internet, et avec quelques connaissances en développement, il peut être assez facile de se faire de l’argent (sale).
Certaines personnes souhaitent apprendre le développement uniquement pour développer des programmes / sites à des fins illégales pour se faire de l’argent facilement.
Malheureusement, en voulant faire ce genre de choses, il y a de fortes chances pour se faire attraper et risquer gros. Si tu n’es pas expert dans ce domaine, il y aura toujours un petit détail qui te trahira dans ton code.
Il y a aussi les personnes qui apprennent le développement uniquement parce que le métier de développeur paye bien. C’est une erreur de faire ça.
Le métier de développeur n’est pas facile, il y a beaucoup de choses à apprendre et il faut vraiment aimer ça pour se lancer là-dedans. La motivation de l’argent ne sera pas suffisant.
Tester en production ou pousser du code non tester en production
On est jeudi, 17h30 et tu reçois un appel pour te dire qu’il y a un petit bug en production et qu’il faut le corriger. Pour toi, il n’y a pas grand-chose à corriger, juste 2 ou 3 lignes de code à rajouter et le tour est joué. Tu ajoutes les quelques lignes directement dans l’environnement de production sans tester si ton code fonctionne.
Après quelques minutes, ton code semble fonctionner correctement, de plus c’est l’heure de la débauche, tu quittes donc ton poste.
Pendant la nuit, on t’appelle en te disant que le site est tombé, qu’il ne fonctionne plus et que plus personne n’a accès au site. Pas de bol c’est un site e-commerce sur lequel les gens font leurs achats le soir. Tu viens de faire perdre 24 520 € de chiffre d’affaire à ton patron…
Tout ça, pour 2 lignes de code qui n’ont pas été testé correctement.
Lorsque tu développes, ne le fait jamais sur l’environnement de production, ne pousse jamais du code que tu n’as pas testé en production et ne teste jamais ton code en production.
Si tu introduis des bugs en production, tu prends d’énormes risques.
Même à petite échelle, sur un petit site avec peu de trafic, ne prends pas cette habitude. Teste toujours sur ton environnement de dév ou de recette.
Abandonner facile et manquer d’obstination
En tant que développeur, tu vas passer tes journées à être confronté à des difficultés. Chaque fonctionnalité que tu vas ajouter est un problème que tu dois solutionner.
Parfois c’est assez facile et tout roule correctement, parfois c’est un peu plus complexe. Ton code ne marche pas forcément comme tu le souhaites, tu n’arrives pas à trouver de solution, tu ne trouves aucune documentation sur internet …
Tu feras face à de nombreuses fois à ce genre de situation et il faudra savoir les surmonter et trouver des solutions. Si tu n’es pas capable de passer des heures voir des jours pour trouver une solution à ton blocage, le métier de développeur va être compliqué pour toi.
Il arrive régulièrement que les développeurs passent des heures pour trouver une solution à quelque chose qui ne fonctionne pas. Il ne faut pas abandonner et continuer de chercher. Tu trouveras toujours une solution.
Ne plus apprendre
Lorsque tu vas apprendre le développement, tu vas forcément t’orienter vers les choses qui t’intéressent le plus. A force d’apprendre tu vas atteindre un bon niveau et tu seras capable de réaliser de bons programmes.
C’est à ce moment-là qu’il faut faire attention. Lorsque tu maitriseras suffisamment une technologie, il ne faudra pas cesser d’apprendre.
Tu peux penser que tu as toutes les connaissances nécessaires et que tu n’as plus besoin d’apprendre quoi que ce soit. Tu te confortes dans l’idée que tu maitrises tout et que tu connais suffisamment de choses pour développer n’importe quoi.
Mais le monde du développement est en perpétuel évolution, les choses avancent très vite. Si tu n’apprends pas en permanence, tu vas vite être dépassé et tes connaissances ne suffiront plus où seront obsolètes.
Il n’est pas toujours évident de se relancer dans l’apprentissages d’un nouveau langage, d’un framework ou d’une nouvelle version, mais cette apprentissage est nécessaire dans le monde du développement.
Ne pas être sûr du résultat de ton code
Il m’est arrivé, lorsque j’étais en alternance, de travailler sur un bout de code JavaScript qui faisait de l’asynchrone. Des requêtes partaient au serveur, le code devait attendre la réponse du serveur et la traiter.
Mais parfois (dans environ 20% des cas), le code ne fonctionnait pas tout à fait correctement et une action été réalisé avant la réponse du serveur. A ce moment-là je me suis dit : « dans 80% des cas le code fonctionne correctement, ça devrait aller ».
J’aurais pu livrer comme ça.
Et après je me suis dit qu’il y allait avoir pas mal de personnes qui allaient utiliser cette fonctionnalité et que je ne pouvais pas me permettre de livrer quelque chose qui marchait à moitié. J’ai donc cherché (pendant plusieurs heures) comment faire pour que mon code fonctionne dans 100% des cas et j’ai finalement trouvé une solution.
En fait, même s’il n’y avait que 2 ou 3 personnes qui auraient utilisées cette fonctionnalité, le code doit être fonctionnel à 100%.
Il faut donc tester tous les cas possibles de ton code et s’assurer qu’il est fonctionnel à 100% (voir 200%). Il est possible d’automatiser ces tests à l’aide de tests unitaires, fonctionnels (ou autres) qui testeront à ta place que ton code est opérationnel.
Penser que son code est parfait et que l’on sait tout faire
Savoir faire ne veux pas dire qu’on le fait correctement.
Tu peux en effet savoir faire pleins des choses, des choses qui fonctionnent mais qui ne suivent pas du tout les bonnes pratiques, les bons référentiels, le besoin du client, etc …
Lorsque l’on apprend à coder, le plus gros effort à faire est de changer les critères d’évaluation de son travail. Au début, on est satisfait lorsque l’on réalise une page web avec du code PHP à l’intérieur, qui va récupérer des données en base. Mais il faut se rendre compte qu’il y a encore du travail derrière pour améliorer ce code, le rendre propre, lisible, scalable, etc.
Le plus dur n’est pas de réaliser du code qui marche, ça c’est assez facile. Le plus dur c’est de réaliser du bon code, du code qui est lisible, performant, documenté, scalable, adapté au besoin, versionné, sécurisé et testé.
Il faut savoir prendre du temps pour refactoriser ton code. C’est-à-dire reprendre le code que tu as fait pour l’améliorer. Et à chaque fois se demander comment ce code pourrait être mieux et comment je pourrais m’améliorer par la suite.
Aujourd’hui encore, lorsque je code, j’essaye de me remettre en question, de bien réfléchir à mon code avant de l’écrire. Je pense au meilleur moyen de coder, de structurer mes fichiers pour que le code soit facilement maintenable, propre et scalable facilement.
Par exemple, si dans ton code, tu as 2 fois le même bout de code, qui fait la même chose, il faut que tu revois ton code et que tu l’améliore.
Pour les développeurs autodidactes, ce travail est encore plus dur à réaliser. En effet, ils apprennent par eux même sans personne pour leur dire si leur code est bien ou non.
Ne pas dormir
On a tous déjà vu dans les films ou séries le développeur code toute la nuit sans s’arrêter pour sortir un programme exceptionnel au lever du jour.
Mais dans la réalité c’est pas tout à fait la même chose.
Développer demande énormément de concentration et d’énergie. Il est difficile de coder durant des heures d’affiler.
Le corps humain a une quantité définie d’énergie au quotidien. Si tu l’as épuisé, il est très difficile de continuer à coder correctement.
Pendant la journée, je ressens bien cette fatigue. Le matin c’est le moment où je suis le plus productif. Je peux passer 2 ou 3 heures non-stop, hyper concentré, à produire du code.
Le début d’après-midi est un peu plus compliqué mais la concentration est toujours là.
Après une journée de code, le soir, je vois bien que je ne réfléchis plus aussi efficacement que le matin. Je ne suis pas capable de fournir la même qualité de travail qu’en début de matinée. J’ai besoin de repos pour repartir le lendemain et être productif.
J’ai déjà fait l’expérience de coder tard le soir. Le lendemain, lorsque j’ai repris mon code, je n’étais pas tout à fait satisfait de ce que j’avais fait. J’ai dû le refaire.
Tout le monde n’a pas les mêmes périodes de productivité. Pour certains ce sera le soir et pas le matin pour d’autre ce sera le début d’après-midi … Mais dans tous les cas, le corps a besoin de repos à un moment.
Il faut savoir décrocher de son ordinateur, arrêter de coder et aller se reposer pour avoir les idées claires et pouvoir reprendre à coder plus tard.
Les mauvaises habitudes des développeurs : ce qu’il faut retenir
Lorsque l’on débute dans le développement, on est souvent tout fou, on apprend pleins de choses, on test pleins de choses, on veut faire beaucoup de code. Coder, coder coder !
C’est très bien d’être motivé. Mais il faut faire attention aux habitudes que l’on prend à ce moment-là.
Les mauvaises habitudes sont difficiles à modifier. Comme on dit « les habitudes ont la vie dure ».
Prendre de mauvaises habitudes et ne pas s’en apercevoir peut-être problématique par la suite, surtout si l’on apprend en autodidacte (très compliqué de voir ces mauvaises habitudes) : pas de remise en question, être sûr de son code, réaliser du code non maintenable, copier-coller du code trouver sur internet, …
Bref les mauvaises habitudes sont nombreuses dans le développement et il faut y faire attention.
Dans cet article je t’ai listé celles que je considérais les plus « dangereuses » pour un développeur et surtout celles auxquelles tu dois vraiment faire attention.
