Un’operazione che modifica centinaia di record può rispettare le proprie regole e, comunque, coinvolgere più dati del previsto. Una conferma generica — «Sei sicuro?» — non permette di valutare la portata dell’intervento né di rilevare condizioni inattese. Un’anteprima delle modifiche in PHP deve mostrare quali record sarebbero interessati, quali valori cambierebbero e a quali condizioni è possibile eseguire l’operazione.
L’anteprima riduce le sorprese, ma non garantisce che l’esecuzione successiva produca esattamente lo stesso risultato. Tra le due fasi possono cambiare i dati, le autorizzazioni o la portata dell’operazione. La progettazione deve rendere visibile questa incertezza e prevedere una nuova convalida di quanto necessario prima della scrittura.
Quando un’anteprima è utile
È opportuno valutare un’anteprima per operazioni in blocco, sensibili o difficili da annullare: aggiornare i prezzi, cambiare stati, riassegnare account, eliminare informazioni o ricalcolare dati derivati. È utile anche quando la persona che avvia l’attività deve valutarne l’impatto o ottenere un’approvazione prima di eseguirla.
Non tutte le azioni richiedono un’interfaccia di anteprima. Se un’operazione è di portata ridotta, reversibile e ha un risultato inequivocabile, può bastare una conferma contestuale. Se invece l’utente non può sapere cosa comporti la conferma, il problema richiede di mostrare dati concreti, non di aggiungere un’altra finestra di dialogo.
L’anteprima non sostituisce neppure un backup, un meccanismo di rollback o una policy di approvazione. Se un errore può avere conseguenze gravi, occorre valutare controlli aggiuntivi, come l’approvazione da parte di un’altra persona, un’esecuzione graduale o un processo di ripristino collaudato.
Separare il calcolo dall’applicazione
La regola di business deve poter calcolare una proposta senza modificare il database. Una strategia pratica consiste nel condividere la selezione e il calcolo tra due modalità: una che descrive la modifica e una che la applica. Evitare due implementazioni indipendenti riduce il rischio che l’anteprima e l’esecuzione interpretino le regole in modo diverso.
Per ogni elemento interessato, la proposta può includere:
- Un identificatore che consenta di riconoscere il record.
- I valori attuali rilevanti e quelli previsti.
- Il motivo dell’inclusione o dell’esclusione.
- Le convalide eseguite e i conflitti rilevati.
- La portata dell’operazione, ad esempio filtri, account o intervallo temporale.
Ad esempio, un’operazione che modifica lo stato degli ordini può mostrare lo stato attuale, quello proposto e il motivo per cui l’ordine è idoneo. Se gli elementi sono troppi per essere visualizzati tutti sullo schermo, si possono mostrare i totali e un campione, chiarendo sempre cosa viene mostrato e consentendo, quando necessario, di esaminare o esportare i dettagli.
In PHP, è opportuno racchiudere selezione e calcolo in componenti con responsabilità chiare. Un servizio di dominio può produrre le modifiche proposte; un altro componente può presentarle; una route applicativa può occuparsi di convalidarle e persisterle. L’anteprima non dovrebbe eseguire indirettamente una scrittura come effetto collaterale della lettura.
Convalidare dati, autorizzazioni e portata
Una proposta utile spiega non solo cosa cambierebbe, ma anche perché la modifica è consentita. Convalida le condizioni di business sui dati attuali e verifica che l’utente sia autorizzato a visualizzare ed eseguire l’operazione. L’autorizzazione a consultare i record non implica necessariamente quella a modificarli.
La portata deve essere esplicita. Se l’azione dipende da filtri, da una selezione o dal caricamento di un file, registra questi parametri in modo comprensibile e comunica limiti, esclusioni ed errori. Evita che una ricerca troppo ampia o un filtro omesso trasformi accidentalmente un’azione circoscritta in una modifica globale.
Occorre inoltre indicare cosa non è possibile prevedere con certezza. L’anteprima non anticipa automaticamente le modifiche effettuate da altri processi, le regole eseguite in sistemi esterni né gli effetti collaterali che dipendono dallo stato futuro. Se sono presenti integrazioni, code o calcoli successivi, descrivi questi effetti separatamente e non presentarli come parte certa del risultato.
Evitare di applicare una proposta obsoleta
Un’anteprima rappresenta i dati in un momento specifico. Se questi cambiano prima dell’esecuzione, un ordine potrebbe non soddisfare più le condizioni, un utente potrebbe perdere le autorizzazioni oppure un record potrebbe essere stato aggiornato da un altro processo. Per questo, il risultato mostrato non deve essere trattato come un’autorizzazione permanente alla scrittura.
Al momento dell’esecuzione, verifica nuovamente le condizioni che determinano l’idoneità e le autorizzazioni. A seconda del caso, puoi confrontare la versione del record, un timestamp o i valori rilevanti con quelli osservati al momento del calcolo della proposta. Se ci sono discrepanze, non applicare silenziosamente una decisione diversa: segnala il conflitto e chiedi di generare una nuova anteprima o di risolverlo in modo esplicito.
Nei processi che richiedono una corrispondenza rigorosa, conserva un riferimento alla proposta e verifica che l’applicazione continui a rispettarne la portata e le regole. Una transazione può proteggere un insieme di scritture dagli errori intermedi, ma da sola non elimina il tempo trascorso tra l’anteprima e l’esecuzione. La strategia di concorrenza deve essere adeguata al rischio e al volume dell’operazione.
Eseguire in batch e registrare i risultati
Per volumi elevati, applicare tutto con una sola operazione può aumentare i tempi di blocco e rendere più difficile il ripristino. Definisci limiti di batch adeguati al database e al comportamento dell’applicazione. In caso di errori parziali, l’utente deve poter distinguere i record applicati, quelli ignorati e quelli che richiedono una revisione.
Registra informazioni sufficienti per indagare sul risultato: chi ha avviato e approvato l’operazione, quando è stata preparata ed eseguita, quale portata è stata richiesta, quanti elementi sono stati elaborati e quali errori si sono verificati. Evita di memorizzare dati personali o valori sensibili senza necessità; anche i log di audit devono rispettare i controlli di accesso e i requisiti di conservazione applicabili.
Se l’operazione viene ripetuta, considera l’idempotenza: ripetere una richiesta non dovrebbe duplicare effetti imprevisti. Un identificatore dell’operazione e i relativi stati di esecuzione possono aiutare a riconoscere le richieste ripetute e a separare preparazione, approvazione, esecuzione e completamento. Non presentare il deployment del codice come equivalente al rilascio o all’abilitazione dell’operazione: sono decisioni distinte e devono avere controlli propri.
Verificare che l’anteprima non modifichi i dati
I test devono verificare sia il calcolo sia l’assenza di scritture in modalità anteprima. Usa dati rappresentativi per verificare inclusioni, esclusioni, valori attuali e proposti, autorizzazioni insufficienti e convalide non superate.
Verifica inoltre che l’esecuzione applichi la proposta prevista e che le modifiche concorrenti producano il comportamento definito. Quando pertinente, prova gli errori all’interno di un batch, i tentativi successivi e gli errori di integrazione. I test di integrazione con il database sono importanti: un test unitario del calcolo non dimostra che una route di anteprima sia priva di effetti collaterali.
I casi limite devono includere filtri vuoti, volumi elevati, record eliminati o modificati tra le due fasi e utenti con diversi ambiti di accesso. È inoltre opportuno verificare che l’interfaccia non affermi «saranno aggiornati esattamente questi elementi» se l’applicazione ricalcolerà l’insieme al momento dell’esecuzione.
Checklist per decidere quali controlli servono
- L’operazione interessa molti record, ha effetti difficili da annullare o richiede un’approvazione?
- Vengono mostrati la portata, gli elementi interessati e i valori attuali e previsti?
- L’anteprima è separata dalle scritture e dai relativi effetti collaterali?
- Le autorizzazioni, le regole di business e i dati vengono convalidati sia in fase di preparazione sia in fase di esecuzione?
- Vengono rilevate le modifiche rilevanti avvenute tra le due fasi?
- Sono previsti limiti di batch, una gestione definita degli errori parziali e log di audit adeguati?
- I test confermano che l’anteprima non modifica i dati e che l’esecuzione rispetta il risultato convalidato?
Un’anteprima è adeguata quando aiuta a prendere una decisione informata e i suoi limiti sono chiari. Se non è possibile fornire una stima affidabile dell’impatto, è preferibile ridurre la portata, eseguire prima l’operazione in un ambiente controllato o richiedere un’ulteriore revisione, invece di trasformare una cifra o un elenco parziale in una promessa sul risultato.
