Una formula può essere corretta. Una query può funzionare senza errori. Una macro può arrivare regolarmente alla fine.
E il risultato può comunque essere sbagliato.
Il problema, in molti casi, non è nella logica che elabora i dati, ma nei dati che quella logica ha ricevuto.
Per questo, in un file destinato a essere utilizzato nel tempo, la validazione non dovrebbe essere un controllo aggiunto alla fine. Dovrebbe essere parte del processo.
Un dato sconosciuto non è necessariamente un dato vuoto
Supponiamo di utilizzare un’anagrafica per associare una categoria a un codice.
Arriva un nuovo codice che non è ancora presente nell’anagrafica. La ricerca non trova corrispondenza.
È molto comodo intercettare l’errore e restituire una stringa vuota, uno zero o una categoria predefinita. Il foglio rimane pulito e le elaborazioni successive continuano a funzionare.
Ma abbiamo perso un’informazione importante: è comparso un caso che il nostro sistema non conosce.
Nascondere l’errore non significa averlo gestito.
Le anagrafiche possono diventare anche regole di controllo
Nel momento in cui separiamo la logica dalle anagrafiche, come visto nell’articolo precedente, quelle stesse tabelle possono assumere una seconda funzione.
Non servono soltanto a dire che al codice X corrisponde la descrizione Y. Possono anche definire quali codici il sistema conosce e sa elaborare.
Un codice non presente nell’anagrafica diventa quindi un’anomalia da evidenziare, non necessariamente un errore da nascondere.
È una differenza piccola nell’implementazione, ma importante nel modo di progettare il file.
Anche un’anagrafica può essere sbagliata
Validare i dati in ingresso non basta.
Supponiamo che una tabella di supporto debba contenere una sola riga per ciascun codice. Se qualcuno inserisce accidentalmente lo stesso codice due volte, una ricerca che presuppone una relazione univoca può produrre un risultato inatteso.
Il dato sorgente è corretto. La formula è corretta. È l’anagrafica ad avere violato una regola.
Per questo alcuni controlli dovrebbero riguardare anche le strutture utilizzate per controllare gli altri dati: chiavi duplicate, campi obbligatori mancanti, intervalli di validità sovrapposti o combinazioni che non dovrebbero esistere.
Non tutti i vuoti sono uguali
Una cella vuota può significare molte cose.
Il dato non è stato compilato. Non è disponibile. Non è previsto per quel tipo di record. Deve ancora essere calcolato. Oppure rappresenta perfettamente una condizione ammessa.
Trattare tutti questi casi nello stesso modo è rischioso.
Prima di sostituire automaticamente un valore mancante con zero, "" o un valore predefinito, conviene chiedersi se l’assenza del dato sia prevista dalla logica oppure rappresenti qualcosa che deve essere verificato.
Lo zero, il valore vuoto e il valore sconosciuto non sono necessariamente sinonimi.
Le regole possono dipendere dal contesto
Non sempre è sufficiente controllare una singola colonna.
Un valore può essere perfettamente valido preso da solo e diventare impossibile quando viene associato a un altro.
Un certo tipo di operazione può ammettere solo alcuni stati. Una categoria può essere utilizzabile soltanto con determinati codici. Un record può essere valido oggi ma non esserlo rispetto alla data a cui si riferisce l’elaborazione.
La validazione diventa quindi progressivamente più interessante quando passa dal semplice controllo del valore al controllo della coerenza tra valori.
Controllare prima, non spiegare dopo
C’è una differenza sostanziale tra scoprire un’anomalia prima di produrre il risultato e trovarla quando qualcuno si accorge che un totale non torna.
Nel secondo caso bisogna risalire all’origine del problema attraversando tutte le trasformazioni che il dato ha subito.
Nel primo possiamo fermarci molto prima: dato → controllo → elaborazione, anziché dato → elaborazione → risultato anomalo → ricerca della causa.
Non significa necessariamente bloccare tutto al primo problema. In molti casi è più utile produrre una tabella delle anomalie e lasciare che il processo distingua ciò che può essere elaborato da ciò che richiede attenzione.
Rendere visibili le anomalie
Un buon controllo non dovrebbe limitarsi a dire che “qualcosa non va”.
Se possibile dovrebbe permettere di capire quale record ha generato l’anomalia, quale regola non è stata rispettata, quale valore l’ha provocata e se il problema impedisce l’elaborazione oppure è soltanto una segnalazione.
Questo approccio è particolarmente utile con Power Query, dove i controlli possono confluire in una tabella dedicata, ma lo stesso principio può essere applicato con formule Excel o VBA.
La tecnologia cambia. Il principio no.
Non serve controllare tutto
Aggiungere controlli a ogni passaggio può rendere una soluzione pesante quanto non averne nessuno.
La validazione dovrebbe concentrarsi sui punti in cui un dato inatteso potrebbe produrre un risultato formalmente valido ma sostanzialmente sbagliato.
È qui che il controllo ha il valore maggiore.
Un errore evidente tende a farsi trovare. Un numero plausibile, prodotto partendo da un presupposto sbagliato, può invece attraversare indisturbato tutto il processo.
Per questo, tra un foglio che nasconde elegantemente ogni anomalia e uno che segnala chiaramente ciò che non riconosce, preferisco il secondo.
Meglio un’anomalia esplicita che un risultato apparentemente corretto.