5 erreurs que commettent les développeurs

En 12 ans de développement sur des projets logiciels variés, j'ai eu l'occasion d'observer différentes façons de travailler parmi mes nombreux collègues.

J'ai été frappé de voir à quel point certaines pratiques en particulier étaient capables de saboter littéralement notre efficacité à produire intelligemment et rapidement du code, voire à faire aboutir des projets. Je dis "on" car faut pas croire, je fais aussi partie des gens qui commettent des erreurs. Encore aujourd'hui d'ailleurs.

Très honnêtement, je pense qu'on pourrait tenir un article de plus de 150 erreurs, mais aujourd'hui j'ai décidé de vous en expliquer 5 qui reviennent très souvent selon moi.

Bâcler la conception

J'ajoute un bout de code vite fait ici parce qu'on a pas le temps de niaiser sur des schémas.

En fait, vous avez 9 chances sur 10 d'écrire un code non optimal et donc créer de la dette technique qui sera plus coûteuse que si vous aviez pris le temps de réfléchir avant en prenant bien en compte tous les paramètres !

Non, vraiment ! Lâchez votre clavier, prenez un crayon (allez, un critérium, soyons modernes !), et réfléchissez : quelle est la meilleure solution pour y parvenir ? y'a-t-il un risque d'effets de bord ? est-ce que le code est bien organisé et efficace ? y'aurait-il moyen de faire mieux ?

Pensez aussi à en parler avec vos collègues : ils ont peut-être des points de vue utiles !

Voyez ça comme une partie d'échecs en fait : ayez toujours plusieurs coups d'avance. Voyez plus loin avant de prendre une direction !

Limiter une solution à ses connaissances techniques

Ah, ce widget, on l'a pas... Mais j'ai une idée : je vais plutôt afficher ces données avec cet autre widget parce que l'autre jour j'ai trouvé comment il marchait. C'est moins bien mais bon...

ou

Oui, en fait, on a décidé de plutôt faire comme ça parce que pour nous autres c'était plus pratique.

En mettant systématiquement l'intérêt des développeurs avant celui des utilisateurs, la qualité du produit sera altérée, et vous verrez qu'une sensation de demi-teinte, d'inachevé voire de sous-marque collera à la peau de votre soft en permanence.

Bien sûr, vous devez faire la part des choses : les tâches coûteuses qui apportent peu de valeur aux yeux du client ne mériteront peut-être pas qu'on s'y attarde plus que ça (quoique, ne sous-estimez jamais l'effet "waouh" d'une petite animation devant votre commercial).

Toutefois, gardez un minimum d'ambition ! Allez au bout des objectifs et de l'idée que vous vous faisiez du résultat final. N'hésitez pas à aller plus loin que ce que vous avez déjà fait.

D'un point de vue personnel, vous allez même trouver satisfaction à faire aboutir quelque chose de nouveau.

Complexifier inutilement son code

Moi je suis un expert dans cette techno, alors je me fais plaisir, je vais utiliser toutes les fonctionnalités existantes, combiner tous les symboles en une seule ligne, mettre des templates de partout, ça va être trop balaise, mes collègues vont êtres bluffés !

Eh bien non. Vos collègues vont surtout tirer une tronche de 3 pieds de long quand ils verront votre code, car il sera im-bi-table !

Et je vais même vous dire une chose : vous tirerez vous aussi la même tronche lorsqu'un an plus tard (parfois beaucoup plus) vous devrez revenir sur ce même code, et vous ne serez pas capable de comprendre ce que vous avez vous-même écrit !

Je ne suis pas en train de blâmer les efforts pour rendre un code super générique. Je dis qu'il y a un juste milieu à trouver. Dans beaucoup de cas, on peut arriver à un même résultat sans se compliquer inutilement la vie.

Léonard De Vinci a dit :

La simplicité est la sophistication suprême.

Vous voyez, c'est quand même pas Joe le stagiaire qui a écrit ça ! (enfin on l'aime bien Joe, mais il manque un peu.. d'expérience !)

Je pourrais écrire plusieurs articles entièrement dédiés à ce sujet, mais je vais essayer de résumer : Un bon code, c'est un code simple et lisible. Même si vous avez intérêt à profiter de tout ce que peut vous offrir votre langage ou vos frameworks, vous devez le faire avec conscience. Car plus votre code sera simple et concis, plus il sera efficace et facile à maintenir !

Commiter du code non testé ou pas assez testé

Ici, je ne parle même pas de tests unitaires ou d'intégration (que je ne peux que vous conseiller). Je parle de développeurs qui martèlent leur clavier comme Flash, et qui commitent fièrement leur code en 30 minutes car "en vérifiant vite fait, ça a l'air bon".

J'ai vu cette situation plusieurs fois. J'ai même vu le même bug revenir 4 fois dans 4 sprints différents. Et à chaque sprint on était persuadés que le bug avait été corrigé...

Le temps perdu est incroyable : on termine une phase de dev en pensant avoir passé un cap, alors que non seulement on ne l'a pas passé, mais on a introduit des régressions !

Il va alors falloir attendre que quelqu'un se rende compte d'un bug, le remonte, puis il faudra retrouver la cause initiale parmi des centaines de commits, créer une tâche corrective, puis vient enfin le jour de la correction proprement dite... mais le travail est effectué de la même manière par la même personne, et Re-Belotte !

Nous avons donc perdu de nombreuses semaines, alors qu'il aurait suffit la première fois de passer ne serait-ce que 2 jours de plus à tester plus largement et apporter la correction adéquate.

Donc vous l'aurez compris : soyez votre propre testeur, et soyez garants de la qualité de votre code ! Vous avancerez plus sûrement !

Se reposer sur ses acquis

Je veux bien mais je ne connais que le C++ alors on développe tout en C++, ou alors c'est pas moi qui m'en occupe.

Le risque avec cette philosophie, c'est de s'enfermer dans une boîte bien hermétique. Et non seulement vous allez limiter vos compétences, mais vous allez aussi créer une frontière entre vous et vos collègues qui travaillent sur d'autres technos.

Alors, on va pas se mentir : quand on a commencé à apprendre notre premier langage de programmation, on a tous réagi un peu comme ça. Sans doute parce qu'au vu des efforts qu'on avait dû fournir pour maitriser ce langage, on n'avait pas envie de "tout recommencer". Oui, j'ai mis des guillemets, c'était voulu. Parce que c'est uniquement une impression : vous n'allez pas tout recommencer.

S'intéresser à d'autres langages et creuser un peu plus les sujets techniques que vous ne connaissez pas va non seulement booster vos compétences, vous ouvrir l'esprit à d'autres manières de faire, mais cela se fera de plus en plus facilement !

Les langages ont beaucoup de points communs, certains sujets peuvent se recroiser, et le savoir sur internet n'a jamais été aussi riche ! Alors prenez régulièrement du temps, plusieurs fois par semaine, pour vous enrichir.

Et pour ça, le blog de Younup est un bon point de départ ! :)