Le code legacy, vous savez tous ce que c'est. Vous arrivez sur un projet, vous
regardez le code et vous faites une grimace.
Je suis sur un projet un peu comme ça. Toutefois, comme je suis joueur, je me
dis : "chouette, il y a pleins d'opportunités d'amélioration, on va bien se marrer !".
Alors sur mes premières interventions, j'ai essayé discrètement de remettre
le code à ma sauce, factoriser un peu tout ça pour faciliter la maintenance.
C'est alors qu'arrive une demande d'évolution nous proposant de réaliser un
tout nouveau module de l'application. C'était le début de l'été, on était à
l'aise... il y avait 2 packages PLSQL à coder. J'ai dit à mon stagiaire d'en
coder un et j'ai gardé le second.
J'ai réutilisé la structure du code existant -c'est une exigence du client-
tout en tentant de l'améliorer : en réduisant la redondance, en essayant de
faire un maximum de fonctions pour que cela reste lisible.
J'ai également écrit les 2 shells de lancement, en poussant les fonctions
communes aux deux scripts dans un troisième fichier. Ça marchait bien,
j'étais vraiment content du boulot qu'on avait effectué et j'étais persuadé
que le client allait être satisfait.
Après l'été, le module entre en VABF. Premiers griefs : qu'est-ce que vous avez
fait dans ce shell ? On y comprend rien, il y a des fonctions partout. En plus
vous avez mis les fonctions communes dans un troisième fichier ! C'est trop en
rupture avec l'existant, ce serait pas mal que vous nous relivriez, après avoir
recopié les fonctions communes dans chacun des deux scripts pour ne pas sourcer
de script externe. Au passage, une remarque en off : c'est pas si mal de factoriser, mais il
faudrait le faire pour toute l'application. Ben voyons, gratos, c'est bien
ça ?
Soupir, respiration, je modifie, je relivre et je me dis que c'est bon...
Peu de temps après seconde remarque : le code du package PLSQL que j'avais
rédigé n'est lui non plus pas conforme. Le style de codage est trop en rupture,
ce qui rend le code non maintenable (sic). Pluies d'anomalies, KPI en berne,
palabre avec le client. On refait le tout.
Il y avait une vraie ano fonctionnelle relativement minime, j'ai quand même
réécrit tout mon code... et ravalé ma fierté.
Essayons de comprendre le client. Celui-ci n'avait pas de TMA depuis plusieurs moi
et a dû prendre en charge évolutions et corrections sans équipe de développeurs
SQL chevronnés. Ceci nécessite de son point de vue :
En plus, mon code n'était pas cohérent avec celui de mon stagiaire... code qui au
passage est considéré comme meilleur que le mien (Nassim, si tu nous lis ;-)) !
Bref, une bonne douche froide et un suppo d'humilité pour moi. Je me remets en
question, j'hésite à démarrer une thérapie... Je me rappelle d'un passage du
livre Pragmatic Programmer, celui qui parle du good enough software... et de boiled frog.
En théorie, les anomalies du client devraient être liées à des tests
fonctionnels. Le comportement de l'application n'était pas celui attendu. Dans
mon cas, c'était effectivement le cas, mais je l'ai découvert moi-même par la
suite. La vraie ano que j'ai eu est "le code est complètement faux".
Dans les faits, bah, on retouche le code à la demande pour que le client soit
satisfait, assuré qu'il a une compréhension globale de ce qui est réalisé et
accepte la livraison. On promet qu'on ne prendra plus les mêmes libertés par la
suite. C'est la joie de la sous traitance.
À titre personnel, c'est un peu dur pour moi car je réfléchis toujours
au façon d'améliorer un système (c'est mon côté geek... ah pardon, lean), d'aller chercher une
meilleure maintenabilité pour faciliter l'évolutivité (c'est une belle phrase
ça, ça ferait un bon tweet). Par exemple, j'imaginais mettre en place un framework pour la
partie PHP. Une telle idée me fait gentiment sourire aujourd'hui.
Au final, la situation s'améliore pour moi : à l'heure actuelle je ne code
quasiment plus pour cette application.
Dernier mot sur l'histoire de la boiled frog pour ceux qui n'ont pas lu le livre.
Si vous voulez cuire une grenouille en la plongeant dans une casserole d'eau
bouillante, celle-ci sautera systématiquement hors de la casserole. Si
toutefois, vous la mettez dans une casserole d'eau froide que vous portez à
ébullition, la grenouille restera dans la casserole car elle ne comprend pas
qu'elle est en train de se faire ébouillanter vivante !
Si vous bossez avec un client (une MOE) et que vous voulez organiser une évolution en
rupture dans un système, rappelez vous que vos solutions ne seront jamais
les bonnes tant que votre client ne se les ait pas appropriées. Faites en sorte
que vos propositions d'évolution deviennent celles de votre client, que ce soit
lui qui les porte. À vous d'être suffisamment malin... tout en restant
honnête à 100%, cela va se soi.
