Développement d'applications Web pour une longue durée de vie (20 ans et plus)

Je développe actuellement une application Web pour la planification foncière du gouvernement. L'application fonctionne principalement dans le navigateur, en utilisant ajax pour charger et enregistrer des données.

Je vais faire le développement initial, puis obtenir mon diplôme (c'est un travail d'étudiant). Après cela, le reste de l'équipe ajoutera la fonctionnalité 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 évoluent, comment puis-je écrire un 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 d'abord devenu disponible en tant qu'extension propriétaire pour Internet Explorer 5, publié en 1999, il y a 17 ans. Il a fallu environ 5 ans pour qu'il soit disponible sur tous les principaux navigateurs. Les 20 années que vous tentez d’envisager représentent à peu près le temps où les applications Web riches existaient déjà.

Certaines choses sont certainement restées les mêmes depuis. Il y a eu de gros efforts de normalisation, et la plupart des navigateurs se conforment bien aux différentes normes concernées. Un site Web qui fonctionnait sur plusieurs navigateurs il y a 15 ans fonctionnera toujours de la même manière, à condition que cela 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 - principalement Flash. Flash avait 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 au sein de la plate-forme Flash, il y avait une concurrence entre Flash et HTML5 - et le HTML5 gagné.

À partir de cette histoire, nous pouvons rassembler quelques indices:

• Restez simple: faites ce qui fonctionne pour le moment, sans recourir à des solutions de contournement. Ce comportement restera probablement disponible longtemps pour des raisons de compatibilité ascendante.

• Évitez de vous fier aux technologies propriétaires et préférez les normes ouvertes.

Le monde JavaScript est aujourd'hui relativement volatil avec un flux important de bibliothèques et de frameworks. Cependant, presque aucune d’entre elles n’aura d’importance dans 20 ans - le seul «cadre» dont je suis certain qu’il sera toujours utilisé à cette date est Vanilla JS .

Si vous souhaitez utiliser une bibliothèque ou un outil car cela facilite beaucoup le développement, assurez-vous d'abord qu'il repose sur les normes actuelles, bien supportées. 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 ce qui est nécessaire pour que le système soit exécutable. Tout ce qui est extérieur est une dépendance qui pourrait casser dans le futur. Un moyen intéressant de tester cela consiste à copier votre code sur une clé USB, à vous connecter à un nouvel ordinateur avec un système d'exploitation différent, à le déconnecter d'Internet et à voir si vous pouvez faire fonctionner votre interface. Tant que votre projet est composé de HTML simple, de CSS, de JavaScript et peut-être de bibliothèques, vous réussirez probablement.

Ce qui est encore plus important que votre code survivant pendant 20 ans est que vos données survivent pendant 20 ans. Les chances sont, c'est la chose à préserver. 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 par un modèle de données clair et bien documenté.
• Utilisez un système de base de données bien établi et bien pris en charge, tel que Oracle ^[1] ou SQL Server.
• Utilisez les fonctionnalités de base, n'essayez pas d'en insérer de nouvelles.
• Préfère le simple au malin .
• Acceptez le fait que la maintenabilité future peut 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, il est plus simple de pérenniser l'application elle-même, car elle encapsule le modèle de données et peut être remplacée si, dans 10 ans, plus personne n'utilise Javascript, par exemple, et que vous devez migrer l'application vers WASM ou quelque chose. Garder les choses modulaires, moins interdépendantes, facilite la maintenance future.

^[1] La plupart des commentaires qui sous-tendent cette réponse s’opposent vivement à l’utilisation d’Oracle pour une base de données, citant de nombreuses raisons parfaitement légitimes pour lesquelles travailler avec Oracle est une tâche ardue. Sa courbe d’apprentissage et son temps d’installation sont très lourds. Ce sont des préoccupations tout à fait valables lorsque vous choisissez Oracle en tant que base de données, mais dans notre cas, nous ne cherchons pas une base de données à usage général, mais une où la préoccupation principale est la maintenabilité . Oracle existe depuis la fin des années 70 et sera probablement pris en charge pendant de nombreuses années. Il existe un vaste écosystème de consultants et d'options de support qui peuvent vous aider à continuer à fonctionner. Est-ce un gâchis trop cher pour de nombreuses entreprises? Sûr. Mais votre base de données fonctionnera-t-elle pendant 20 ans ? Plutôt probable.

La réponse précédente par amon est excellente, mais il y a deux points supplémentaires qui n'ont pas été mentionnés:

• Ce n'est pas juste à propos des navigateurs; les appareils comptent aussi.

  Amon mentionne le fait qu'un «site Web fonctionnant 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 non pas il y a quinze ans 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 à cause du changement de navigateur, mais bien à cause du périphérique. 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 un clickévénement JavaScript , sans savoir que cet tapévénement était également important.

