Idea principale

Uno sviluppatore che rifiuta un'azione crea un caso d'errore, e gli dà un nome. CannotEditInvoicedOrder dice «non si può modificare un ordine fatturato»: la regola intera sta nel nome, senza commenti né documentazione. Nessuno ha scritto quel nome per documentare alcunché — era il modo più rapido di designare il rifiuto nel momento in cui lo si programmava.

Da qui un giacimento inatteso nelle parti del codice meno ordinate, quelle in cui nessuna regola è enunciata in chiaro: la lista dei nomi dei casi d'errore. Si legge senza saper programmare, perché si tratta solo di leggere dei nomi.

Altri tre posti producono regole, in ordine di rendimento decrescente: le verifiche fatte all'inizio di un'operazione, prima che qualunque cosa venga modificata; i vincoli della base di dati — cosa deve essere unico, cosa non può restare vuoto; i controlli di inserimento nelle schermate.

Perché è importante

Apre la lettura delle regole a chi non legge il codice, ed è proprio chi ne ha bisogno — supporto, prevendita, product management. La barriera tecnica cade sulla parte del lavoro che si credeva la più tecnica.

Dà anche un ordine di attacco quando il tempo è contato: cominciare dagli errori, finire con le schermate, invece di scorrere i file.

Sfumature e limiti

Un nome d'errore scelto male enuncia una regola falsa con la stessa sicurezza di uno buono: la fonte è densa ma non verificata, e ogni regola che ne esce resta da confermare.

E l'assenza di casi d'errore non dice niente: un rifiuto può essere espresso in un altro modo, oppure non esistere da nessuna parte perché la regola non viene applicata. Un oggetto descritto senza nessuna regola segnala una descrizione superficiale, mai un business senza regole.

Domande aperte

• Che fare delle regole che non rifiutano niente — quelle che scatenano, calcolano o completano —, visto che non lasciano dietro di sé nessun nome?