Checklist di debug: quanto è necessario avere? [chiuso]

È una buona idea, ma il trucco diventa dove mettere la lista di controllo in modo che gli esperti di risoluzione dei problemi siano sicuri di saperlo e usarlo. Ad esempio, seguiamo un processo di sviluppo agile al lavoro. Ciò significa che a volte rilasciamo funzionalità per testarlo, ma non sono la versione user-friendly completa a cui stiamo lavorando alla fine.

Invitiamo tutti coloro che useranno la nuova funzione nella nostra demo. Presentiamo una lista di controllo per la risoluzione dei problemi, parliamo dei limiti, rispondiamo alle loro domande, rendiamo l'elenco disponibile a tutti. Poi, alcuni giorni dopo, quando iniziano effettivamente i test, riceviamo un sacco di telefonate, e-mail e segnalazioni di bug sulle cose che abbiamo inserito nella lista.

Poiché ha indicato Julia , le liste di controllo nei commenti di codice o in un file di documentazione non sono particolarmente utili. Queste informazioni per la risoluzione dei problemi devono essere inserite nel codice il più possibile. Se la licenza non è valida, hai almeno bisogno di un grande messaggio di errore che dice la tua licenza non è valida , ed è meglio se dice go qui per acquistare una licenza valida . Se il centro della mappa è una latitudine / longitudine non valida, hai almeno bisogno di un grande messaggio di errore che dice latitudine / longitudine non valida per il centro della mappa , ma è meglio se dichiari quali valori sono validi, come specifica un centro mappa entro i confini della Georgia .

In altre parole, è il tuo lavoro per abilitare la risoluzione dei problemi della tua applicazione senza usare una lista di controllo.

Posso vedere due aspetti.

1. Con la maggior parte delle funzioni c'è un tipo di contratto che deve essere soddisfatto dal chiamante. Questo dovrebbe essere descritto nella documentazione. Questa documentazione può assumere molte forme diverse. È molto comune trovare commenti nel codice sorgente che spieghi lo scopo della funzione, i parametri e i valori di ritorno. Puoi ottenere un software che estrae questi commenti e genera un file di guida con collegamento ipertestuale, se lo desideri.

   Se non riesci a far funzionare il modulo Mappa (dal tuo esempio), inizi a guardare questa documentazione per vedere se la stai usando correttamente.

2. Non c'è niente di sbagliato nello scrivere una FAQ o una lista di trouble-shooting per particolari librerie, ma questo dovrebbe essere solo se necessario. Il problema di avere una politica che ogni biblioteca deve avere una tale lista è che alcuni semplicemente non ne hanno bisogno e tu spendi gli sforzi per produrre qualcosa senza valore. Quali attività commerciali potrebbero intenzionalmente buttare via i soldi?

   A proposito, i controlli 2 e 3 nell'esempio della mappa saranno coperti dalla documentazione della funzione. Chiunque non pensi al check 4 probabilmente non dovrebbe lavorare nello sviluppo del software, in primo luogo. Il controllo 1 è valido se non è ovvio che è necessaria una licenza e il messaggio di errore dal modulo è inutile. (Ma come dice Julia nella sua risposta, è molto meglio rendere il messaggio di errore più informativo che creare una FAQ per la risoluzione dei problemi.)

Non vedo alcun modo ovvio per i test unitari di includere il controllo della documentazione richiesta. Questo dovrebbe far parte della revisione del codice, non del test dell'unità.

There are ways to do a better error handling -- like throw an exception for example if the MapServer is unreachable, however there are also situations that you still need to check different elements to make sure what exactly causing the error.

È vero, ma naturalmente ogni volta che devi approfondire per scoprire cosa non va, devi aggiungere un codice per fornire un messaggio informativo con qualsiasi mezzo, preferibilmente aggiungendo il problema ad una lista. Non ha molto senso controllare ripetutamente lo stesso insieme di possibili cause di errore, in particolare perché è probabile che tale elenco aumenti, quando è possibile ottenere l'applicazione per diagnosticare i problemi stessi.