Code legacy : comment utiliser un code legacy de façon optimale

Le code source constitue le cœur d’un logiciel. La fonc­tion­na­lité du programme et les fonc­tion­na­li­tés dis­po­nibles dépendent des ins­truc­tions et des commandes en­re­gis­trées dans ce code. Les pro­gram­meurs éditent et en­tre­tien­nent ce code ré­gu­liè­re­ment afin d’offrir aux uti­li­sa­teurs la meilleure con­vi­via­lité possible. Chaque mo­di­fi­ca­tion apportée au code peut provoquer des erreurs lo­gi­cielles ou mettre en péril la fonc­tion­na­lité du programme.

Pour les dé­ve­lop­peurs et les pro­gram­meurs, la main­te­nance et la mise à jour du logiciel sont toujours par­ti­cu­liè­re­ment pro­blé­ma­tiques lorsqu’ils doivent tra­vail­ler avec un code qu’ils n’ont pas écrit per­son­nel­le­ment ou qui a été écrit pour des systèmes d’ex­ploi­ta­tion obsolètes n’étant plus supportés dans des versions tout aussi obsolètes du langage de pro­gram­ma­tion sous-jacent. Dans cet article, vous dé­cou­vri­rez ce que recouvre exac­te­ment le code legacy, et comment le traiter au mieux.

Le terme « code legacy » est utilisé en in­for­ma­tique et peut être traduit par « ancien code » ou « code hérité ». Il s’agit d’un code ancien qui ne fait gé­né­ra­le­ment plus l’objet d’un dé­ve­lop­pe­ment actif. À certains égards, le code legacy est le contraire du clean code qui est com­pré­hen­sible de façon intuitive, par­ti­cu­liè­re­ment simple à en­tre­te­nir et fa­ci­le­ment adaptable. Le code legacy est un code plus vo­lu­mi­neux, répétitif et dé­sor­donné, pouvant entraîner de nombreux problèmes. La sig­ni­fi­ca­tion accordée à ce terme dépend fortement du point de vue du dé­ve­lop­peur et de la situation concernée. En principe, le code legacy se distingue toutefois par les aspects suivants :

• Le code n’est plus entretenu pas les dé­ve­lop­peurs initiaux.
• À l’origine, le code a été écrit pour des systèmes d’ex­ploi­ta­tion qui ne sont plus supportés.
• Le code ne permet pas la réa­li­sa­tion de tests au­to­ma­ti­sés.

Pourquoi le code legacy est-il utilisé s’il présente autant d’in­con­vé­nients ? Tout sim­ple­ment parce qu’il n’est pas toujours possible de l’éviter : au cours d’un projet, il n’est pas rare qu’un nouveau pro­gram­meur prenne en charge la main­te­nance et le dé­ve­lop­pe­ment du code. Alors que le dé­ve­lop­peur initial com­pre­nait le code in­tui­ti­ve­ment dans la plupart des cas, les nouveaux membres de l’équipe doivent tout d’abord acquérir cette com­pré­hen­sion. Dans ce cadre, il se peut qu’ils ignorent ou ne com­pren­nent pas par­fai­te­ment des parties du code.

Lorsque sur de nom­breuses années, un code est entretenu, amélioré et édité de toute autre façon par de nombreux dé­ve­lop­peurs, il peut, au fil du temps, devenir un véritable patchwork toujours plus difficile à com­prendre et à modifier. Le problème est qu’à partir d’un certain point, les mises à jour ou les mo­di­fi­ca­tions né­ces­saires ne peuvent plus être réalisées lorsque plus personne ne comprend le code et son effet.

Autre in­con­vé­nient du code legacy : il est im­pos­sible de réaliser les tests de ré­gres­sion, c’est-à-dire les tests au­to­ma­ti­sés, en raison de la densité, de la diversité et de l’in­com­mo­dité de la pro­gram­ma­tion. Les dé­ve­lop­peurs devant tra­vail­ler avec du code legacy doivent donc procéder à des tests manuels nettement plus con­sé­quents. Les erreurs sont ainsi plus dif­fi­ciles à corriger et les mises à jour sont plus dif­fi­ciles à mettre en œuvre.

Les dé­ve­lop­peurs n’ap­pré­cient guère devoir tra­vail­ler sur du code legacy, et ce pour dif­fé­rentes raisons. L’un des prin­ci­paux problèmes de ce code est qu’il rend im­pos­sible la réa­li­sa­tion de tests au­to­ma­ti­sés pour détecter les bugs et les erreurs. Par con­sé­quent, que peuvent faire les dé­ve­lop­peurs lorsqu’ils sont sou­dai­ne­ment con­fron­tés à du code legacy dans le cadre d’un nouveau projet ?

La meilleure solution est sans conteste le re­fac­to­ring (en français « refonte »). Cette approche de dé­ve­lop­pe­ment consiste à res­truc­tu­rer le code sans modifier sa fonction initiale. Toutefois, avant de pouvoir procéder à la refonte, les pro­gram­meurs doivent tout d’abord com­prendre à quoi servent les dif­fé­rents éléments du code. Par ailleurs, l’ensemble des fonc­tion­na­li­tés doivent être sé­cu­ri­sées par des tests.

On procède uni­que­ment à la refonte effective lorsqu’il est clai­re­ment établi que le code fonc­tionne. Dans ce cadre, le code est optimisé fragment par fragment en sup­pri­mant et en réé­cri­vant les parties de code su­per­flues, en sim­pli­fiant et en re­grou­pant les classes de code et les variables et en ajustant et en réé­cri­vant les méthodes de commande. En dé­fi­ni­tive, une refonte s’apparente à une révision générale du code legacy. À terme, on obtient un code in­tel­li­gible, facile à en­tre­te­nir et rapide à adapter.