Mesmo o provedor substituto escolhido com mais cuidado vai diferir do original em pelo menos alguns pequenos aspectos, e encontrar essas diferenças antes que apareçam em produção é um exercício bem diferente de descobri-las depois que um cliente relata algo errado. Uma abordagem estruturada de comparação de esquemas detecta a maioria dessas diferenças cedo, a baixo custo e sem drama.
Um bom ponto de partida é distinguir três categorias de diferença, já que cada uma pede uma resposta diferente:
Diferenças de presença de campos. Um campo que o seu código lê pode estar presente na resposta de um provedor e ausente, ou presente apenas sob certas condições, na de outro. Esta é a categoria mais fácil de detectar por comparação estática: pegue uma resposta de exemplo de cada provedor para a mesma entrada e compare diretamente as listas de campos.
Diferenças de tipo ou de formato de campos. O mesmo valor conceitual pode ser representado de formas diferentes: uma coordenada como dois campos numéricos separados ou como uma única string combinada, uma pontuação de confiança como um número entre 0 e 1 ou como uma categoria ("high", "medium", "low"), ou um timestamp em um formato totalmente diferente. Para detectar essas diferenças, é preciso ler os valores reais, e não apenas os nomes dos campos.
Diferenças semânticas com nomes de campos idênticos. Esta é a categoria mais difícil, em que dois provedores usam exatamente o mesmo nome de campo, mas querem dizer coisas sutilmente diferentes com ele, como um campo "accuracy" que um provedor pontua com base na correspondência dos componentes do endereço e outro pontua com base em uma metodologia interna totalmente diferente. A comparação baseada apenas em nomes de campos não detecta isso; é preciso entender o que um valor realmente representa em cada sistema, normalmente lendo com atenção a documentação dos dois provedores, em vez de supor que um nome compartilhado implica um significado compartilhado.
Um processo prático: pegue uma amostra representativa de requisições históricas reais, idealmente cobrindo pelo menos seus padrões de requisição mais comuns e seus casos extremos conhecidamente difíceis, execute-as no provedor antigo e no novo e compare os resultados de forma sistemática, em vez de olhar alguns exemplos a olho. Automatizar essa comparação, mesmo como um script simples que sinalize qualquer diferença estrutural ou de valor significativa, compensa o tempo de preparação para qualquer integração que não seja muito pequena.
Os hosts de compatibilidade da My Geocode foram criados especificamente para minimizar as duas primeiras categorias de diferença em relação ao provedor que cada um reproduz, replicando exatamente a presença e o formato dos campos, exceto pelos textos de direitos autorais, termos e privacidade, como documentado para cada host em /docs/compatibility/. Isso deixa a terceira categoria, as diferenças semânticas sob um nome de campo compartilhado, como o principal ponto a testar diretamente, mesmo ao usar um host de compatibilidade, já que uma correspondência de formato nunca garante totalmente uma correspondência na metodologia subjacente.
Reservar tempo real para esse trabalho de comparação antes de considerar uma migração concluída, em vez de tratar como suficiente um teste bem-sucedido com alguns endereços comuns, é uma das formas mais confiáveis de evitar o tipo de problema sutil de qualidade de dados que leva semanas para ser percebido e ainda mais tempo para ser rastreado até sua causa real.