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

160

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?

Dan
la source
94
J'ai commencé à programmer en Fortran à la fin de 1966 et j'ai donc eu amplement le temps de réfléchir à ce type de problème. Si vous rencontrez un jour une réponse fiable à 50%, merci de me le faire savoir. Pendant ce temps, il suffit de penser à l'obsolescence quasi-inévitable comme à la "sécurité de l'emploi" :)
John Forkosh
11
Rien ne dure éternellement en génie logiciel. Seulement hôte dans les banques et parce que personne n'ose mettre à jour de tels systèmes critiques. Eh bien, je suppose que le programme exécuté dans le Voyager compte également.
Laiv
9
@ Laiv Il y a quelque temps, j'ai travaillé sur des applications de transfert d'argent pour Bankers Trust à l'aide de la messagerie Swift exécutée sur Vax / VMS. Quelques années plus tard, Swift supprima tout le support VMS. Eh bien, est-ce que cela a causé des problèmes ... et m'a fourni un autre contrat chez BTCo. Comme je l'ai dit plus haut, "sécurité d'emploi" :). Quoi qu'il en soit, ce que je veux dire, c'est que même les applications critiques des marchés financiers ne sont pas à l'abri de l'obsolescence.
John Forkosh
102
Que diriez-vous de "Ecrire un code que le prochain développeur peut comprendre"? Si et quand le code devient obsolète au point qu’ils auront besoin de trouver un programmeur pour le mettre à jour, le meilleur scénario est qu’ils comprendront ce que fait votre code (et peut-être pourquoi certaines décisions ont été prises).
David Starkey
38
Il suffit d'utiliser du HTML ancien, pas de JS, pas de plugins, rien d'extraordinaire. Si cela fonctionne dans Lynx, c'est bon pour tous les temps.
Gaius

Réponses:

132

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.

Amon
la source
4
Les applications à grande échelle sont immuables dans vanilla js, à partir de maintenant. ES6 corrige déjà le problème, mais il y a une raison pour laquelle flow ou TypeScript gagnent en popularité.
Andy
34
@DavidPacker Absolument, TypeScript, etc. sont excellents et facilitent le développement. Mais dès que j'introduis un processus de construction, tous les outils nécessaires à ce processus deviennent des dépendances: NodeJS, Gulp, NPM - qui a déclaré que NPM serait toujours en ligne dans 20 ans? Je devrai gérer mon propre registre pour en être certain. Ce n'est pas impossible. Mais à un moment donné, il vaut mieux abandonner les choses qui facilitent le développement seulement immédiatement, mais pas à long terme.
amon
30
@DavidPacker Il existe de nombreux langages dynamiques et, étonnamment, de nombreux systèmes à succès ont été construits avec Smalltalk, Ruby, Perl, Python, même avec PHP et JS. Alors que les langages à typage statique ont tendance à être plus faciles à maintenir alors que les langages dynamiques ont tendance à être meilleurs pour le prototypage rapide, il n'est pas impossible d'écrire des JS maintenables. En l'absence de compilateur, de compétences médianes élevées au sein de l'équipe, de savoir-faire et d'une importance accrue pour une organisation claire du code deviennent encore plus cruciales. Personnellement, je pense que les types facilitent les choses, mais ils ne sont pas une solution miracle.
amon
4
Est-ce que je viens de lire "prendre usb et tester sur une machine différente"? Pourquoi ne pas simplement faire tourner la virtualbox ou simplement utiliser le mode incognito (avec ethX désactivé).
Kyslik
5
Je ne suis pas sûr que JS de vanille sera une chose sûre dans 20 ans. Son histoire a été rocailleuse et expérimentale, et il en a pas mal pris d'assaut au fil du temps, même s'il est devenu un langage agréable et efficace (personnellement, je préfère JavaScript ou TypeScript). Il n’est pas difficile d’imaginer que les fournisseurs voudront peut-être abandonner tout ou partie de cette crue, qu’il s’agisse de commencer à proposer un nouveau langage alternatif - comme Google semblait le proposer avec Dart, même si cela ne semble pas être allé nulle part. —Ou en déconseillant puis en éliminant des parties de JS.
Kryan
178

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.

