Legacy

Ces vieux projets dont nous ne connaissons pas l’origine exacte, cette structure qui est fragile, ces lignes de code qui travaille sans filet, ces variables qui sont précédés du mot global en haut, ou pas, d’une function dans un fichier nommé utils2.new.inc dont tu sais que Pierre, Jean et Jacques l’ont modifié en décembre 2005, juste avant Noël, pour commencer à utiliser mysqli sans même avoir git d’installé. Un jour ou l’autre, nous finissons tous par travailler dans l’un de ces projets. C’est ici que nous voyons plusieurs types de programmeur qui ont des mentalités très différentes dans leurs approches.

Burn it to the ground!

Ce serait un mensonge de dire que ce n’est pas la première idée qui me vient en tête lorsque je rencontre ce type de projet, le jeter dans les flames de l’enfer pour bâtir, encore, une “nouvelle merveille”.

Des fois, c’est une bonne solution, lorsque nous avons les ressources nécessaires et une excellente compréhension de l’application. Armé de gens compétents, de patience et de détermination, il faut faire attention de ne pas se laisser déjouer par des heures de tombée qui nous force à réaliser des “copier/coller” de ce que nous voulons détruire. Juste ça, c’est un grand défi, si ce n’est le plus grand défi.

Si c’est la voix que vous voulez suivre, allez-y. Même si c’est la première idée qui me vient en voyant ce type de projet, ce n’est probablement pas le chemin que je vais prendre.

legacy it like you don’t care

J’ai déjà passé par là, je l’avoue. Lorsque je voyais du code que je considérai comme étant legacy, je traitais tout ce qui l’entourait comme une poubelle sans importance. Aucun respect pour le passé de tous ceux qui ont travaillé pour en arriver là où le code se trouve actuellement, soit un environnement de production produisant suffisamment de revenu pour engager quelqu’un pour travailler dessus.

Avec du recul, je suis capable de dire que je n’ai pas toujours su donner le respect que se devait ces applications.

La meilleure explication de ce qui se passe que j’ai eu la chance de lire est celle d’Andrew Hunt.

Despite the best laid plans and the best people, a project can still experience ruin and decay during its lifetime. Yet there are other projects that, despite enormous difficulties and constant setbacks, successfully fight nature’s tendency toward disorder and manage to come out pretty well. What makes the difference? In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict. A broken window. One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality. The “Broken Window Theory” has inspired police departments in New York and other major cities to crack down on the small stuff in order to keep out the big stuff. It works: keeping on top of broken windows, graffiti, and other small infractions has reduced the serious crime level.

― Andrew Hunt, The Pragmatic Programmer: From Journeyman to Master

Certain vont passer leur vie avec cette mentalité et d’autre vont maturer.

I’m one with legacy

Il y a aussi ceux qui aiment cette version de l’application, qui ne la considère pas comme legacy et ne voit pas les problèmes qui y sont rattachés. Pour eux la solution est le temps, le temps passé à debugger, le temps passé à développer, le temps pour réaliser des modifications.

Je leur lève mon chapeau, car avec l’expérience qu’ils ont dans seulement cette application, ils ont généralement la force mentale de connaitre cette application de fond en comble et ce n’est pas une mince affaire.

Pour eux, le statu quo est le meilleur état d’être, car il ne demande ni d’effort de changement, ni d’effort d’apprentissage. Si rien ne change pour eux, tout restera pareil et ils pourront continuer à vaguer à leur occupation en défendant le code tel qu’il est actuellement.

Personnellement, j’ai du respect pour eux, mais seulement pour le temps passé à apprendre toutes les possibilités de l’application, leur force de “mapping” mentale. Malheureusement, cette force pourrait être mise à un meilleur usage.

The phoenix will rise again!

Une autre approche est de modifier l’application pour répondre à nos besoins. En tant que membre de l’équipe de développement notre besoin est d’avoir une application plus facilement modifiable, que nous apprécions travailler dessus. Indirectement, nous sommes à la recherche du bonheur lorsque nous lisons et écrivons.

Il n’y a rien d’impossible.

Lorsque nous voulons réaliser quelque chose de plus grand que soit, il faut diviser les tâches à accomplir dans le but d’avoir des petites modifications facilement réalisables. Si nous pennons de trop grande bouchés, nous n’y arriverons pas.

Comme toute sorte de restructuration, il faut avoir un plan. Qu’il soit réalisé de toutes pièces pour répondre à nos besoins, qu’il soit trouvé sur Internet et adopté ou encore qu’il soit la modification d’un plan existant n’est pas ce qu’il y a de plus important. Ce qui est nécessaire, c’est d’en avoir un.

Une fois que nous en avons un, il faut s’assurer qu’il répond à nos besoins! Ok, j’aurais pu en parler avant. Je suggère de prendre connaissance de ce livre Modernizing Legacy Applications In PHP. Cet ouvrage est un “cookbook” pour moderniser une application legacy, en suivant toutes les étapes, vous aurez une application testable et répondant à de bon standard de programmation.