Blog: legacy code

Le terrible Legacy Code? Vous le devez à l’un de ces types!

Vous avez un jour entamé une mission chez un nouveau donneur d'ordre et le code que vous avez vu vous a directement donné des démangeaisons. Tellement de démangeaisons que vous avez directement eu envie de tout réécrire ou peut-être même, de rentrer chez vous ? Le Legacy Code est inévitable et il arrive souvent que des développeurs aient travaillé à un projet avant vous. Mais parfois, vous auriez bien deux mots à dire à votre prédécesseur…

Le Legacy Code n’est évidemment pas toujours mauvais

Généralement, l'ancien travail s'intègre très bien dans le nouveau et la majeure partie du Legacy Code n’est donc pas tout à fait mauvaise.  Même s’il tourne sur un ancien cadre, les entreprises non-tech investissent beaucoup dans les logiciels et n’ont pas envie de les mettre à jour chaque année si ce n’est pas nécessaire.

Dès lors, quand le Legacy Code pose-t-il vraiment problème?

Nous avons posé la question à nos développeurs et nous en avons conclu qu’il existe 5 types qui ont des pratiques qui vous amènent à vous arracher les cheveux. Si vous vous reconnaissez dans l’un de ces types, vous pouvez avoir honte. Si vous reconnaissez un collègue dans l'un de ces types, n’hésitez pas à vous venger de manière créative. Notre suggestion ? Des oursons Haribo sans sucre... 

Le spécialiste en missiles

Le spécialiste en missiles n’est pas l’un ou l'autre surdoué qui, grâce à sa grande intelligence, a inventé un code un peu trop compliqué. Non, c’est le développeur qui solutionne de petits problèmes en tirant un missile dessus. Vous en connaissez certainement des collègues qui préfèrent ne pas utiliser des répertoires et des cadres standard – non, ils écrivent tout eux-mêmes !

Et quand ils partent ? Eh bien, c’est à vous de deviner comment tout cela fonctionne. Et le stagiaire ou le nouveau collaborateur ? Il doit se mettre au courant de manière intensive car le seul support dont il dispose, c’est l’homme (ou la femme) qui a construit le système.

L'intoxiqué de la tech

Nous connaissons tous des collègues (ou pire encore, des managers) qui sont toujours absolument fans des tout derniers développements. Ce nouveau cadre original ou cette tout autre façon de travailler, c’est leur seul et unique sujet de conversation. Et ils ne sont pas seulement fans, ils veulent absolument les introduire ou les utiliser le plus rapidement possible.

Soupir, il s’agit encore de l’un ou l'autre cadre obscur que vous devez utiliser en toute hâte. Et dans 5 ans, essayez d’encore trouver des développeurs pour ceux-ci…

Le stagiaire qui se noie

Il arrive parfois que les entreprises soient trop avares pour faire appel au senior dont elles ont besoin. Elles font donc appel à un stagiaire, vu que « il peut quand même aussi programmer ? » Le stagiaire fait de son mieux, bien sûr, mais un code qui dépend de solutions pêchées sur Google et des work arounds ne sont en général pas la meilleure solution pour le long terme.

L’extincteur

Lorsque vous voulez résoudre rapidement quelque chose, vous ne trouvez souvent la solution que pour ce moment donné. Le véritable problème n’est pas abordé et vous vous êtes contenté d'éteindre un petit incendie. Songez à une app dans laquelle un nombre maximum d'utilisateurs a été programmé. Dès que vous avez atteint ce plafond, vous pouvez augmenter le nombre maximum d'utilisateurs (éteindre l’incendie) ou bien chercher une solution durable pour ne pas être confronté au même problème lors de chaque pic de croissance. Lorsqu'un extincteur s’occupe trop longtemps d'un projet, vous vous retrouvez avec un Legacy Code rempli de solutions rapides et de constructions à réaliser plus tard. Malheureusement, ce « plus tard » n’est jamais arrivé et c’est à vous de trouver la solution maintenant.

Le sprinter prétentieux

Les deux derniers types sont des pollueurs de code principalement en raison des circonstances mais le sprinter prétentieux a pour effet que des équipes entières se retrouvent obligées d'écrire de mauvais codes. Quand le manager lui demande de faire quelque chose, il répond que ce sera réglé en deux jours. DEUX JOURS ?! Dans ce cas, le code sera peut-être terminé, mais alors, sans debug ni test. Maintenant que le manager sait que c’est possible en deux jours, il veut évidemment l'avoir dans les deux jours. Vous vous précipitez dès lors tous pour réaliser le plan du sprinter prétentieux. Vous pensez que « ça s'arrangera plus tard », et c’est ainsi que vous devenez aussi un extincteur.

Que pouvons-nous en conclure ? Qu’en raison du manque de temps ou d'attentes irréalistes, il peut arriver à tout le monde de tisser une toile de codes problématiques. Avant d'imaginer vos représailles, réfléchissez aussi à ce que vous pouvez faire vous-même pour prévenir ces problèmes.