Quanto dettagliato dovrebbe essere l'output di convalida? [chiuso]

Question

Ho un'applicazione che legge un database e genera avvisi per eventuali dipendenze che non vengono soddisfatte. La mia opinione su questo problema è & Quot; Fornire le informazioni minime che indicano all'utente il problema. & Quot; Mi è stato detto da un collega che dovrei essere il più prolisso possibile, stampando i valori dei campi del database per ogni campo di cui parlo versetti dando il messaggio minimo che & Quot; il campo uno deve essere inferiore al campo due quot &;.

So che ci devono essere alcune convenzioni o standard per questo problema in quanto mi ricorda errori e avvertenze del compilatore. Qualcuno sa come vengono scelti i messaggi di un compilatore?

Quali suggerimenti ha la community per questo problema?

Answer 1

Quando scrivi, conosci il tuo pubblico.

Se stai registrando messaggi di avviso / errore per il tuo consumo, allora è abbastanza facile: cosa tu devi sapere quando qualcosa va storto?

Se stai registrando messaggi di avviso / errore per qualcun altro, le cose si complicano. Cosa sanno? Come appare il loro modello mentale del sistema? Quali tipi di problemi possono risolvono e di quali informazioni hanno bisogno per risolverli?

Inserire tutti gli ultimi frammenti di dati in un messaggio è puntuale: nella migliore delle ipotesi, il lettore dovrà guadare informazioni irrilevanti per trovare ciò di cui ha bisogno; nel peggiore dei casi, diventeranno confusi e finiranno per prendere decisioni basate sui dati errati .

L'analogia del compilatore è appropriata: pensa a quanto sarebbe fastidioso se l'intera tabella dei simboli fosse scaricata insieme ad ogni avviso ...

Answer 2

Penso che la chiave sia concisa. Inserisci tutti i dettagli richiesti per il motivo della comunicazione dell'avviso e niente di più.

Answer 3

Per il normale funzionamento quotidiano, do un messaggio di convalida dei dati che fornisce informazioni sufficienti affinché l'utente possa risolvere il problema, in modo che i dati vengano convalidati. Ad esempio, se ho due campi (campo A e campo B) e uno di essi deve essere maggiore dell'altro, lo direi sull'output di convalida, specificando quale campo è il campo offensivo.

Ad esempio, se A deve essere maggiore di B e forniscono una risposta inferiore a B, il messaggio sarebbe " il campo A deve essere maggiore del campo B "

Detto questo, programma anche una modalità di debug nelle mie applicazioni (specialmente le applicazioni web) che ha una modalità dettagliata, che dice esattamente cosa sta succedendo con tutto. Se attivato, visualizzerai due messaggi, l'errore intuitivo e quindi & Quot; FieldA = XX e FieldB = YY: XX non è maggiore di YY & Quot ;.

È semplificato, ma è l'idea generale.

Answer 4

Suggerirei di implementare entrambe le modalità. Durante il normale funzionamento è necessario un messaggio utile ma breve. Ma a volte le cose potrebbero andare storte e in questo caso una modalità 'dump' che fornisce all'utente tutte le informazioni possibili è un salvavita.

Answer 5

Penso che ci siano 3 livelli dei dettagli di un messaggio di errore per i 3 gruppi di utenti tipici:

1. L'utente finale. Questo è un surfista su un sito web o un utente di un'applicazione desktop. Dovrebbe ricevere un messaggio di errore se il problema non può essere compensato. Dovrebbe includere il minimo di informazioni. L'utente finale non dovrebbe ricevere alcuna informazione sul sistema come la configurazione corrente e i percorsi dei file. L'utente finale deve contattare l'amministratore. Un ID di errore continuo può essere utile per consentire all'amministratore di trovare ulteriori informazioni.
2. L'amministratore ha bisogno di informazioni più utili per risolvere il problema da solo. Può includere informazioni come la tabella xy non fonte o l'accesso al database non riuscito.
3. Lo sviluppatore: se l'amministratore non è in grado di risolvere il problema, contatterà il fornitore del software. In questo caso l'amministratore dovrebbe essere in grado di inviare un file di registro che lo sviluppatore può risolvere anche se non è in grado di riprodurre il problema.

Answer 6

È possibile discutere le specifiche del contenuto di un registro, ma è mia esperienza che il livello di verbosità sarà rapidamente determinato durante stress test .
Se il sistema non può funzionare correttamente, è solo perché:

• diventa troppo dettagliato con i tuoi registri o
• ha effettuato l'accesso troppo spesso (in realtà, credo Jeff stesso ha avuto un problema simile )

  

Atwood : stavamo registrando in modo tale che il registro .... durante la chiamata di registro stia attivando un'altra chiamata di registro. Il che di solito va bene, ma con il carico che abbiamo, alla fine accaderebbero così vicini che c'è anche un lucchetto. Quindi, ci sono due blocchi in corso lì.

     

Spolsky : [...] hai la tendenza a voler registrare tutto. Ma poi ottieni solo registri che sono, sai, cento megabyte per utente e ne ottieni trenta al minuto e non è possibile analizzarli o memorizzarli in modo ragionevole. Quindi la prossima cosa che devi fare è iniziare a cancellare i tuoi registri o semplicemente avere diversi livelli di debug, dove è come in modalità di debug alta tutto è registrato e in modalità di debug bassa nulla è registrato. E ... è un po 'difficile capire cosa vuoi davvero in un registro.

     

Atwood : intendo dire che, ironicamente, per risolvere questo blocco, che si è rivelato essere dovuto al log, stavamo aggiungendo altro log.

     

Spolsky : [ride]

     

Atwood : la battuta si scrive da sola! Lo scherzo si scrive da solo, giusto ...

Quindi il mio punto è, quando eseguirai il tuo sistema in un ambiente simile alla produzione, dovresti essere in grado di determinare rapidamente se il livello di verbosità che scegli è sostenibile.

Answer 7

Gestione degli errori vs. avvertenze prima: dovrebbe esserci un errore per qualcosa che viola lo standard. Un avvertimento dovrebbe essere per qualcosa che è permesso, ma molto probabilmente non è quello che intendeva l'autore.

Ad esempio, il W3C Markup Validator avviserà dell'uso della sintassi < br / > in un documento HTML. In XHTML questo significa & Quot; Un'interruzione di riga & Quot ;, ma in un documento HTML, pur essendo consentito, in realtà significa & Quot; Un'interruzione di riga seguita da un segno maggiore di & Quot; (anche se la maggior parte dei browser non lo rispetta).

Per quanto riguarda la verbosità, ciò che è meglio dipende da chi sta usando il sistema. Alcuni utenti starebbero meglio con brevi messaggi che possono sfogliare, mentre altri utenti (forse quelli meno avanzati) troveranno utili le informazioni aggiuntive. Senza sapere di più su chi sono, tenderei ad usare un flag (-v è tradizionale) per consentire all'utente di selezionare quale versione preferisce.