• Vous vous concentrez sur un mauvais sujet.

  Les changements technologiques sont une chose, mais une plus importante est la modification des exigences . Le produit doit peut-être être mis à l'échelle, ou peut-être nécessiter des fonctionnalités supplémentaires, ou peut nécessiter une modification de ses fonctionnalités actuelles.

  Peu importe ce qu'il adviendra des navigateurs, des appareils, du W3C ou ... peu importe.

  Si vous écrivez votre code de manière à ce qu'il puisse être restructuré , le produit évoluera avec la technologie.

  Si vous écrivez votre code de manière à ce que personne ne puisse le comprendre et le conserver, peu importe la technologie: toute modification de l'environnement entraînera de toute façon une baisse de votre application, telle qu'une migration vers un autre système d'exploitation, ou même quelque chose de simple, une croissance naturelle des données. .

  Par exemple, je travaille dans le développement de logiciels depuis dix ans. Parmi les dizaines et dizaines de projets, il n'y en a que deux que j'ai décidé de changer pour des raisons technologiques , plus précisément parce que PHP a beaucoup évolué au cours des dix dernières années. Ce n'était même pas la décision du client: peu lui importait que le site utilise les espaces de noms PHP ou les fermetures. Cependant, les changements liés aux nouvelles exigences et à l’évolutivité, il y en avait beaucoup!

Vous ne prévoyez pas durer 20 ans. Clair et simple. Au lieu de cela, vous déplacez vos objectifs vers la compartimentation.

Votre base de données d'applications 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 dès maintenant, pourriez-vous? Suivez-vous les bonnes directives de conception comme SRP et DRY?

J'ai des projets qui durent 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 une fenêtre contextuelle, mais vous ne pouvez pas aujourd'hui. XSS n'était pas une chose il y a 20 ans, maintenant vous devez tenir compte de CORS.

Vous devez donc vous assurer que votre logique est bien séparée et que vous évitez d'utiliser N'IMPORTE QUELLE technologie qui vous verrouille chez un fournisseur spécifique.

Cela peut être très difficile parfois. .NET, par exemple, est idéal pour exposer la logique et la méthode de son adaptateur de base de données MSSQL qui n’a pas d’équivalent dans d’autres adaptateurs. MSSQL peut sembler être un bon plan aujourd'hui, mais le restera-t-il pendant 20 ans? Qui sait. Voici un exemple de solution permettant d’avoir une couche de données totalement distincte des autres parties de l’application. Ensuite, dans le pire des cas, il vous suffit de réécrire la couche de données complète, le reste de votre application reste inchangé.

En d'autres termes, pensez-y comme une voiture. Votre voiture ne va pas faire 20 ans. Mais, avec des pneus neufs, un nouveau moteur, une nouvelle transmission, de nouvelles fenêtres, de nouveaux composants électroniques, etc. Cette même voiture peut être sur la route pendant très longtemps.

Les réponses de @amon et de certaines autres sont excellentes, mais je voulais vous suggérer d’examiner cette question 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. Ils avaient tous un point commun: l'entreprise contrôlait le matériel. Avoir quelque chose qui fonctionne et qui est extensible pendant plus de 20 ans n’est pas difficile lorsque vous contrôlez son fonctionnement. Les employés de ces groupes ont développé du code sur des machines modernes qui étaient des centaines de fois plus rapide que les machines à déployer ... mais les machines à déployer ont été 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 se bloque dans 10 ans, vous ne voulez pas que quelqu'un devienne 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 exécutées sur différents systèmes d'exploitation ou architectures.

En ce qui concerne le navigateur, vous devez tout héberger sur le serveur (par exemple, vous ne pouvez pas utiliser un CDN global pour héberger des fichiers). Nous pouvons supposer que les futurs navigateurs continueront à utiliser HTML et Javascript (au moins pour des raisons de compatibilité), mais c'est vraiment une supposition / hypothèse et vous ne pouvez pas contrôler cela.

Les données constituent le noyau de la plupart des applications. Les données sont pour toujours. Le code est plus consomptible , modifiable, malléable. Les données doivent cependant être préservé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 sur le fait qu’une nouvelle application pourrait être construite sur 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 avec le temps. Personne ne le remarque. Utilisez au maximum des fonctionnalités telles que des clés étrangères, des contraintes uniques, des contraintes de vérification et éventuellement des déclencheurs de validation. Il existe certaines astuces pour abuser des vues indexées afin d'appliquer des contraintes d'unicité entre les tables.

Alors peut-être devez-vous accepter que l'application soit réécrite à un moment donné. Si la base de données est propre, il y aura peu de travail de migration. Les migrations sont extrêmement coûteuses en termes de travail et de défauts.

