Combien de temps et les efforts devraient passer un projet sur la compatibilité ascendante? [fermé]

Question

Étant donné que chaque projet de logiciel ne dispose que tant de programmeur-heures consacrées à lui, combien consacrez-vous à faire en sorte que le produit est compatible avec les versions précédentes? En fait, il y a plusieurs points à considérer:

• Est-ce que l'âge du logiciel affecte votre décision? Voulez-vous investir moins de temps dans la rétrocompatibilité lorsque le programme est plus récent?
• La décision est fondée uniquement sur le nombre de clients des copies installées?
• Avez-vous faire un effort actif pour produire des formats de code et de fichiers qui prend en charge les changements à venir?
• Lorsque vous développez v1.0, essayez-vous de construire pour le rendre plus facile pour v2.0 d'être rétrocompatible avec v1.0? (Laissant les champs "réservés" est un exemple.)
• Comment décidez-vous que « Non, nous n'allons soutenir que plus » sur les caractéristiques?

Answer 1

La base client est clé dans déterminer si oui ou non vous devriez soutenir un grand problème de compatibilité descendante.

En gros, vous devez évaluer que, comme tout autre dont vous avez besoin pour mettre en œuvre, et vous devez spécifier soigneusement exigences non fonctionnelles ce qui est inclus dans un "caractéristique rétrocompatibilité" :

• Compatibilité API . Cela signifie que les versions ultérieures d'une bibliothèque fournissent la même API que les versions précédentes font, afin que les programmes écrits contre la version précédente sera toujours en mesure de compiler et exécuter avec la nouvelle version. En plus de laisser effectivement les mêmes fonctions autour, cela implique aussi que ces fonctions font tous la même chose dans la nouvelle version qu'ils ont fait dans les anciens
• Application Binary Interface, ou ABI, la compatibilité . Cela signifie que la compatibilité descendante est préservée au niveau du code objet binaire produit lorsque vous compilez la bibliothèque.
  Il y a généralement un certain chevauchement entre la compatibilité API et ABI, mais il existe des différences importantes. Pour maintenir la compatibilité ABI, tout ce que vous avez à faire est de vous assurer que votre programme exporte tous les mêmes symboles.
  Cela signifie que toutes les mêmes fonctions et ont besoin d'être là des objets globalement accessibles, de sorte que les programmes liés contre la version précédente sera toujours en mesure d'exécuter avec la nouvelle version.
  Il est possible de maintenir la compatibilité ABI tout casser la compatibilité API . Dans le code C, laisser des symboles dans les fichiers C, mais les supprimer des en-têtes publics, le code si nouvelle que tente d'accéder aux symboles ne parviendra pas à compiler, alors que l'ancien code que les utilisateurs compilés avec la version précédente continuera à fonctionner
• compatibilité des protocoles client-serveur . Cela signifie qu'un client en utilisant la version du protocole réseau fourni dans les versions plus anciennes continuera à fonctionner face à un serveur plus récent, et que les programmes clients plus récents continuera de travailler avec un ancien serveur.
• compatibilité des formats de données . Les nouvelles versions du code doivent être en mesure de travailler avec des fichiers de données écrites par les anciennes versions, et vice versa. Idéalement, vous devriez également être en mesure de construire une certaine compatibilité avant dans les formats de données. Si vos routines de fichiers de traitement peuvent ignorer et préserver les champs non reconnus, de nouvelles fonctionnalités peuvent modifier les formats de données d'une manière qui ne cassent pas les anciennes versions. Ceci est l'un des types de compatibilité les plus critiques, tout simplement parce que les utilisateurs deviennent très contrariés lorsqu'ils installent une nouvelle version d'un programme et ne parvenez plus à accéder à leurs anciennes données.

Si vous combinez les critères précédents (la nature de la compatibilité descendante) avec la nature de votre base client, vous pouvez décider que:

• Si vos clients sont internes à votre entreprise, le besoin est plus faible, et 2.0 peut briser les fonctions importantes.

• Si vos clients sont externes, un 2.0 peut encore casser des choses, mais vous devrez peut-être fournir Guide de migration

• A l'extrême, si vos clients sont tout monde, comme je l'ai déjà parlé dans ce SO question sur java , vous pouvez finir par fournir de nouvelles fonctionnalités sans jamais déprécier les anciens! Ou même préserver BUGS de vos anciens produits , parce que les applications du client dépend de ces bugs !!

---

