Le progrès propulse la technologie vers l’avant. Mais le progrès a aussi un coût : en ajoutant de nouvelles capacités et fonctionnalités, la communauté des développeurs ajuste constamment les éléments de base. Cela inclut les langages fondamentaux utilisés pour coder les solutions technologiques.

Lorsque les éléments constitutifs changent, le code derrière la solution technologique doit également changer. C’est un exercice difficile et chronophage qui épuise les ressources. Et s’il y avait une alternative ?

Le problème : lire le code que quelqu’un d’autre a écrit

Prenons du recul et examinons l’un des défis fondamentaux du développement : éditer le code de quelqu’un d’autre. L’édition du code que vous venez d’écrire, ou que vous avez écrit il y a quelques semaines, est très bien. Mais éditer votre propre code écrit il y a des années – sans parler du code de quelqu’un d’autre – c’est une autre histoire.

Les règles de style de code internes peuvent aider, mais il existe toujours des conventions de dénomination étranges pour les variables et les fonctions, ou des choix inhabituels pour les algorithmes. On peut dire que la capacité d’un programmeur à lire le code est une compétence clé – mais c’est difficile pour tout le monde.

Les développeurs appellent le processus d’édition de l’ancien code « refactoring » et c’est un processus qui introduit généralement de nouveaux bogues ou problèmes de performances. C’est pourquoi, revenir en arrière et éditer l’ancien code, eh bien – c’est la dernière chose que la plupart des équipes de développement veulent faire, en particulier lorsque la base de code existante fonctionne de manière stable et fait son travail.

C’est un vrai casse-tête, mais parfois il n’y a pas d’alternative

La refactorisation est quelque chose que chaque développeur veut éviter le plus longtemps possible car cela peut sembler une perte de temps. Néanmoins, les développeurs 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éveloppeurs.

Cela inclut les changements apportés aux langages de programmation utilisés pour créer des logiciels, qui évoluent inévitablement avec le temps. Les nouvelles versions d’un langage désapprouvent souvent les anciennes façons de faire tout en introduisant de nouvelles fonctionnalités. Si les développeurs n’adoptent pas la nouvelle version linguistique, ils sont exclus du nouvel ensemble de fonctionnalités.

Cependant, le code existant doit généralement être ajusté pour fonctionner sur la nouvelle version du langage, ce qui implique un processus de refactorisation. Et c’est là l’énigme : pour adopter la nouvelle version plus avancée d’un langage, les développeurs doivent refactoriser, et en cours de route, ils dépenseront énormément d’efforts – et casseront toutes sortes de choses inattendues, introduisant de nouveaux bogues dans une application qui fonctionnait très bien.

Pire encore, la refactorisation seule ne vous donne pas les avantages de la nouvelle version linguistique, vous devez plutôt redévelopper votre base de code pour tirer parti des améliorations. Sinon, malgré l’ajustement du code pour s’adapter à la nouvelle version linguistique, vous êtes exactement là où vous étiez : une base de code fonctionnant sur une nouvelle version linguistique, mais sans nouvelles fonctionnalités.

Les fournisseurs laissent généralement les utilisateurs finaux s’en occuper

Cela peut sembler être un exercice inutile, mais avec l’évolution constante de la technologie, il n’y a souvent que peu de choix en la matière, vos partenaires technologiques choisissant pour vous.

Disons que nous venons de passer de Python 2.7 à Python 3.0. Si vous développez vos applications en interne, vous avez le contrôle total et pouvez faire le changement ou ne pas le faire. Les développeurs, en revanche, pourraient bien décider de laisser les choses en l’état. Si une application est développée pour et s’exécute sur Python 2.7, le développeur s’en tiendra là et indiquera aux utilisateurs qu’une application a été développée pour Python 2.7, sans prise en charge des autres versions.

Cela peut laisser les utilisateurs dans une situation difficile – restez sur l’ancienne version de Python 2.7 pour s’adapter à l’application, en laissant derrière vous des progrès, ou passez à Python 3.0, et risquez une gamme d’incompatibilités avec les applications.

Le résultat net : un risque majeur pour la sécurité

Les langages de programmation (et leurs bibliothèques assorties) ne sont pas à l’abri des failles de sécurité. Lorsque ces vulnérabilités apparaissent, une mise à niveau de la version linguistique peut vous être imposée par les développeurs.

Mais ces mises à niveau ne se limiteront pas à de simples corrections de bogues – elles entraîneront la dépréciation des constructions de langage avec de nouvelles constructions introduites, et cela obligera les développeurs à modifier le code existant, encore une fois avec tous les problèmes potentiels que apporte.

La situation s’aggrave encore lorsque vous pensez à l’effet cumulatif des bibliothèques incluses. Après les changements de langue, ces bibliothèques doivent également être mises à jour – mais si l’une des bibliothèques utilisées n’est pas mise à jour par ses auteurs, le développeur ne pourra pas l’utiliser après la mise à niveau du reste du code vers une version plus récente, ce qui conduit à nouveau à plus d’écriture de code.

Il est facile de voir où tout cela mène : plus d’efforts, des risques supplémentaires d’introduction de bugs… et une réticence à poursuivre le refactoring pour s’adapter aux mises à jour. Prochain? Les mises à jour ne sont tout simplement pas effectuées, ce qui signifie que les charges de travail reposent sur des blocs de construction non sécurisés et obsolètes.

L’histoire est similaire à ce que nous voyons se dérouler partout dans le monde de la technologie, alors que des blocs de construction anciens et vulnérables laissent la porte ouverte aux cyberattaques. Il y a cependant de bonnes nouvelles qui émergent.

Existe-t-il une meilleure solution ?

Prenez les systèmes d’exploitation non pris en charge, par exemple. Dans le passé, quand un OS arrivé en fin de vie, le seul choix était de passer à un système d’exploitation plus récent – un investissement majeur et plein de risques. Le résultat net est que de nombreuses organisations s’appuient sur des systèmes d’exploitation non corrigés et non pris en charge, même pour les charges de travail critiques. Si vous n’avez pas d’applications mises à jour, car les développeurs ne refactoriseront pas les anciennes bases de code, vous ne pouvez pas déplacer vos applications vers des systèmes d’exploitation plus récents qui ne prennent pas en charge les anciennes versions du langage – et donc casser l’application.

Heureusement, ce scénario a changé car l’assistance en fin de vie est désormais une réalité pour de nombreux systèmes d’exploitation Linuxce qui signifie que les organisations peuvent gagner du temps pour migrer d’un système d’exploitation non pris en charge vers un système d’exploitation avec prise en charge par un fournisseur officiel, sans prendre aucun risque de sécurité.

Peut-on faire quelque chose de similaire pour les versions linguistiques ? Un moyen de « mettre à niveau » efficacement un runtime de langage avec les derniers correctifs de sécurité tout en ne modifiant pas le fonctionnement de cette version de langage ou de ces bibliothèques spécifiques, supprimant ainsi le besoin de refactoriser ?

Répéter ce qui a été réalisé pour les systèmes d’exploitation et l’appliquer aux versions linguistiques donnera aux développeurs une énorme marge de manœuvre, réduisant ainsi le besoin de refactoriser en permanence. À leur tour, il y a une probabilité plus élevée que les charges de travail s’exécutent en toute sécurité.

Est-il possible? Eh bien, ce qui a été réalisé pour les systèmes d’exploitation peut être étendu à d’autres domaines. Surveillez cet endroit.