D'un point de vue technologique, il peut être judicieux de placer la plupart des applications sur le serveur et non sous une forme JavaScript sur le client. Grâce à la virtualisation, vous pourrez probablement exécuter la même application sur la même instance de système d'exploitation pendant une très longue période . Ce n’est pas vraiment agréable, 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 possibilité sécuritaire et peu coûteuse de continuer à exécuter du code ancien et fonctionnel.

De plus, je trouve que certaines piles technologiques sont plus stables que d’autres . Je dirais que .NET a actuellement la meilleure histoire de compatibilité ascendante possible. Microsoft est vraiment sérieux à ce sujet. Java et C / C ++ sont également très stables. Python a prouvé qu’il était très instable avec les changements importants de Python 3. JavaScript me semble en fait assez stable, car casser le Web n’est une option pour aucun vendeur de navigateur. Vous ne devriez probablement pas vous fier à rien d’expérimental ou de funky. ("Funky" étant défini comme "je le sais quand je le vois").

Les autres réponses ont un sens. Cependant, j’ai le sentiment que les commentaires sur la technologie client compliquent beaucoup 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, tout devrait bien se passer. Donc, pas de "hacks" avec des cadres / iframes, etc. Utilisez uniquement des fonctions bien définies dans les navigateurs.

Vous pouvez toujours utiliser les modes de compatibilité dans les navigateurs pour les maintenir en fonctionnement.

Pour prouver mon point de vue, il y a quelques mois à peine, j'ai corrigé un bogue du code javascript pour un client qui exécutait son application Web depuis 17 ans. Fonctionne toujours sur des machines récentes, une base de données récente, un système d'exploitation récent.

Conclusion: restez simple et propre et tout ira bien.

Quelques axiomes:

• La vérité survit. Dans ce contexte, il s'agirait d'algorithmes et de modèles de données - ce qui représente fidèlement le "quoi" et le "comment" de votre espace de problèmes. Bien que, il y ait toujours le potentiel pour le raffinement et l'amélioration, ou une évolution du problème lui-même.
• Les langues évoluent. Ceci est aussi vrai pour les langages informatiques que pour les langages naturels.
• Toute technologie est vulnérable à l'obsolescence. Cela peut prendre plus de temps pour certaines technologies que d'autres

Les technologies et normes les plus stables (celles qui sont le moins vulnérables à l'obsolescence) ont tendance à être celles qui ne sont pas propriétaires et qui ont été adoptées le plus largement. Plus l'adoption est large, plus l'inertie contre presque toute forme de changement est grande. Les «normes» propriétaires sont toujours vulnérables aux fortunes et aux caprices de leurs propriétaires et aux forces concurrentielles.

Vingt ans, c’est très long dans l’industrie informatique. Cinq ans est un objectif plus réaliste. Dans cinq ans, le problème que votre application est censée résoudre pourrait être complètement redéfini.

Quelques exemples pour illustrer:

C et C ++ existent depuis longtemps. Ils ont des implémentations sur à peu près toutes les plateformes. Le C ++ continue d'évoluer, mais les fonctionnalités "universelles" (celles disponibles sur toutes les plateformes) sont pratiquement garanties de ne jamais être déconseillées.

Flash est presque devenu un standard universel, mais il est propriétaire. La décision des entreprises de ne pas prendre en charge cette fonctionnalité sur les plates-formes mobiles les plus répandues l'a pratiquement condamné: si vous créez pour le Web, vous souhaitez que votre contenu soit disponible sur toutes les plates-formes. vous ne voulez pas manquer le grand marché que le mobile est devenu.

WinTel (Windows / x86), bien qu’il soit propriétaire de Microsoft et d’Intel, a démarré sur une plate-forme peu optimale (interne 16 bits / interne 8 bits externe 8088 vs Apple Macintosh 32 bits interne / interne interne 16 bits externe 68000), et l’érosion Apple sur le marché grand public reste un choix de facto pour les plates-formes professionnelles. Pendant tout ce temps (25 ans), un engagement en matière de compatibilité ascendante a à la fois entravé le développement futur et inspiré une confiance considérable dans le fait que ce qui fonctionnait sur l’ancien boîtier fonctionnera toujours sur le nouveau.

Dernières pensées

JavaScript n'est peut-être pas le meilleur choix pour la mise en œuvre de la logique métier. Pour des raisons d’intégrité et de sécurité des données, la logique commerciale doit être exécutée sur le serveur. Par conséquent, le code JavaScript côté client doit être limité au comportement de l’interface utilisateur. Même sur le serveur, JavaScript n'est peut-être pas le meilleur choix. Bien que plus facile à utiliser que d'autres piles (Java ou C #) pour de petits projets, il manque la formalité qui peut vous aider à écrire de meilleures solutions, mieux organisées, lorsque les choses deviennent plus complexes.