Développement d'applications Web pour une longue durée de vie (20+ ans)
Je développe actuellement une application Web pour l'aménagement du territoire du gouvernement. L'application s'exécute principalement dans le navigateur, utilisant ajax pour charger et enregistrer les données.
Je ferai le développement initial, puis obtiendrai mon diplôme (c'est un travail d'étudiant). Après cela, le reste de l'équipe ajoutera la fonction occasionnelle selon les besoins. Ils savent coder, mais ce sont surtout des experts en aménagement du territoire.
Compte tenu du rythme auquel les technologies Javascript changent, comment puis-je écrire du code qui fonctionnera encore dans 20 ans? Plus précisément, quelles bibliothèques, technologies et idées de conception dois-je utiliser (ou éviter) pour pérenniser mon code?
Il est difficile de planifier un logiciel pour une telle durée de vie, car nous ne savons pas ce que l'avenir nous réserve. Un peu de contexte: Java a été publié en 1995, il y a 21 ans. XmlHttpRequest est devenu disponible en tant qu'extension propriétaire pour Internet Explorer 5, publié en 1999, il y a 17 ans. Cela a pris environ 5 ans avant est devenu disponible sur tous les principaux navigateurs. Les 20 années que vous essayez d’avancer sont à peu près à la même époque où les applications Web riches existaient.
Certaines choses sont certainement restées les mêmes depuis lors. Il y a eu un fort effort de normalisation, et la plupart des navigateurs se conforment bien aux différentes normes impliquées. Un site Web qui fonctionnait sur tous les navigateurs il y a 15 ans fonctionnera toujours de la même manière, à condition qu'il fonctionne parce qu'il cible le sous-ensemble commun de tous les navigateurs, et non parce qu'il utilise des solutions de contournement pour chaque navigateur.
D'autres choses allaient et venaient - surtout Flash. Flash a eu une variété de problèmes qui ont conduit à sa disparition. Plus important encore, il était contrôlé par une seule entreprise. Au lieu de la concurrence à l'intérieur de la plate-forme Flash, il y avait une concurrence entre Flash et HTML5 - et HTML5 a gagné.
De cette histoire, nous pouvons rassembler quelques indices:
Restez simple: faites ce qui fonctionne en ce moment, sans avoir à utiliser de solution de contournement. Ce comportement restera probablement disponible longtemps à l'avenir pour des raisons de compatibilité descendante.
Évitez de vous fier à des technologies propriétaires et préférez des normes ouvertes.
Le monde JavaScript est aujourd'hui relativement volatile avec un flux élevé de bibliothèques et de frameworks. Cependant, presque aucun d'entre eux n'aura d'importance dans 20 ans - le seul "framework" dont je suis certain qu'il sera encore utilisé d'ici là est Vanilla JS.
Si vous souhaitez utiliser une bibliothèque ou un outil car cela facilite vraiment le développement, assurez-vous d'abord qu'il est construit sur les normes bien prises en charge d'aujourd'hui. Vous devez ensuite télécharger la bibliothèque ou l'outil et l'inclure avec votre code source. Votre référentiel de code doit inclure tout le nécessaire pour que le système soit exécutable. Tout ce qui est externe est une dépendance qui pourrait se briser à l'avenir. Une façon intéressante de tester cela est de copier votre code sur une clé USB, d'aller sur un nouvel ordinateur avec un système d'exploitation différent, de le déconnecter d'Internet et de voir si vous pouvez faire fonctionner votre interface. Tant que votre projet se compose de HTML + CSS + JavaScript et peut-être de bibliothèques, vous allez probablement réussir.
Ce qui est encore plus important que votre code survivant pendant 20 ans, c'est que votre données survit pendant 20 ans. Les chances sont, c'est la chose qui mérite d'être préservée. Si vos données sont faciles à utiliser, il sera facile de créer un système alternatif avec une technologie plus récente.
- Commencez donc avec un modèle de données clair et bien documenté.
- Utiliser un système de base de données établi et bien pris en charge, tel qu'Oracle[1] ou SQL Server.
- Utilisez des fonctionnalités de base, n'essayez pas d'en insérer de nouvelles flashy.
- Préférez simple plutôt que intelligent.
- Acceptez que la maintenabilité future puisse se faire au détriment d'aspects tels que les performances. Par exemple, vous pourriez être tenté d'utiliser des procédures stockées, mais celles-ci pourraient limiter la maintenabilité future si elles empêchent quelqu'un de migrer le système vers une solution de stockage plus simple.
Une fois que vous avez cela, la pérennisation de l'application elle-même est plus simple, car elle enveloppe le modèle de données et peut être remplacée si, dans 10 ans, personne n'utilise plus Javascript, par exemple, et que vous devez migrer l'application vers WASM ou quelque chose. Garder les choses modulaires, moins interdépendantes, permet une maintenance future plus facile.
[1] La plupart des commentaires sur cette réponse prennent une position ferme contre l'utilisation d'Oracle pour une base de données, citant de nombreuses raisons parfaitement légitimes pour lesquelles Oracle est difficile à travailler, ont une courbe d'apprentissage abrupte et des frais généraux d'installation. Ce sont des préoccupations tout à fait valables lorsque vous choisissez Oracle comme base de données, mais dans notre cas, nous ne recherchons pas une base de données à usage général, mais une où la principale préoccupation est maintenabilité. Oracle existe depuis la fin des années 70 et sera probablement pris en charge pendant de nombreuses années à venir, et il existe un vaste écosystème de consultants et d'options de support qui peuvent vous aider à le faire fonctionner. Est-ce un gâchis trop cher pour de nombreuses entreprises? Sûr. Mais cela gardera-t-il votre base de données en service pendant 20 ans? Plutôt probable.
La réponse précédente par amon est super, mais il y a deux points supplémentaires qui n'ont pas été mentionnés:
Il ne s'agit pas seulement de navigateurs; les appareils comptent aussi.
amon mentionne le fait qu'un "site Web qui a fonctionné sur tous les navigateurs il y a 15 ans fonctionnera toujours de la même manière", ce qui est vrai. Cependant, regardez les sites Web créés il n'y a pas quinze, mais dix ans, qui, une fois créés, fonctionnaient dans la plupart des navigateurs pour la plupart des utilisateurs. Aujourd'hui, une grande partie des utilisateurs ne pourront plus utiliser ces sites Web, non pas parce que les navigateurs ont changé, mais parce que les appareils l'ont fait. Ces sites Web sembleraient terribles sur de petits écrans d'appareils mobiles , et ne fonctionneraient finalement pas du tout si les développeurs décidaient de s'appuyer sur l'événement JavaScript
click, sans savoir que l'événementtapest également important.Vous vous concentrez sur un mauvais sujet.
Les changements technologiques sont une chose, mais un plus important est le changement des exigences . Le produit peut avoir besoin d'être mis à l'échelle, ou peut avoir besoin de fonctionnalités supplémentaires, ou peut avoir besoin de modifier ses fonctionnalités actuelles.
Peu importe ce qui arrivera aux navigateurs, aux appareils, au W3C ou ... peu importe.
Si vous écrivez votre code de manière à ce qu'il puisse être refactorisé , le produit évoluera avec la technologie.
Si vous écrivez votre code d'une manière que personne ne peut le comprendre et le maintenir, la technologie n'a pas d'importance: tout changement environnemental entraînera de toute façon la fermeture de votre application, comme une migration vers un autre système d'exploitation, ou même quelque chose de simple comme la croissance naturelle des données .
A titre d'exemple, je travaille dans le développement logiciel depuis dix ans. Parmi les dizaines et les dizaines de projets, il n'y en avait que deux que j'ai décidé de changer à cause de la technologie, plus précisément parce que PHP a beaucoup évolué au cours des dix dernières années. Il ce n'était même pas la décision du client: il s'en moquerait si le site utilisait des espaces de noms ou des fermetures de PHP, mais les changements liés aux nouvelles exigences et à l'évolutivité étaient nombreux!
Vous ne prévoyez pas durer 20 ans. Clair et simple. Au lieu de cela, vous déplacez vos objectifs vers la compartimentation.
La base de données de votre application est-elle agnostique? Si vous deviez changer de base de données maintenant, pourriez-vous. Votre langage logique est-il agnostique? Si vous deviez réécrire l'application dans une toute nouvelle langue en ce moment, le pourriez-vous? Suivez-vous de bonnes directives de conception comme SRP et DRY?
J'ai des projets en cours depuis plus de 20 ans et je peux vous dire que les choses changent. Comme des pop-ups. Il y a 20 ans, vous pouviez compter sur un pop-up, aujourd'hui vous ne pouvez pas. XSS n'était pas une chose il y a 20 ans, maintenant vous devez rendre compte de CORS.
Donc, ce que vous faites, c'est de vous assurer que votre logique est bien séparée et que vous évitez d'utiliser TOUTE technologie qui vous enferme dans un fournisseur spécifique.
Cela peut parfois être très délicat. .NET par exemple est excellent pour exposer la logique et la méthode de son adaptateur de base de données MSSQL qui n'ont pas d'équivalents dans d'autres adaptateurs. MSSQL peut sembler être un bon plan aujourd'hui, mais le restera-t-il pendant 20 ans? Qui sait. Un exemple de la façon de contourner cela pour avoir une couche de données totalement séparée des autres parties de l'application. Dans le pire des cas, il vous suffit de réécrire toute la couche de données, le reste de votre application reste inchangé.
En d'autres termes, pensez-y comme une voiture. Votre voiture ne fera pas 20 ans. Mais, avec de nouveaux pneus, un nouveau moteur, une nouvelle transmission, de nouvelles vitres, une nouvelle électronique, etc. Cette même voiture peut rouler très longtemps.
Les réponses de @amon et d'autres sont excellentes, mais je voulais vous suggérer de regarder cela sous un autre angle.
J'ai travaillé avec de grands fabricants et des agences gouvernementales qui s'appuyaient sur des programmes ou des bases de codes utilisés depuis plus de 20 ans, et ils avaient tous une chose en commun: l'entreprise contrôlait le matériel. Avoir quelque chose en cours d'exécution et extensible pendant plus de 20 ans n'est pas difficile lorsque vous contrôlez ce qu'il fonctionne. Les employés de ces groupes ont développé du code sur des machines modernes qui étaient des centaines de fois plus rapides que les machines de déploiement ... mais les machines de déploiement étaient figées dans le temps.
Votre situation est compliquée, car un site Web signifie que vous devez planifier deux environnements - le serveur et le navigateur.
En ce qui concerne le serveur, vous avez deux choix généraux:
Comptez sur le système d'exploitation pour diverses fonctions de support qui peuvent être beaucoup plus rapides, mais cela signifie que le système d'exploitation peut avoir besoin d'être "figé dans le temps". Si tel est le cas, vous souhaiterez préparer des sauvegardes de l'installation du système d'exploitation pour le serveur. Si quelque chose tombe en panne dans 10 ans, vous ne voulez pas rendre quelqu'un fou en essayant de réinstaller le système d'exploitation ou de réécrire le code pour qu'il fonctionne dans un environnement différent.
Utilisez des bibliothèques versionnées dans un langage/framework donné, qui sont plus lentes, mais peuvent être empaquetées dans un environnement virtuel et probablement s'exécuter sur différents systèmes d'exploitation ou architectures.
En ce qui concerne le navigateur, vous devrez tout héberger sur le serveur (c'est-à-dire que vous ne pouvez pas utiliser un CDN global pour héberger des fichiers). Nous pouvons supposer que les futurs navigateurs exécuteront toujours HTML et Javascript (au moins pour la compatibilité), mais c'est vraiment une supposition/hypothèse et vous ne pouvez pas contrôler cela.
Le cœur de la plupart des applications sont les données. Les données sont éternelles. Le code est plus extensible, modifiable, malléable. Les données doivent cependant être conservées. Concentrez-vous donc sur la création d'un modèle de données vraiment solide. Gardez le schéma et les données propres. Anticipez qu'une nouvelle application puisse être construite au-dessus de la même base de données.
Choisissez une base de données capable d'appliquer des contraintes d'intégrité. Les contraintes non appliquées ont tendance à être violées au fil du temps. Personne ne le remarque. Utilisez au maximum les fonctionnalités telles que les clés étrangères, les contraintes uniques, les contraintes de vérification et éventuellement les déclencheurs de validation. Il existe quelques astuces pour abuser des vues indexées afin d'appliquer des contraintes d'unicité croisées.
Vous devrez peut-être accepter que la demande sera réécrite à un moment donné. Si la base de données est propre, il y aura peu de migration. Les migrations sont extrêmement coûteuses en termes de main d'œuvre et de défauts occasionnés.
D'un point de vue technologique, il peut être judicieux de placer la majeure partie de l'application sur le serveur et non sous une forme JavaScript sur le client. Vous pourrez probablement exécuter la même application dans la même instance de système d'exploitation pendant très longtemps grâce à virtualisation. Ce n'est pas vraiment Sympa mais c'est une garantie que l'application fonctionnera dans 20 ans sans coûts de maintenance et de matériel coûteux. En faisant cela, vous avez au moins la solution de rechange sûre et bon marché de continuer à exécuter un ancien code de travail.
De plus, je trouve que certaines piles technologiques sont plus stables que d'autres. Je dirais que .NET a la meilleure histoire de rétrocompatibilité possible actuellement. Microsoft est très sérieux à ce sujet. Java et C/C++ sont également très stables. Python a prouvé qu'il est très instable avec le Python 3 briser les changements. JavaScript me semble en fait assez stable car briser le Web n'est une option pour aucun fournisseur de navigateur. Vous ne devriez probablement pas vous fier à quelque chose d'expérimental ou de funky. ("Funky" étant défini comme "Je le sais quand je vois il").
Les autres réponses ont du sens. Cependant, je pense que les commentaires sur la technologie cliente compliquent les choses. Je travaille en tant que développeur depuis 16 ans. D'après mon expérience, tant que vous gardez votre code client intuitif, ça devrait aller. Donc pas de "hacks" avec des frames/iframes, etc. N'utilisez que des fonctions bien définies dans les navigateurs.
Vous pouvez toujours utiliser les modes de compatibilité dans les navigateurs pour les faire fonctionner.
Pour prouver mon point de vue, il y a seulement quelques mois, j'ai corrigé un bogue du millénaire dans le code javascript pour un client, qui utilisait son application Web depuis 17 ans. Fonctionne toujours sur les machines récentes, la base de données récente, le système d'exploitation récent.
Conclusion: restez simple et propre et tout ira bien.