Sur l'obsolescence du code et le cycle de vie des logiciels
Startup, nouvelles technologies, langages et frameworks modernes. Tout cela est tellement excitant lorsque nous commençons à faire quelque chose à partir de zéro. Et nous allons certainement essayer de choisir des technologies modernes et populaires aimées par des millions de personnes pour notre projet. Mais le temps n'arrête pas sa course incessante, et du coup nous regardons en arrière et voyons que notre «startup» a déjà 15 ans. Et le monde autour a changé il y a longtemps. Et nous avons toujours le même Basic / Delphi / Fortran / n'importe quoi dans notre projet. Et comment vivre avec?
Non, je ne veux pas du tout élever un autre holivar, et c'est loin d'être un fan. C'est juste ma peine personnelle de mener des projets valant plus d'un million de lignes de code sur des technologies obsolètes, en particulier sur Delphi.
Et il devient intéressant de savoir combien de temps dure un projet réussi. Si vous regardez autour de vous, alors, en principe, il y a pas mal de projets avec une "histoire barbu". Cela inclut WinRAR, Microsoft Office, AutoCAD, Photoshop, 3DSmax et bien d'autres. De plus, ce sont des projets destinés à un large public. Et combien de systèmes bancaires différents, CIS, CRM et autres systèmes «d'entreprise» de différents niveaux existent. Et beaucoup d'entre eux n'ont pas été écrits au cours des cinq dernières années.
Bien sûr, je voudrais suivre le rythme, mais migrer un gros projet d'une langue à une autre, à mon avis, est une tâche difficile. Non seulement cette migration est en cours et l'écriture d'un nouveau code, mais l'ancien projet devrait également continuer à fonctionner, vivre et se développer. Dans un nouveau projet, il faut répéter toute la logique de l'ancien, mais ce n'est pas toujours clair. Dans un ancien projet, une grande partie de la logique peut être construite sur des bibliothèques qui n'ont pas été prises en charge par leurs développeurs depuis longtemps. Dans un nouveau projet, ces bibliothèques doivent être remplacées. S'il s'agit de composants visuels, cela est encore plus difficile, car en plus de trouver un remplacement, vous devez également réfléchir à la manière de réécrire le code pour travailler avec ces composants visuels afin que le nouveau composant répète le comportement de l'ancien. Bien sûr, tout est résoluble et il n'y a aucun objectif de répéter le travail du projet à 100%,mais même 50% de le faire est très, très difficile, et dans le processus d'une telle réécriture, il peut s'avérer que la plate-forme / la langue dans laquelle ils ont décidé de réécrire ne convient pas ou perd déjà de sa popularité.
Bien sûr, je parle principalement de grands projets avec une couche de logique importante. Un million de lignes et plus. Ceux. pas sur les mini-sites, pas sur les microservices, mais sur ces monolithes (même s'ils sont divisés en "composants" / "couches", etc.).
J'aimerais connaître l'opinion des personnes présentes ici, avez-vous rencontré des problèmes similaires et comment vous avez agi dans des situations similaires?
Quelles solutions recommanderiez-vous d'appliquer pendant le développement afin que dans 10 à 15 ans, il n'y ait plus de désir de transférer le projet sur une autre plateforme?