Le progr\u00e8s propulse la technologie vers l’avant. Mais le progr\u00e8s a aussi un co\u00fbt : en ajoutant de nouvelles capacit\u00e9s et fonctionnalit\u00e9s, la communaut\u00e9 des d\u00e9veloppeurs ajuste constamment les \u00e9l\u00e9ments de base. Cela inclut les langages fondamentaux utilis\u00e9s pour coder les solutions technologiques.<\/p>\n
Lorsque les \u00e9l\u00e9ments constitutifs changent, le code derri\u00e8re la solution technologique doit \u00e9galement changer. C’est un exercice difficile et chronophage qui \u00e9puise les ressources. Et s’il y avait une alternative ?<\/p>\n
Le probl\u00e8me\u00a0: lire le code que quelqu’un d’autre a \u00e9crit<\/h2>\n
Prenons du recul et examinons l’un des d\u00e9fis fondamentaux du d\u00e9veloppement : \u00e9diter le code de quelqu’un d’autre. L’\u00e9dition du code que vous venez d’\u00e9crire, ou que vous avez \u00e9crit il y a quelques semaines, est tr\u00e8s bien. Mais \u00e9diter votre propre code \u00e9crit il y a des ann\u00e9es – sans parler du code de quelqu’un d’autre – c’est une autre histoire.<\/p>\n
Les r\u00e8gles de style de code internes peuvent aider, mais il existe toujours des conventions de d\u00e9nomination \u00e9tranges pour les variables et les fonctions, ou des choix inhabituels pour les algorithmes. On peut dire que la capacit\u00e9 d’un programmeur \u00e0 lire le code est une comp\u00e9tence cl\u00e9 – mais c’est difficile pour tout le monde.<\/p>\n
Les d\u00e9veloppeurs appellent le processus d’\u00e9dition de l’ancien code “refactoring” et c’est un processus qui introduit g\u00e9n\u00e9ralement de nouveaux bogues ou probl\u00e8mes de performances. C’est pourquoi, revenir en arri\u00e8re et \u00e9diter l’ancien code, eh bien – c’est la derni\u00e8re chose que la plupart des \u00e9quipes de d\u00e9veloppement veulent faire, en particulier lorsque la base de code existante fonctionne de mani\u00e8re stable et fait son travail.<\/p>\n
C’est un vrai casse-t\u00eate, mais parfois il n’y a pas d’alternative<\/h2>\n
La refactorisation est quelque chose que chaque d\u00e9veloppeur veut \u00e9viter le plus longtemps possible car cela peut sembler une perte de temps. N\u00e9anmoins, les d\u00e9veloppeurs doivent refactoriser de temps en temps pour diverses raisons, et l’une des raisons les plus courantes est due aux changements dans les blocs de construction des d\u00e9veloppeurs.<\/p>\n
Cela inclut les changements apport\u00e9s aux langages de programmation utilis\u00e9s pour cr\u00e9er des logiciels, qui \u00e9voluent in\u00e9vitablement avec le temps. Les nouvelles versions d’un langage d\u00e9sapprouvent souvent les anciennes fa\u00e7ons de faire tout en introduisant de nouvelles fonctionnalit\u00e9s. Si les d\u00e9veloppeurs n’adoptent pas la nouvelle version linguistique, ils sont exclus du nouvel ensemble de fonctionnalit\u00e9s. <\/p>\n
Cependant, le code existant doit g\u00e9n\u00e9ralement \u00eatre ajust\u00e9 pour fonctionner sur la nouvelle version du langage, ce qui implique un processus de refactorisation. Et c’est l\u00e0 l’\u00e9nigme\u00a0: pour adopter la nouvelle version plus avanc\u00e9e d’un langage, les d\u00e9veloppeurs doivent refactoriser, et en cours de route, ils d\u00e9penseront \u00e9norm\u00e9ment d’efforts – et casseront toutes sortes de choses inattendues, introduisant de nouveaux bogues dans une application qui fonctionnait tr\u00e8s bien.<\/p>\n
Pire encore, la refactorisation seule ne vous donne pas les avantages de la nouvelle version linguistique, vous devez plut\u00f4t red\u00e9velopper votre base de code pour tirer parti des am\u00e9liorations. Sinon, malgr\u00e9 l’ajustement du code pour s’adapter \u00e0 la nouvelle version linguistique, vous \u00eates exactement l\u00e0 o\u00f9 vous \u00e9tiez\u00a0: une base de code fonctionnant sur une nouvelle version linguistique, mais sans nouvelles fonctionnalit\u00e9s. <\/p>\n
Les fournisseurs laissent g\u00e9n\u00e9ralement les utilisateurs finaux s’en occuper<\/h2>\n
Cela peut sembler \u00eatre un exercice inutile, mais avec l’\u00e9volution constante de la technologie, il n’y a souvent que peu de choix en la mati\u00e8re, vos partenaires technologiques choisissant pour vous.<\/p>\n
Disons que nous venons de passer de Python 2.7 \u00e0 Python 3.0. Si vous d\u00e9veloppez vos applications en interne, vous avez le contr\u00f4le total et pouvez faire le changement ou ne pas le faire. Les d\u00e9veloppeurs, en revanche, pourraient bien d\u00e9cider de laisser les choses en l’\u00e9tat. Si une application est d\u00e9velopp\u00e9e pour et s’ex\u00e9cute sur Python 2.7, le d\u00e9veloppeur s’en tiendra l\u00e0 et indiquera aux utilisateurs qu’une application a \u00e9t\u00e9 d\u00e9velopp\u00e9e pour Python 2.7, sans prise en charge des autres versions.<\/p>\n
Cela peut laisser les utilisateurs dans une situation difficile – restez sur l’ancienne version de Python 2.7 pour s’adapter \u00e0 l’application, en laissant derri\u00e8re vous des progr\u00e8s, ou passez \u00e0 Python 3.0, et risquez une gamme d’incompatibilit\u00e9s avec les applications.<\/p>\n
Le r\u00e9sultat net : un risque majeur pour la s\u00e9curit\u00e9<\/h2>\n
Les langages de programmation (et leurs biblioth\u00e8ques assorties) ne sont pas \u00e0 l’abri des failles de s\u00e9curit\u00e9. Lorsque ces vuln\u00e9rabilit\u00e9s apparaissent, une mise \u00e0 niveau de la version linguistique peut vous \u00eatre impos\u00e9e par les d\u00e9veloppeurs. <\/p>\n
Mais ces mises \u00e0 niveau ne se limiteront pas \u00e0 de simples corrections de bogues – elles entra\u00eeneront la d\u00e9pr\u00e9ciation des constructions de langage avec de nouvelles constructions introduites, et cela obligera les d\u00e9veloppeurs \u00e0 modifier le code existant, encore une fois avec tous les probl\u00e8mes potentiels que apporte.<\/p>\n
La situation s’aggrave encore lorsque vous pensez \u00e0 l’effet cumulatif des biblioth\u00e8ques incluses. Apr\u00e8s les changements de langue, ces biblioth\u00e8ques doivent \u00e9galement \u00eatre mises \u00e0 jour – mais si l’une des biblioth\u00e8ques utilis\u00e9es n’est pas mise \u00e0 jour par ses auteurs, le d\u00e9veloppeur ne pourra pas l’utiliser apr\u00e8s la mise \u00e0 niveau du reste du code vers une version plus r\u00e9cente, ce qui conduit \u00e0 nouveau \u00e0 plus d’\u00e9criture de code. <\/p>\n
Il est facile de voir o\u00f9 tout cela m\u00e8ne : plus d’efforts, des risques suppl\u00e9mentaires d’introduction de bugs\u2026 et une r\u00e9ticence \u00e0 poursuivre le refactoring pour s’adapter aux mises \u00e0 jour. Prochain? Les mises \u00e0 jour ne sont tout simplement pas effectu\u00e9es, ce qui signifie que les charges de travail reposent sur des blocs de construction non s\u00e9curis\u00e9s et obsol\u00e8tes.<\/p>\n
L’histoire est similaire \u00e0 ce que nous voyons se d\u00e9rouler partout dans le monde de la technologie, alors que des blocs de construction anciens et vuln\u00e9rables laissent la porte ouverte aux cyberattaques. Il y a cependant de bonnes nouvelles qui \u00e9mergent. <\/p>\n
Existe-t-il une meilleure solution ?<\/h2>\n
Prenez les syst\u00e8mes d’exploitation non pris en charge, par exemple. Dans le pass\u00e9, quand un OS arriv\u00e9 en fin de vie<\/a>, le seul choix \u00e9tait de passer \u00e0 un syst\u00e8me d’exploitation plus r\u00e9cent – un investissement majeur et plein de risques. Le r\u00e9sultat net est que de nombreuses organisations s’appuient sur des syst\u00e8mes d’exploitation non corrig\u00e9s et non pris en charge, m\u00eame pour les charges de travail critiques. Si vous n’avez pas d’applications mises \u00e0 jour, car les d\u00e9veloppeurs ne refactoriseront pas les anciennes bases de code, vous ne pouvez pas d\u00e9placer vos applications vers des syst\u00e8mes d’exploitation plus r\u00e9cents qui ne prennent pas en charge les anciennes versions du langage – et donc casser l’application.<\/p>\n