Mauvais code, bon code

Après une longue pause, j'ai récemment retravaillé sur la code base d'Ayadn, ma première “vraie” application avec des utilisateurs et tout et tout, créée début 2014.

Ca a été amusant - et traumatisant - de redécouvrir du code que je considère aujourd'hui comme médiocre.

Et pourtant, cette app fonctionne sans bug connu et satisfait ses utilisateurs, donc quoi… c'est du bon code mais c'est pas du bon code ?

Hmm…

Tout dépend de comment on regarde la situation.

Si l'on considère que l'unique but du code est de faire fonctionner l'application en donnant entière satisfaction à l'utilisateur, alors la code base d'Ayadn est carrément très bonne !

Et fin de la discussion. :p

Mais si l'on considère que la condition précédente est en réalité un pré-requis et que le code doit également être :

alors la code base d'Ayadn est complètement pourrie. :p

Donc, le premier point de vue est simpliste mais après tout, pour un débutant, inutile d'aller plus loin. Hey, j'ai fait un truc et ça marche ! La magie est là - le reste, on verra plus tard. On a incarné une idée dans une machine, on va aller célébrer, là, pas pleurer sur la qualité.

En revanche pour un amateur éclairé / junior pro, la seconde option est obligatoire. Tout dessinateur sait dessiner. Tout chanteur sait chanter (hmm). Tout développeur doit savoir développer. Là n'est pas la fin du voyage : c'est le début.

Il faut ensuite apprendre à être, donc, efficace, lisible, élégant, etc.

Efficace car tout chimpanzé, avec assez de temps et de ressources, peut finir par coder quelque chose qui fonctionne. Pas besoin d'être intelligent pour coder du Rube-Goldberg. Il y a même des applications comme ça sur le marché, on les reconnaît assez vite. Vas-y, mets-donc à genoux une machine de 2016 pour afficher trois images. Cool.

En revanche créer du code qui va vite, du code qui économise la batterie, du code qui ne consomme pas de la bande passante inutilement, du code qui s'adapte aux changements d'environnement, ça - ça c'est difficile.

Lisible et élégant, car quand votre code circule, que ce soit entre collègues ou dans le public, vous voulez qu'il puisse être lu et compris sans difficulté. Sinon, il sera tout simplement ignoré. Les obscurantistes ont perdu la bataille depuis longtemps déjà.

Comme un texte en prose, si le code est inutilement ampoulé ou au contraire se veut si malin qu'il en devient bien trop élliptique, c'est sans intérêt aucun.

Et même pour un développeur solitaire : après plusieurs mois - ou années ! - relire votre propre code n'est pas si différent de lire le code de quelqu'un d'autre. On se demande bien quel idiot a pu créer un code si moch- oh fuck, c'est moi… ahah.

Et c'est bien ce que j'ai expérimenté en revenant sur Ayadn.

Quelques fonctions un peu trop intelligentes qui deviennent très difficiles à modifier et à tester (n'est pas Carmack ou Knuth qui veut); quelques autres vraiment trop laides, inefficaces et redondantes (faut pas coder la nuit); des bouts qui trainent ça et là et qui ne servent à rien (du code fantôme, symptomatique des modifications faites au fil du temps); une architecture globale qui se situe quelque part entre le plat de lasagnes et le plat de spaghetti, avec des portails de téléportation non documentés en guise de sauce…

J'ai donc fait, en plus de ce que j'avais prévu, du ménage dans tout ça.

Pas autant que j'aurais souhaité - notamment je n'ai pas changé l'architecture, ça aurait été trop de travail et cette app est trop niche pour y investir du temps dorénavant - mais c'est tout de même devenu plus lisible et efficace.

Pour l'élégance, on repassera : je laisse en place les lasagnes et autres scènes de guerre, disons que c'est un témoignage historique pour moi, et une occasion de se marrer pour ceux qui liront ces bouts de code… hé, pitié pour les débutants, ho. Il faut bien commencer quelque part. Même pas honte, tiens ! :D

Auteur: Eric Dejonckheere