Avner Shahar-Kashtan
la source
141
Je suis désolé, mais je dois dire ceci. Si vous utilisez Oracle, vous tirez dans le pied sur tout le monde en ce qui concerne "facile à travailler." Il n'est pas facile de travailler avec Oracle . Un grand nombre de fonctionnalités que SQL Server, PostgreSQL et probablement même MySQL simplifient, Oracle n’a pas ou rend trop difficile. Je n'ai jamais autant de problèmes stupides avec d'autres bases de données qu'avec Oracle; le simple fait d’installer le client est une douleur énorme dans le dos. Même les choses googler est difficile. Si vous voulez "travailler facilement", évitez Oracle.
jpmc26
4
+1 pour garder les données aussi simples que possible. Utilisez le SQL standard pour cela, par exemple, utilisez OUTER JOIN au lieu de l' opérateur + spécifique d'Oracle . Utilisez des dispositions de table simples. Ne normalisez pas vos tables au niveau maximum absolu. Décidez si certaines tables peuvent contenir des données redondantes ou si vous devez réellement créer une nouvelle table afin que chaque valeur n'existe qu'une seule fois. Les procédures stockées sont-elles spécifiques au fournisseur ? Si oui, alors ne les utilisez pas. N'utilisez pas la fonctionnalité la plus chaude de la langue de votre choix: j'ai vu plus de programmes COBOL sans fonctionnalité POO que de les utiliser . Et c'est totalement ok.
some_coder
3
@ jpmc26 Je partage votre opinion sur Oracle, mais comme je l'ai dit, "il est facile de travailler avec" n'est pas nécessairement la principale exigence. Je préfère une plate-forme solidement soutenue ici, même si c'est pénible de travailler avec. Parce que quand amorti sur 20 ans, c'est pas mal.
Avner Shahar-Kashtan
8
Évitez en effet Oracle. Postgresql est la seule base de données existante qui ne semble pas être un mauvais choix dans 20 ans.
Josué
3
Je voudrais ajouter que les SGBD à code source ouvert sont préférables car ils ont de bonnes chances de ne pas mourir. Si Oracle cesse de gagner de l'argent dans 10 ans, il ne sera plus utilisé dans 11 ans. PostreSQL semble être le meilleur cheval sur lequel parier.
Shautieh
36

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!

Arseni Mourzenko
la source
4
L'adoption de différentes tailles d'écran est un problème général. Le mobile fait actuellement fureur, mais si vous consultez ce site Web dans une fenêtre de navigateur plein écran sur un écran offrant une résolution suffisante, il y a beaucoup d'espace vide (gaspillé). Modifier les dispositions et la manière dont les informations sont présentées pour utiliser au mieux les pixels disponibles ne s'est jamais réellement produit de manière intelligente. Mobile a rendu cela évident. Mais penser dans l'autre sens pourrait être plus important pour la question à traiter.
null
9
@ Null: bien que je sois d'accord avec votre commentaire, les sites Web StackExchange peuvent ne pas être la meilleure illustration de votre argument. Étant donné les données à afficher, je pense que les concepteurs / développeurs de StackExchange ont très bien réussi à les afficher car elles doivent être affichées, y compris sur des écrans de grande taille. Vous ne pouvez pas élargir la colonne principale, car le texte deviendrait beaucoup plus difficile à lire, et vous ne pouvez pas utiliser plusieurs colonnes car il ne sera pas très beau pour les questions et réponses brèves.
Arseni Mourzenko
Un autre bon exemple est l'événement "survol" souvent utilisé dans les systèmes de menus. Beaucoup de ces menus échouent lamentablement avec les appareils tactiles.
Justas
Vous avez raison à 110% (ou plus) au sujet des appareils, et je peux vous donner des exemples vieux de plusieurs décennies. À la fin des années 1980, je travaillais sur des applications CICS fonctionnant sur des ordinateurs centraux IBM et des terminaux 3270 synchrones. La région CICS est un peu analogue aux applications côté serveur, envoyant des données à la fois plein d’écrans aux terminaux synchrones, qui sont donc analogues aux navigateurs d’appareils dédiés. Et la programmation CICS était peut-être à 80% Cobol, 20% PL / 1. Ces deux langues sont pour la plupart obsolètes de nos jours, et l'apparition des stations de travail Unix (Sun et Apollo) au début des années 1990 a presque complètement tué CICS
John Forkosh
31

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.

coteyr
la source
2
"Si vous deviez changer de base de données maintenant, pourriez-vous" C'est presque impossible à accomplir si vous faites autre chose que CRUD sur une ligne à la fois.
jpmc26
1
Beaucoup d'ORM sont agnostiques aux bases de données. Je pouvais donner n'importe lequel des projets sur lesquels je travaille actuellement que je pourrais passer de SQLLite à MySql et Postgre sans aucun effort.
coteyr
5
Et les ORM cessent d’être de très bons outils pour le travail lorsque vous faites plus que de simples CRUD sur un seul enregistrement à la fois. C'est pourquoi je l'ai qualifié. J'ai essayé. Au fur et à mesure que la complexité de la requête augmente, même les meilleurs ORM posent plus de problèmes que la simple écriture de la requête. Même si vous y forcez votre requête, vous vous retrouvez assez rapidement en utilisant des fonctionnalités ou des optimisations spécifiques à la base de données.
jpmc26
1
Définir "complexe". Était-ce une opération en masse? At-il inclus des requêtes de fenêtre? Sous-requêtes? CTE? Les syndicats? Conditions de regroupement complexes? Des mathématiques complexes sur chaque ligne et les agrégats? Combien de jointures dans une seule requête? Quels types de jointures? Combien de lignes ont été traitées à la fois? Certes, dire quoi que ce soit au- dessus d'une seule ligne CRUD (attention, cela signifie une ligne par requête, et non par requête Web ou autre.) Est un peu hyperbole, mais la route à suivre lorsque l'ORM devient plus problématique qu'elle ne vaut la peine tu penses. Et les étapes pour bien exécuter une requête sont très souvent spécifiques à une base de données.
jpmc26
4
"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 langue totalement nouvelle, pourriez-vous?" - Ceci est un conseil absolument terrifiant! Ne vous contraignez pas artificiellement à ce que vous croyez être le plus grand dénominateur commun des langages de programmation ou des bases de données - cela vous obligera à réinventer la roue à tout moment. Essayez plutôt de trouver le moyen NATUREL d’exprimer le comportement souhaité dans votre langage de programmation et dans la base de données de votre choix.
fgp
12

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.

