Meilleures pratiques pour la compatibilité héritée [fermé]

Question

D’après mon expérience, les engagements en matière de compatibilité amont / aval sont la cage dorée de la industrie du génie logiciel. J'ai particulièrement observé que c'était le cas des formats de fichier de document et des langages de programmation / API. Les clients et les partenaires détestent cela lorsque leurs données ou leur code existants sont brisés. cependant, si vous ne cassez jamais la compatibilité, vous pouvez sérieusement limiter votre capacité à innover à long terme.

Existe-t-il des solutions à ce problème autres que la dépréciation progressive d'anciennes fonctionnalités? Il semble que la virtualisation, comme dans le mode XP de Windows 7, soit une possibilité excitante. Y en a-t-il d'autres?

De plus, pour ceux d'entre nous qui souhaitent concevoir de nouveaux systèmes aussi résistants que possible à l'avenir, quelles leçons pouvons-nous tirer des erreurs passées dans l'industrie?

Answer 1

Innovez en étendant et non en réécrivant les API publiques. Disposer d'interfaces publiques génériques cohérentes avec les fonctionnalités principales. Vous pouvez réécrire des modules privés à tout moment, à condition de fournir aux modules d'API publics les résultats escomptés.

Faites vos améliorations dans le back-end et laissez l'API cohérente autant que possible. Créez de nouveaux modules et documentez-les clairement lorsque vous étendez les parties publiques de votre API. La dépréciation des anciennes méthodes deviendra naturelle si vous fournissez de nouvelles et meilleures méthodes pour faire des choses qui viennent s'ajouter aux anciennes.

Pour les formats de document, incluez toujours les numéros de version et assurez-vous de pouvoir prendre en charge toutes les versions existantes. Comme pour les API, ajoutez la nouvelle fonctionnalité en développant et non en réécrivant.

Lorsque vous souhaitez apporter des modifications fondamentales à l’architecture globale de votre logiciel, incluez l’ancienne version sous forme de module, ce qui permettra une plus grande taille, mais un meilleur support des anciennes données et programmes.

Answer 2

Utilisez XML comme base pour votre format de fichier et ajoutez-le uniquement à la définition DTD de la spécification, ne supprimez pas. De cette façon, vos fichiers devraient être rétrocompatibles avec les versions précédentes, ce qui est un avantage.

Answer 3

Voici un bon exemple: utilisation des ponts SLF4J pour faciliter la migration à partir d'un module de journalisation. à un autre en Java.