• L'âge du logiciel affecte votre décision? Voulez-vous investir moins de temps dans la rétrocompatibilité lorsque le programme estnouvelle?
  Je crois que cela a à voir avec ce qui est déjà déployé: un récent programme devra traiter avec moins de besoins de compatibilité ascendante que celle qui est autour de 20 ans

.

• La décision fondée uniquement sur le nombre de clients avec les copies installées?
  Il devrait se fonder sur une étude de cas: (à cause de toutes les nouvelles fonctionnalités brillantes qu'elle apporte) votre migration - - si nécessaire en raison d'un manque de compatibilité ascendante peut être « vendu » efficacement à vos clients

• Faites-vous un effort actif pour produire des formats de code et de fichiers qui prend en charge les changements à venir?
  Essayer de prédire « changement futur » peut être très contre-productif et rapidement limite à YAGNI (yagni). Un bon ensemble d'outils de migration peut être beaucoup plus efficace

• Lorsque vous développez v1.0, essayez-vous de construire pour le rendre plus facile pour v2.0 d'être rétrocompatible avec v1.0? (Laissant les champs « réservés » est un exemple.)
  Pour les internes applications j'ai travaillé, non. parallèles est notre façon d'assurer une compatibilité ascendante « fonctionnelle ». Mais ce n'est pas une solution universelle.

• Comment décidez-vous que « Non, nous n'allons soutenir que plus » sur les caractéristiques
  Encore une fois, pour internes applications, le processus de décision peut être très différente de celle d'un un externe déployé. Si une fonction ne comporte pas de valeur ajoutée pour l'entreprise, une tâche « de cohérence » interne est configuré pour vérifier avec toutes les autres applications internes le coût de leur migration (à savoir « ne pas utiliser plus cette fonction »). La même tâche est beaucoup plus difficile à faire avec les clients à l'extérieur de votre organisation.

Answer 2

Plus votre système est utilisé au jour le jour, plus vous devriez vous concentrer sur elle.

Plus votre système est profondément ancré dans les processus de base de vos clients, plus vous devriez vous concentrer sur elle.

Plus votre système a des concurrents, plus vous devriez vous concentrer sur elle.

Les plus utilisateurs qui utilisent des versions plus anciennes, plus vous devriez vous concentrer là-dessus.

Le buy-in plus complexe et plus profond, il est pour un client à votre système, en termes de la taille d'un impact de votre logiciel a sur leur entreprise, plus vous devriez vous concentrer sur la compatibilité ascendante.

Si vous ne pouvez pas les aider le long sur les nouvelles versions grâce à des prix attractifs, etc., il pourrait être utile d'envisager le risque de forcer tout le monde.

Comme Vista ou Office 2007. C'était formidable pour me aider à Apple.

Answer 3

Mon point de vue sur la compatibilité ascendante du logiciel:

1.) Si son produit largement utilisé déjà par de nombreux clients, alors je vous assurer que la nouvelle version de ce produit est toujours en utilisant le même « code de base » (code qui permet d'obtenir des fonctionnalités de base de l'application en cours de développement) . Les nouvelles fonctionnalités devraient être prises en compte dans cette base de code ou construit sur le dessus de cette base de code avec aussi peu de changements nécessaires dans l'environnement d'exécution de cette application possible. Vous ne voulez pas faire vos utilisateurs existants effectuer beaucoup de changements dans leurs installations existantes. Ainsi son un compromis entre le soutien d'une nouvelle fonctionnalité et refonte dans la configuration existante et le processus d'utilisation pour le client.

2.) Dans un nouveau produit, si possible d'identifier toutes les fonctions possibles de cette bonne application au début avant même v1.0 est sorti. Identifier les fonctionnalités u vont à l'expédition dans v1.0. et ceux qui seraient conservés pour les versions ultérieures. Dans la mesure du possible, garder ces « caractéristiques de temps plus tard » à l'esprit tandis que la conception, la mise en œuvre du code, la finalisation de la sortie / de l'application pour tenir compte des caractéristiques dans les futures versions. par exemple. Laisser des éléments supplémentaires / champs de bits dans vos structures de données.

-AD.

Answer 4

Beaucoup. Si vous ne voulez pas emmerder chacun de vos clients fidèles!

Answer 5

Mon expérience est avec les systèmes d'emballage rétractable complexes avec relativement peu (100 - 5000). Utilisateurs
Le marketing a souvent l'avoir obtenu l'attitude sur la compatibilité ascendante sans une appréciation complète des coûts du cycle de vie. Par exemple, les économies pour maintenir des bugs dans votre système pour la base de l'utilisateur actuel peut facilement être éclipsés par les coûts de soutien pour les nouveaux utilisateurs sur la durée de vie du système.