Idea principale

Quando un controllo è applicato solo dall'interfaccia — un tetto massimo di sconto verificato nel modulo di inserimento e da nessun'altra parte —, sono possibili soltanto due letture, ed entrambe sono scostamenti.

O è una vera regola di business, messa nel posto sbagliato: dovrebbe vivere dove vivono le regole, e la sua presenza nella schermata è un difetto di progettazione su cui decidere. Oppure è aggirabile — con un import di file, attraverso l'interfaccia che il prodotto espone agli sviluppatori esterni — e allora è un difetto con implicazioni di sicurezza: quello che la schermata vieta, un altro percorso lo consente.

Il caso inverso si tratta allo stesso modo. Una regola applicata dal cuore del codice che la schermata non riflette produce un rifiuto incomprensibile: l'utente si vede respingere l'azione senza vedere cosa ha sbagliato.

Perché è importante

Trasforma la lettura delle schermate — di solito relegata alla fine, quando viene fatta — in una macchina per trovare scostamenti. Il rendimento è alto perché la domanda non richiede alcun giudizio: basta constatare che una regola non ha una gemella lato server.

E fornisce un argomento per non saltare questa lettura quando il tempo stringe: è la parte del prodotto che rende di più per ora spesa.

Sfumature e limiti

«Quasi sempre»: un aiuto all'inserimento senza alcuna portata di business — un formato di data suggerito, un campo nascosto per alleggerire la schermata — non è una regola e non diventa uno scostamento.

L'aggiramento presuppone un altro percorso effettivamente aperto. Su un prodotto senza import né interfaccia esterna, resta in gioco solo il primo caso — la regola di business messa nel posto sbagliato.

Domande aperte

• Una volta riportata la regola lato server, che ne è del controllo di inserimento: duplicazione assunta per comodità dell'utente, o fonte di divergenze future?