Comment le code proprement séparez-vous pour la compatibilité ascendante du code principal?

Question

Je suis intéressé par ce que les gens stratégies ont mis au point pour séparer toute la logique crufty qui est nécessaire pour maintenir la compatibilité ascendante du code principal d'une application. En d'autres termes, les stratégies qui vous permettent de vous rapprocher d'avoir votre look de code comme s'il n'y avait pas de problèmes de compatibilité ascendante, sauf pour les fichiers source séparés isolés distinctement pour cette tâche.

Par exemple, si votre application lit un format de fichier particulier, au lieu d'une fonction d'analyse syntaxique du fichier klaxons géant, vous pourriez avoir votre premier code itérer une liste d'entrées « bizarreries » / objets, où chaque bizarrerie vérifie le fichier pour voir si il est un fichier, il s'appliquerait, et si oui invoque sa propre logique d'analyse au lieu de la logique de cas normal.

Quirks est une stratégie OK, mais vous devez travailler pour mettre des crochets dans des contrôles de bizarreries à tous les endroits appropriés dans votre application, et ce que les contrôles ressemblera varie pour les différents types de Quirk, etc. Il semble presque il devrait y avoir des bibliothèques dédiées à la boilerplate pour cette tâche. Une autre question est de savoir comment faire appliquer cette bizarreries ne sont pas maltraités comme des crochets à usage général en morceaux arbitraires de l'application.

Answer 1

Ma stratégie habituelle est d'avoir quelque chose de séparé qui se traduira par l'entrée de compatibilité descendante dans la nouvelle entrée de mise en œuvre, puis utiliser le nouveau code de mise en œuvre avec ces données traduites.

Answer 2

Cela dépendra du délai jusqu'à la retraite de ladite arrière caractéristiques de compatibilité. Il vous êtes assez sûr que dans quelques mois, vous allez libérer une autre version de votre logiciel qui n'aura plus d'avoir ces bizarreries, vous pouvez juste garder l'ancien code autour si vous êtes assez disciplinés pour enlever réellement toutes les cochonneries dans le prochain cycle de développement. Je maintiens deux composants du serveur de back-end séparés où je travaille et alors qu'ils ne peuvent pas être mis à jour en même temps, ils peuvent généralement être dans deux ou trois semaines d'intervalle. Cela signifie que la communication entre eux doit être rétrocompatible, mais seulement une seule version en arrière, et dans chaque version, je peux supprimer l'ancien code qui je suis parti pour des raisons de compatibilité ascendante dans la version précédente.

Si toutefois, la couche de compatibilité est là pour rester pendant longtemps, voire indéfiniment (pensez formats de fichiers binaires de Word) Je voudrais essayer de factoriser le code de telle sorte que la nouvelle fonctionnalité et la fonctionnalité ancienne sont sur un pied d'égalité en elle. Je pense à la fois l'ancien format (ou le comportement) et le nouveau format font partie des exigences du système et il n'y a aucune raison pour que l'ancien format d'être un citoyen de deuxième classe en elle (autre que d'être vieux qui est, jeu de mots).