Hai mai trovato un bug che non riesci a risolvere? Cosa fai in questo caso?

Question

Hai mai trovato un bug che non riesci a risolvere? Cosa fai in questo caso?

#1 da (5 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (1 voti)

5

Stiamo sviluppando un CMS ospitato, qualcosa come WordPress.com. Quando stavamo creando il modulo Galleria immagini , abbiamo esaminato molte librerie jQuery come easySlider , jCarousel e Nivo Slider . Ma ognuno di loro aveva qualche tipo di strano bug tra i vari browser. Abbiamo quasi messo 2 giorni per scoprire da dove proviene il bug. Ma non siamo riusciti a trovare la fonte del problema. La ragione più importante potrebbe essere che il nostro sistema sia ora complesso.

Ecco i problemi:

easySlider sliding non era transitorio ed era brusco.
jCarousel stava facendo scorrere le immagini a metà della loro larghezza in IE.
Nivo Slider non ha nascosto l'ultima immagine mostrata, quindi non era adatto per la galleria di immagini con immagini eterogenee.

Abbiamo appena concluso che abbiamo bisogno di trovare una libreria che possa funzionare senza bug, e l'abbiamo cercata e trovata.

Ma la mia domanda è, è normale per i progetti di grandi dimensioni che la fonte di un bug non può essere trovata e invece, si trova con trial-and-error e semplicemente fuggire dal bug? Hai una tale esperienza?

debugging bug

posta Saeed Neamati 04.09.2011 - 08:57

fonte

4 risposte

Leggi altre domande sui tag debugging bug

Elaborazione MVC multiplo vs Processo MVC singolo È legale mettere "FSharp.Core.dll" dal pacchetto ridistribuibile di FSharp?

score 5 · Answer 1

We just concluded that we need to find a library which can work without bug, and we searched and found one.

Oppure, meglio, puoi contattare i rispettivi autori di tali librerie e inviare loro il bug che hai trovato.

Potresti anche sorprendervi se quegli autori rispondono che il bug non esiste. Ad esempio, ho usato jCarousel in passato e non ho mai avuto problemi di larghezza in IE. Il tuo caso potrebbe essere uno strano caso limite o un bug introdotto nell'ultima versione, ma potrebbe anche essere il fatto che stai usando la libreria sbagliata.

Ora, se contatti l'autore e spende un sacco di tempo per correggere un bug mentre si avvicina la scadenza, o la sua risposta non è di aiuto, non c'è nulla di male nell'abbandonare una biblioteca e sceglierne un'altra . Puoi anche disattivare una funzionalità con bug nella versione corrente del tuo sito web e cercare una soluzione in un secondo momento , facoltativamente contribuire a libreria se è open source.

score 1 · Answer 2

Per definizione ogni bug può essere corretto, magari scrivendo il tuo sistema operativo in linguaggio assembler. Questa è una delle bellezze della programmazione.

Su una nota più realistica, il problema è trovare una soluzione al bug che ha un costo ragionevole. Riscrivere un pezzo di Linux è molto più economico rispetto alla scrittura del proprio sistema operativo. Trovare una libreria che funzioni costa meno della riscrittura di una libreria danneggiata.

Drupal ha un trucco per cui l'HTML è dato a html.tpl.php per essere scritto nel browser. Modificando quel file ho "corretto" bug sostituendo il vero HTML con il mio. Gli esempi includono la traduzione dall'inglese al cinese, l'aggiunta di un selettore di lingua in un angolo non consentito dello schermo e il prelievo di un'immagine casuale da visualizzare. È di basso livello, ma è possibile.

È sempre possibile "correggere" un errore sostituendo il codice che genera il problema. Più piccolo è il pezzo che sostituisci, meno costa.

score 1 · Answer 3

Direi che hai fatto la cosa giusta, forse ci è voluto troppo tempo per arrivarci. Per cose come le librerie open source di terze parti preferisco fare un rapido "picco" su quelle che sembrano più promettenti. Lo "spike" è un test rapido di fattibilità, con piccoli bit di codice isolati, per determinare rapidamente se la libreria sarà adatta al problema. Se non lo è, puoi passare rapidamente all'alternativa.

Naturalmente, se nessuno di questi è adatto, dovrai affrontare la tua implementazione o, per quella che è la corrispondenza più vicina, puoi risolvere il problema o collaborare con l'autore come suggerisce MainMa. In caso di correzione si impiegano tecniche di debug standard, ma il metodo spike può essere d'aiuto in quanto si ha meno del proprio codice e si può isolare meglio il codice di terze parti che è problematico.

score 1 · Answer 4

Qualsiasi bug può essere "trovato" nel senso che finirai in una delle seguenti situazioni:

Puoi individuare esattamente il file e la linea nel tuo codice in cui le cose vanno male. Se sei qui, bene, hai praticamente risolto il bug.
Concludo che i requisiti non soddisfatti sono in realtà non ben definiti: possono essere troppo vaghi, contraddittori o ambigui. La soluzione è quindi tornare al cliente e ottenere i requisiti immediatamente prima di apportare modifiche casuali al tuo codice.
È possibile individuare una sezione del codice in cui le cose vanno male, ma quella sezione è così complicata che l'analisi del suo comportamento e il confronto con il comportamento previsto richiederebbero molto tempo. Questo è un campanello d'allarme, e dovresti riscrivere immediatamente quel codice.
Puoi individuare il bug da qualche parte al di fuori del tuo codice: una biblioteca; l'implementazione da parte del browser di javascript, CSS, HTML o qualsiasi altra cosa tu stia utilizzando; implementazione di un altro host di un protocollo di rete; ecc. Se è possibile, sostituire il codice difettoso con un'alternativa che funzioni. Se non è possibile (ad esempio con un bug javascript), trovare una soluzione alternativa, ma integrarlo nel codice in un modo che renda semplice e immediato il passaggio al comportamento conforme. Idealmente, vuoi essere in grado di rilevare un ambiente non conforme e regolarlo automaticamente.

Quindi, anche se non è sempre possibile trovare il bug nel senso del primo punto, devi essere sempre in grado di finire in una di queste quattro situazioni, e tutte hanno delle soluzioni (anche se alcune possono essere piuttosto dolorose ).