Come determinare se c'è qualcosa di sbagliato nel mio codice o un bug nella libreria

1

Sto lavorando con Meteor, che è un framework Javascript relativamente giovane. In quanto tale, mi sembra di incappare spesso in problemi che non sono già stati richiesti su Stackoverflow.

In un caso del genere, stavo agonizzando per qualcosa che non funzionava, e si scopre che era un bug con Meteor. Quando stavo lavorando su questo, ho fatto l'ipotesi che fosse un problema con il mio codice, e non ho nemmeno considerato la possibilità di un bug nel framework.

Non aiuta che io sia piuttosto nuovo con Javascript.

Quindi la mia domanda è, in futuro, come posso decidere più rapidamente se un bug è mio o del framework? È frustrante passare un po 'di tempo a cercare di eseguire il debug di qualcosa che non è sostenibile, soprattutto quando non sono sicuro delle mie capacità JS.

    
posta ahota 06.11.2015 - 18:48
fonte

2 risposte

7

So my question is, in the future, how can I more quickly decide if a bug is mine or the framework's?

La chiave sta rendendo il bug riproducibile e isolato. In generale, si desidera seguire la stessa procedura inizialmente se si sospetta che il bug sia tuo o delle librerie.

La pagina MCVE di Stack Overflow è un ottimo primer su questo. SSCCE tenta anche di parlare con la stessa idea. Fai un esempio che riproduce l'errore in modo semplice e affidabile.

Come semplice esempio, immagina di avere un metodo esterno definito come:

Meteor.foo(int, int) // returns sum of two ints

Si sta utilizzando questo metodo nel codice e si sospetta che non funzioni correttamente. Dopo aver seguito il processo MCVE, si arriva al seguente codice:

print Meteor.foo(0,2) // prints 0
print Meteor.foo(1,2) // prints 3
print Meteor.foo(2,0) // prints 2

Questo è ora un motivo convincente per credere che la libreria Meteor stia causando il problema (ovviamente ..). In questo caso è chiaro come scrivere un esempio che è un "bug non è nel mio codice" MCVE.

Il punto di tutto questo è quello di limitare l'utilizzo del codice fino a trovare la quantità minima di codice che causa il problema. Ritaglio di codice extra fino alla risoluzione del bug. Se non riesci a tagliare più a causa di chiamate in biblioteca esterne ... probabilmente hai trovato il problema.

Sfortunatamente, la realtà è che quasi tutti i bug di questo tipo non saranno così semplici da riprodurre. Con questi (e il tuo esempio MCVE o 'principalmente MVCE') è una buona idea:

  • Visualizza le note sulla versione / i problemi noti
  • Visualizza bug aperti
  • Fai una domanda su Stack Overflow o sulle librerie listserve
  • Visualizza il codice sorgente stesso o quali test ha

Ci sono altre domande una , due su cosa fare una volta arrivato alla conclusione che il bug si trova nella libreria esterna.

Questi tipi di problemi possono essere davvero sgradevoli quando si lavora con librerie molto estese e comunemente usate. Abbiamo avuto un'istanza in cui più persone stavano cercando di rintracciare un bug di blocco della nave che finiva per essere una combinazione di un driver del mouse che causava il rendering non corretto della grafica con un framework esterno.

    
risposta data 06.11.2015 - 19:58
fonte
2

Mi dispiace dirlo, ma non esiste un punto magico.

In generale non è possibile stabilire facilmente se:

  1. Hai un bug nel tuo codice.
  2. Non capisci cosa dovrebbe fare il codice di terze parti.
  3. Il codice di terze parti sta facendo la cosa sbagliata.

L'unica soluzione è migliorare la tua conoscenza di javascript e migliorare il debugging.

    
risposta data 06.11.2015 - 21:26
fonte

Leggi altre domande sui tag