C'e' una categoria di operazioni che in ogni gestionale merita un trattamento diverso da tutte le altre: quelle che scrivono su documenti fiscali, giacenze di magazzino o partite contabili.
Non perche' siano piu' difficili da scrivere. Perche' sono difficili da disfare. Una lista che si carica male si ricarica. Milleduecento fatture emesse con la numerazione sbagliata sono un problema che dura settimane e coinvolge il commercialista.
La regola
Ogni operazione che tocca soldi, magazzino o fisco deve poter essere eseguita in modalita' di prova, e la prova deve essere il comportamento predefinito.
La seconda meta' della frase e' quella che conta. Se la prova e' un'opzione da ricordarsi, prima o poi qualcuno non se la ricorda — di solito il giorno in cui il documento e' urgente e c'e' fretta. Se e' il comportamento normale, per fare danno bisogna dichiararlo esplicitamente.
$ php artisan fatture:emetti --dry-run
simulazione nessuna scrittura sul database
documenti 1.284 pronti
anomalie 3 · P.IVA non valida · righe 219, 604, 1102
Interrompo. Correggi le 3 e rilancia senza --dry-run.Cosa deve fare davvero una prova a vuoto
Non basta scrivere "modalita' di prova" e saltare le scritture. Una simulazione utile fa quattro cose.
Percorre lo stesso codice. Se la prova prende una strada diversa, non sta provando niente. La differenza deve stare in un punto solo, il piu' vicino possibile alla scrittura.
Dice i numeri. Quanti documenti, per quale importo totale, in che intervallo di numerazione. Sono i numeri che una persona puo' riconoscere come giusti o assurdi a colpo d'occhio.
Elenca le anomalie con la riga. Non "sono stati trovati errori", ma quali e dove. Un messaggio che non ti dice dove guardare ti costa piu' tempo del silenzio.
Si ferma da sola. Se ci sono anomalie, la prova finisce con un'interruzione, non con un avviso. La differenza fra un avviso e un blocco e' che l'avviso viene letto solo quando e' gia' tardi.
La parte che si dimentica sempre
La modalita' di prova va segnalata nell'interfaccia, non solo nella riga di comando.
E' un errore che abbiamo fatto e corretto: un sistema in cui l'invio verso un servizio esterno era in modalita' di prova, ma il messaggio a video diceva comunque "salvato anche sul sistema esterno". La chiamata non era mai partita. Nessuno se n'e' accorto per settimane, perche' il software rassicurava.
Un sistema che sbaglia rumorosamente costa un pomeriggio. Un sistema che sbaglia in silenzio costa mesi, e si scopre sempre nel momento peggiore.
Il caso peggiore: fallire senza dirlo
Un difetto della stessa famiglia, trovato leggendo del codice che girava da tempo. Una funzione registrava un allarme quando un campo spariva dal sistema di origine, ma scriveva su una colonna che nel database non esisteva. Il tutto stava dentro un blocco che catturava gli errori e li mandava solo nel file di log.
Risultato: il campo spariva, l'importazione continuava con dati incompleti, l'allarme non veniva mai salvato, il pannello restava vuoto. Il sistema stava dicendo "tutto bene" mentre importava record a meta'.
Da li' una seconda regola, gemella della prima: il codice che serve ad accorgersi dei guasti non puo' stare in un blocco che ingoia gli errori. Se l'allarme non riesce a suonare, deve essere l'allarme successivo.