Migration

Les signes qui montrent que vous êtes enfermé dans un format propriétaire

La dépendance envers un fournisseur résulte rarement d'une décision unique. Elle s'accumule progressivement, un raccourci pratique après l'autre, jusqu'à ce qu'une base de code qui avait commencé par une intégration raisonnable avec un fournisseur soit discrètement devenue difficile à séparer de ce fournisseur. Quelques schémas précis méritent d'être reconnus comme des signaux d'alerte, car chacun, pris isolément, semble anodin au moment où il apparaît.

Les noms de champs exacts d'un fournisseur sont utilisés dans tout votre propre modèle de données. Si le schéma de votre base de données, les réponses de votre API interne et votre code front-end utilisent tous la convention de nommage d'un fournisseur précis, formatted_address, display_name ou quel que soit le nom que ce fournisseur a choisi, au lieu de vos propres noms traduits une seule fois à la frontière, chaque couche de votre application a absorbé une dépendance aux conventions de ce seul fournisseur.

Les particularités propres à un fournisseur ont été contournées dans la logique métier au lieu d'être isolées à la frontière d'intégration. Si un contournement lié à la façon particulière dont un fournisseur formate une adresse atypique se trouve dans la logique métier générale plutôt que dans la fonction étroite qui communique avec ce fournisseur, migrer implique de traquer et de démêler ce contournement dans du code qui, à première vue, n'a rien à voir avec le géocodage.

Personne ne sait dire rapidement combien d'endroits de la base de code font référence au fournisseur par son nom. Si répondre à la question « où dépendons-nous de ce fournisseur ? » exige un audit minutieux plutôt qu'une réponse rapide et assurée, cette incertitude est en soi un signe de dépendance, car elle signifie que la dépendance s'est étendue au-delà de ce que quiconque suivait activement.

Les types d'objets propres à la bibliothèque cliente sont utilisés dans les signatures de fonctions ailleurs dans le code. Si des fonctions sans rapport avec le géocodage acceptent en paramètre le type de réponse du SDK d'un fournisseur précis, le système de types de ce fournisseur fait de fait partie du système de types de votre application, et le supprimer oblige à modifier chaque fonction qui y fait référence, pas seulement le code de géocodage.

Aucune migration n'a jamais été testée, même partiellement, depuis des années que l'intégration est en service. Une intégration qui pourrait en théorie passer à un autre fournisseur mais qui n'a jamais été réellement essayée avec l'un d'eux ne diffère pas vraiment, en pratique, d'une intégration qui ne peut pas migrer du tout, tant que personne ne l'a réellement testée.

Aucun de ces schémas n'est catastrophique à lui seul, et la plupart des intégrations en présentent au moins un sans réelle conséquence pendant longtemps. L'intérêt de les reconnaître est de pouvoir faire de la dépendance un compromis délibéré et acceptable plutôt qu'un accident que personne n'a choisi. Parfois, la commodité vaut le couplage, en particulier pour un petit projet où une migration complète coûterait plus de temps d'ingénierie que ne vaut la flexibilité. Le problème n'apparaît que lorsque la dépendance s'installe de façon invisible et se découvre au pire moment possible, lors d'une migration forcée sous la pression d'une échéance, au lieu d'être reconnue et acceptée volontairement à l'avance.

Si un hôte de compatibilité existe déjà pour le fournisseur dont vous dépendez actuellement, une partie de ce risque est naturellement moindre, car 17 hôtes de compatibilité signifient qu'au moins une voie de migration probable n'exige pas du tout de démêler une dépendance au niveau des champs, seulement un changement d'hôte et de clé. C'est une assurance raisonnable à avoir en place, même pour une intégration que vous n'avez aucun projet immédiat de migrer.