Jonathan Vanasco
la source
11
Vous devez également considérer la sécurité. Un OS non supporté âgé de 20 ans sera probablement plein de failles de sécurité. J'ai travaillé pour une entreprise et hérité de ce problème. Agence gouvernementale, anciens systèmes d’exploitation (heureusement tous longtemps virtualisés), mais c’était un problème énorme, et la mise à niveau était pratiquement impossible en raison de la réécriture complète du logiciel (des centaines de scripts PHP de code spaghetti individuels, chacun ayant reçu des appels de base de données). codé en dur, en utilisant des fonctions obsolètes que le nouveau pilote ne supportait pas / shudder).
Si vous choisissez la route du système d'exploitation, vous pouvez au mieux espérer que les correctifs de sécurité ont été appliqués et que les futurs responsables de la maintenance seront en mesure de protéger les éléments au niveau de la couche réseau. Afin de planifier des choses qui fonctionnent de la sorte à long terme (surtout en l’absence d’un budget important, car le PO est un étudiant), vous devez en principe accepter que votre application et votre serveur finissent par devenir peu sûrs. Par exemple, dans 20 ans, il existera éventuellement des exploits connus de la version SSL sur le serveur ... mais ce système d'exploitation risque de ne pas être compatible avec les versions de openssl dans 10 ans. Il s’agit de minimiser les compromis.
Jonathan Vanasco
@FighterJet, vous pouvez toujours exécuter un pare-feu sur un système d'exploitation pris en charge. Vous avez donc peu de risques en dehors des injections SQL, etc. que vous auriez dû coder de toute façon.
Ian
@ Ian: Je souhaite. Il y avait un pare-feu. Mais je n'ai pas écrit le code, je l'ai hérité. Et oui, il y avait des milliers de vulnérabilités SQL que j'aurais aimé pouvoir corriger, mais le vrai problème était que le code dépendait d'une version particulière de PHP4 (obsolète depuis toujours et regorgeant de failles de sécurité) et d'un Une version particulière du pilote de base de données (qui ne fonctionnait pas sur les systèmes d'exploitation les plus récents), ce qui nous empêchait de passer à une version plus récente de la base de données. Disons simplement que je suis content de ne plus y travailler.
1
@ FighterJet C'est en fait un très bon exemple de ce que je voulais dire. Vous avez fini par hériter d'un code ne fonctionnant que sur une version particulière de PHP4 et d'un pilote s'exécutant uniquement sur un système d'exploitation particulier ... vous ne pouvez donc pas mettre à niveau le serveur. Je ne recommanderais personne de faire ça, mais ça arrive. -- beaucoup. FWIW, je suis d’accord avec vous mais je voulais ma réponse pour encourager la réflexion sur ce type de scénario et non pour faire une recommandation.
Jonathan Vanasco
6

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").

usr
la source
à propos de la compatibilité ascendante .net - Je ne pense pas avoir vu une application Java qui demanderait une version plus ancienne de Java, contrairement à ce qui se passe. Cela pourrait changer avec Java 9 ou au-delà, mais ne l’a pas encore vu se produire.
eis
Il est étonnamment compatible en pratique et l’installation d’une version antérieure côte à côte n’est pas un problème. Notez également que, selon moi, le .NET BCL est 10 à 100 fois plus volumineux que les classes intégrées Java.
Usr
La compatibilité ascendante signifie qu’il ne devrait pas être nécessaire d’installer également une version plus ancienne. Mais nous nous écartons de la question initiale, cela n’est pas vraiment pertinent pour OP.
eis
0

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.

Jonathan van de Veen
la source
1
Les cadres et les iframes sont très bien définis dans la spécification HTML. Qu'est-ce qui les rend inappropriés?
curieuxdannii
3
@curiousdannii: Ce n'est pas tellement l'utilisation d'iframes (les cadres ne sont plus pris en charge en HTML5), mais l'utilisation de cadres et d'iframes pour charger du contenu de manière asynchrone via des scripts, etc. Cela peut fonctionner très bien actuellement, être soumis à des changements de sécurité.
Jonathan van de Veen
-2

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.

Zenilogix
la source