I piccoli territori e i codici speciali sono il punto in cui un modello di dati dei paesi scopre quanto del suo design fosse un presupposto. Il set di dati funziona meravigliosamente per i luoghi grandi, inequivocabili e ben documentati, poi arriva una dipendenza, un dipartimento d’oltremare o un codice riservato e qualcosa deve cedere.
Il valore di questi casi è che sono economici da aggiungere e insolitamente bravi a smascherare problemi strutturali. Un modello che li gestisce ha di solito reso esplicite diverse decisioni importanti.
Perché il presupposto del codice di due lettere si rompe?
Perché i sistemi di codici sono stati progettati per scopi che non richiedono tutti un codice di due lettere per ogni luogo. Il sistema a due lettere è quello familiare, ma esistono anche un sistema a tre lettere e un sistema numerico, e ciascuno esiste per risolvere un problema diverso. Il sistema numerico in particolare è nato per evitare l’ambiguità delle lettere tra le lingue.
La codifica delle suddivisioni aggiunge un altro livello. Alcuni luoghi appaiono solo come suddivisioni all’interno di un’entità più grande invece che come entità a sé stanti, e alcuni appaiono in un sistema ma non in un altro. Un modello che tratta il codice di due lettere come chiave primaria del mondo semplicemente non avrà uno spazio per quei luoghi.
La conseguenza pratica è che la chiave primaria dovrebbe essere qualcosa che il tuo sistema controlla, non un valore preso in prestito da uno standard che ha le proprie decisioni di ambito. Il codice standard diventa allora un attributo: importante, ricercabile, ma sostituibile quando la situazione lo richiede.
Cosa dovrebbe succedere ai codici riservati e ritirati?
I codici vengono aggiunti, riservati per un uso futuro e ritirati. I codici ritirati non scompaiono dal mondo; restano nei record storici, nei documenti archiviati e nei vecchi database, e continueranno ad arrivare negli import molto tempo dopo che il codice è stato ritirato.
Un sistema deve decidere cosa farne. Rifiutarli del tutto rompe la capacità di leggere la storia. Accettarli silenziosamente come attuali inventa un fatto sul presente. La via di mezzo praticabile è accettarli con un contrassegno che dica che non sono attuali, e mantenere quella distinzione visibile ovunque il valore venga visualizzato.
La stessa logica vale per i codici che sono stati riservati prima di essere mai usati. Un codice riservato non è un errore; è una lacuna nella numerazione che qualcuno ha scelto deliberatamente, e una regola di convalida che lo rifiuta come malformato sbaglia sullo standard invece che sull’input.
Nomi precedenti e i nomi che un luogo usa per sé stesso
I nomi cambiano, e il cambiamento raramente è simultaneo ovunque. Per un periodo, un nuovo nome è ufficiale mentre il vecchio nome è ancora ciò che contengono la maggior parte dei documenti, e per i nomi di luogo la forma locale e la forma internazionale differiscono spesso.
Tre tipi di nome devono quindi essere distinti. Il nome ufficiale attuale, il nome che appare nei record più vecchi e il nome usato localmente da chi ci vive. Un sistema che ne conserva solo uno dei tre sarà sbagliato in una direzione o nell’altra, e quale direzione dipende da chi legge.
Questo è un punto in cui pulire i dati può distruggerli. Un passaggio di normalizzazione ben intenzionato che riscrive ogni record storico con il nome attuale fa concordare l’archivio con il presente e smettere di concordare con sé stesso.
Non applicabile non è la stessa cosa di sconosciuto
I piccoli territori rendono questa distinzione impossibile da ignorare, perché sono i casi in cui un campo genuinamente non si applica.
Un campo che non si applica significa che il concetto non esiste per quel luogo, quindi non c’è nulla da cercare e nessun valore corretto. Un campo sconosciuto significa che il valore esiste e non è ancora stato stabilito. Questi due producono la stessa cella vuota e richiedono risposte opposte, e una checklist che li registra come uno solo continuerà a produrre lavoro che non può essere completato.
Dove il campo è un sistema di codice postale, la differenza è netta. La guida ai formati dei codici postali per paese copre quanto il campo vari tra i luoghi. La situazione di ogni paese deve essere classificata prima che qualsiasi convalida la tocchi, perché un sistema che presume che un campo esista contrassegnerà ogni voce senza di esso come incompleta, e un sistema che presume che possa non esistere accetterà input genuinamente errati.
Non supportato non è la stessa cosa di malformato
Questa è la distinzione che più spesso si perde, ed è quella con il costo più chiaramente visibile all’utente.
Un valore che un sistema non supporta non è un valore sbagliato. Può essere perfettamente ben formato per il proprio luogo, in un formato che il sistema semplicemente non è mai stato istruito a gestire. Segnalarlo all’utente come non valido gli dice che ha commesso un errore quando in realtà il limite è dalla parte di chi riceve.
| Cosa ha trovato il sistema | Cosa sa | Cosa dovrebbe dire |
|---|---|---|
| Un valore che segue le regole che implementa | Il valore è valido | Accettalo |
| Un valore che segue regole che non implementa | Il valore può benissimo essere valido | Non verificabile qui |
| Un valore che infrange regole che implementa | Il valore è non valido | Segnala il problema specifico |
| Un campo che non esiste per questo luogo | Non c’è nulla da verificare | Non applicabile, non mancante |
Ridurre a una le due righe centrali è il guasto comune. Produce un prodotto che è con sicurezza sbagliato esattamente nei punti in cui la sua conoscenza è più sottile, e i clienti di quei luoghi sono i primi a notarlo.
Per gli sviluppatori: rendere esprimibile il terzo stato
Un esito binario valido o non valido non può rappresentare “non verificato qui”, quindi il risultato della convalida ha bisogno di un terzo valore che si propaghi onestamente all’interfaccia. È un cambiamento di tipo più che un cambiamento di regola, ed è per questo che tende a essere saltato sotto pressione di tempo e rimpianto in seguito.
Poi testa i casi limite di proposito. Includi un luogo il cui codice appare solo in un sistema, un codice che è stato ritirato, un luogo senza sistema di codice postale e un nome che è cambiato. Questi quattro casi sono piccoli, veloci e insolitamente produttivi, e vale la pena tenerli nella suite in modo permanente invece di aggiungerli quando arriva un ticket.
La directory dei paesi e delle regioni è un luogo ragionevole per vedere come un paese e le sue suddivisioni sono visualizzati quando sono trattati come voce di prima classe invece che come eccezione, e la voce degli Stati Uniti mostra come appare una voce completamente specificata accanto a una più esile.
I territori, i codici, i nomi e gli stati dei campi usati in questo articolo sono casi limite costruiti, assemblati per illustrare un problema di design. Non sono un set di dati, non rappresentano la classificazione effettiva di alcun territorio reale, e nulla qui dovrebbe essere citato come un fatto su un luogo specifico.
Passi successivi
Aggiungi i quattro casi limite sopra alla tua suite e vedi quali di essi producono una risposta sbagliata invece che una non gestita. La guida a scegliere i paesi per i dati di test spiega come collocare deliberatamente tali casi in un insieme predefinito, e la guida agli scenari di indirizzo transfrontaliero copre cosa succede quando un luogo come questi appare come uno di diversi paesi in una singola transazione.