Il était une fois une vieille base de code…

Je m’en souviens comme si c’était hier.

La joie d’avoir décroché un nouveau job, mieux payé et plus prometteur que l’ancien, a vite été balayée dès lors que j’ai pour la première fois regardé l’Enfer dans les yeux, par l’intermédiaire d’Eclipse.

Du code PHP vieux d’une décennie, sans structure, qui semblait adresser un énorme doigt d’honneur à mes convictions les plus profondes ; des lignes et des lignes de HTML, CSS et JavaScript torturés, déformés, forcés à faire des choses qu’ils n’auraient osé concevoir dans leurs pires cauchemars — ou les miens. Bien sûr, certains bouts de code étaient mieux que d’autres, mais ils résultaient simplement du dégoût passager d’un développeur paresseux, qui avait fait sa tambouille dans son coin sans prendre l’initiative de la communiquer à ses pairs pour la standardiser, ou de l’utiliser pour rendre un peu moins immonde le code préexistant.

En un mot comme en cent, j’étais devant ce qu’on appelle communément du « code legacy » : l’ennemi public numéro un, celui qu’il faut abattre à vue et qui est considéré comme une entité démoniaque par le commun des mortels, qui ne se privent pas d’en rire — au début — ou d’enrager — un peu plus tard, la lassitude aidant.

Et puis, certaines choses ont changé. La refonte tant attendue est arrivée. Oh, bien sûr, elle allait être longue ; mais sa simple existence semblait redonner le sourire aux développeurs, remettre un peu d’espoir au fond de leurs cœurs. Des experts — dont certains vraiment excellents — sont arrivés, et ont tiré l’open space vers le haut en instaurant des best practices — les vraies, celles qu’on respecte, celles qui sont surveillées par de l’analyse statique et des tests automatisés. Installer le poste de travail d’un nouvel arrivant demandait désormais deux heures, contre deux jours jusqu’alors. L’Orienté Objet (avec deux grands O), les pull requests, les containers Docker, l’intégration continue sont devenus une part de notre vocabulaire et de notre quotidien. Nous avons adopté une démarche Agile, parce que c’était hype, et il faut reconnaître que ça fonctionnait plutôt bien.

L’innovation a, comme de raison, apporté son lot de problèmes — manque de recul ou d’expérience, dans la plupart des cas. Un exemple frappant me concerne directement : je suis celui qui a proposé l’outil retenu pour développer l’IHM d’une des nouvelles applications back office, à savoir React. J’ai fait cette proposition après avoir découvert l’outil de mon côté, le trouvant pertinent quant au besoin décrit (en deux mots, un formulaire un tant soit peu complexe communiquant en AJAX avec le serveur). Le début du projet a été paradisiaque : j’écrivais le gros du JavaScript, étant le plus à l’aise avec ce langage, pendant que le développement côté PHP était supervisé par un de mes collègues. Les itérations Scrum avaient été bien conçues et découpaient le besoin en petites unités de valeur. Tout semblait donc aller pour le mieux dans le meilleur des mondes, mais ce rythme de production modéré nous a bandé les yeux.

En effet, il nous a empêché de voir qu’à mesure que l’application se complexifiait, les composants React devenaient de plus en plus gros, et de moins en moins maintenables, portant une responsabilité bien trop grande. Une meilleure solution aurait été de les laisser gérer la couche de présentation uniquement, et de placer le reste de la logique (métier comme applicative) hors de React, une architecture bien plus apte à « scaler », comme on dit aujourd’hui. Ayant moins de temps à consacrer à ce projet, et soucieux d’effectuer un transfert de compétences efficace, j’ai donné de mon temps pour présenter React à l’équipe lors d’un atelier, rédiger des guidelines pour le développement JavaScript et introduire les tests unitaires dans ce langage.

Cela a hélas été insuffisant. Même si le développement sur l’application a pu être repris en main par mes collègues, ni eux ni moi n’avions les clés nécessaires à la refonte architecturale du code. Nous avons alors entendu parler de Flux, qui semblait parfaitement correspondre à nos besoins. J’ai pris le temps de réécrire en utilisant Flux le code concernant un des éléments de l’interface, et ai été conquis par cette solution. Je prévoyais déjà de poursuivre l’effort en équipe afin de réécrire la totalité de l’application de la même manière.

Nous étions pris par le temps. Nous ne l’avons jamais fait, et je sais que nul ne le fera jamais. Quelle leçon tirer de cette anecdote du vrai monde ? Je pense qu’il y en a plusieurs.

Premièrement, sachez que de la même manière qu’on est toujours le con de quelqu’un, votre code tout shiny sera toujours le legacy d’un autre développeur. Le code de quelqu’un d’autre est toujours difficile à comprendre et donne des ulcères aux plus tatillons d’entre nous, et ces désagréments sont proportionnels à l’âge de ce code. C’est une fatalité. Instaurer toutes les best practices de l’Univers ne suffira pas à lui faire atteindre l’état utopique de sembler avoir été écrit par une seule personne. On peut simplement faire de son mieux, en ne se pensant jamais à l’abri du temps qui passe — à la fin, c’est toujours lui qui gagne.

Deuxièmement, si votre job actuel ne vous satisfait pas totalement, soyez acteur du changement. Proposez de mettre en place des choses pour améliorer la vie de tout le monde, si vous en avez le temps. Dans mon cas, la qualité globale du code JavaScript a tout de même augmenté suite à mes actions, à son rythme. C’est doublement bon pour vous : vous en bénéficierez aussi, et ça sera un sacré bon point pour votre CV. C’est bien plus facile de s’y prendre à plusieurs, mais si vous êtes le seul développeur compétent, passionné, investi (rayez les mentions inutiles) dans ce job et que vous en souffrez, il est temps d’en changer. C’est une voie sans issue.

Enfin, retenez que l’innovation, c’est bien ; en abuser, ça craint. Brûler les étapes fait s’accumuler la dette technique : devoir découvrir de nouvelles choses empêche de se perfectionner sur les précédentes. Évoluer est toutefois vital : Darwin avait aussi raison au sujet des entreprises, dans le sens où celles qui survivent sont celles qui s’adaptent le mieux à leur environnement, sans cesse changeant dans le cas du développement. Tâchez de fixer un juste milieu adapté à la taille de l’équipe et à ses capacités, afin de maximiser à la fois la satisfaction des développeurs et la qualité du produit fini.

Je vous souhaite de bonnes fêtes, et bon code !