Come posso trovare la radice di problemi confusi?

Quindi, per iniziare, vedi Wikipedia :

Problems that can be solved in theory (e.g., given infinite time), but which in practice take too long for their solutions to be useful, are known as intractable problems.

I tuoi problemi potrebbero essere molti, ma probabilmente non sono intrattabili . Quindi attacchiamo il cuore del problema:

Come abbattere i problemi a un livello che gli altri possono aiutare?

La risposta ovvia è il debug. Un problema si verifica quando il tuo programma fa qualcosa che non ti aspetti. Quindi, ad ogni passo, vuoi assicurarti che la realtà sia congruente con le tue aspettative. Quando raggiungi un punto in cui ciò che accade non è quello che ti aspetti, hai riscontrato il problema.

Le persone spesso postano chiedere aiuto per ciò che "pensano" che è sbagliato. Forse hanno cercato l'errore e hanno provato a implementare la soluzione nel primo risultato. Forse la loro paperella di gomma ha detto loro. Francamente, quello che "pensi" di solito è senza valore. Per citare Richard Feynman:

It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong.

Quindi prima capisci cosa c'è che non va!

Da lì, si tratta semplicemente di isolare gli input e gli output. Le persone non hanno bisogno di capire il tuo intero programma - hanno semplicemente bisogno di vedere cosa sta arrivando e cosa dovrebbe uscire. Dovresti sempre descrivere la fonte di ciò che sta arrivando, perché a volte ciò che pensi di entrare non è ciò che sta realmente accadendo.

A quel punto, il problema può solitamente essere risolto. Alcuni SO guru vedranno cosa succede, forse ti chiederanno di fare qualcosa, e accetterai la loro risposta e dirai "grazie mille!" o qualcosa di simile.

Ricorda, trova il punto in cui le aspettative e la realtà differiscono. Scrivi il caso base che causa questo. Attuare la soluzione. QED.

Il problema che ho è un po 'specifico, e potrebbe avere problemi radicati altrove nel mio codice. Mi sembra che tu non sia in grado di capire il problema in primo luogo. Questa situazione si verifica principalmente quando ci aspettiamo che si verifichi un errore per una ragione e se questa ragione non è la fonte di errore, saltiamo alla conclusione che è un problema un po 'schiacciante e non può essere spiegato a parole.

Per evitare tali cose, ti suggerirei di tenere la mente aperta a tutti gli errori che possono accadere all'interno di un codice e provarli uno per uno. Identificare il problema è una preoccupazione importante che può essere fatta solo sulla tua parte. Dovresti dedicare un po 'di tempo a capire i fondamenti del debugging e del tracing perché se vengono appresi non avrai alcun problema irraggiungibile o senza parole.

E una volta che hai il problema nelle mani, sono sicuro che SO è sufficiente per risolvere QUALSIASI problema nella codifica. Saluti :-)

Credo che non si stia investendo abbastanza tempo nel debugging e nel muoversi attorno al codice che si costruisce e si affretti a concludere che non funziona a causa di MethodA . Siccome un utente SO non è a conoscenza di ciò che le altre cose sono l'unico modo è di dedurre dai dettagli / codice che hai fornito che potrebbe essere sbagliato e talvolta fuorviante.

Per prima cosa devi essere sicuro di ciò che sta causando il problema, anche nel caso in cui ti accorga che quest'ultimo aggiorna la tua domanda con i fatti rilevanti. Jon Skeet ha menzionato alcune linee guida su come andare riguardo a una domanda

Spero che questo aiuti e ottieni risultati migliori da SO, evita l'urgenza di chiederlo immediatamente e prenditi un po 'di tempo da solo (è così che hanno imparato tutti quei veterani della SO)

La comprensione

il percorso più veloce è la comprensione. questa è un'abilità di cui avrai bisogno e si sviluppa con esperienza.

piuttosto che "aiuto! non capisco il mio programma / problema", lavorarci sopra .

la programmazione è davvero piuttosto semplice. la maggior parte delle cose si risolve in vero o in falso. il numero di problemi grandi che non possono essere semplificati a quelli che possono essere ulteriormente semplificati è molto basso (in programmazione).

scrivi il tuo programma per rilevare i suoi errori (e correggere immediatamente i problemi). idealmente, questo sarebbe fatto mentre andate. semplifica il tuo programma - non in funzionalità, ma nelle sue interazioni; ridurre o localizzare la complessità delle tue classi, funzioni, ecc.

scrivo programmi come se fossi più o meno un idiota - i miei programmi sono apertamente difensivi e semplificati. questo aiuta a rilevare i problemi e serve come documentazione. il risultato finale ha pochissimi bug perché i problemi sono localizzati nel callsite e, soprattutto, vengono rilevati molto presto.

quindi ora è il momento della revisione del codice per te: inizia con le aree problematiche e aggiungi una serie di controlli di integrità (ad esempio asserzioni), quindi scrivi i test delle unità - risolvendo man mano che procedi. poi impari cosa va storto e perché va male, e capirai i problemi che affronti e come affrontarli facilmente (gli errori dei programmatori hanno modo di ripetersi).

lasciandoti con una citazione: "Il debugging è due volte più difficile della scrittura del codice, quindi se scrivi il codice nel modo più intelligente possibile, per definizione non sei abbastanza intelligente per eseguirne il debug." --Brian Kernighan