Quale percentuale del tempo di programmazione spendi per il debug?

Question

Quale percentuale del tempo di programmazione spendi per il debug? Quali pensate siano percentuali accettabili per determinati supporti di programmazione?

Answer 1

Non molto ora che ho molti test unitari. A meno che non contiate il tempo speso per scrivere test e correggere i test non riusciti per eseguire il debug del tempo, cosa che in realtà non è. È relativamente raro ora dover passare attraverso il codice per capire perché un test sta fallendo.

Quanto tempo è necessario dedicare al debug dipende dal codice base. Se è troppo alto, è probabile che sia un sintomo di altri problemi, ad es. mancanza di adeguata gestione delle eccezioni, registrazione, test, ripetibilità ecc. Ciò che conta come "troppo alto" è soggettivo.

Se è necessario eseguire il debug di un errore, è consigliabile eseguire un test di errore prima di correggerlo, in modo che l'errore non si ripresenti.

La cosa peggiore su cui ho dovuto lavorare è stata una simulazione complessa e complessa scritta interamente senza test. A volte falliva nel bel mezzo di una corsa, e per riprodurre un incidente comportava l'impostazione di un breakpoint, l'avvio della corsa e l'attesa di mezz'ora o più. Quindi apporta una modifica e ripeti. Non ti immergere mai in quella situazione che distrugge il morale e distrugge la produttività.

Answer 2

C'è così tanta varietà quando si tratta di scrivere software che è impossibile dare una risposta solida. La complessità del software può aumentare il tempo di debug, ad esempio, se il codebase è molto grande e il codice stesso è scritto male, allora questo potrebbe aumentare la quantità di tempo speso per il debug.

Un modo per ridurre il tempo di debug è scrivere test di unità. L'ho fatto per un po 'e ho scoperto che aiuta a ridurre il numero di bug che vengono rilasciati al cliente.

Answer 3

Circa il 90% del mio tempo viene speso per il debugging o il refactoring/riscrittura del codice dei miei colleghi che non hanno mai lavorato, ma che comunque sono stati assegnati a GIT come "funzionanti".

Potrebbe essere spiegato dal morale negativo in questa (abbastanza grande) azienda a causa della cattiva gestione.

Gestione opinione sui miei suggerimenti: Test

• Unità: proibito, prende troppo tempo.
• Ambiente di sviluppo: nessun server di riserva e il lavoro sui dati live non è un problema, devi solo stare attento.
• QA/Test: gli sviluppatori possono testare da soli, senza bisogno di un tester separato.
• Programmazione orientata agli oggetti: troppo complessi, i nuovi programmatori non saranno in grado di comprendere il codice abbastanza velocemente.
• Specifiche scritte: prendi troppo tempo, è più facile dire semplicemente ai programmatori di creare ciò di cui abbiamo bisogno direttamente.
• Formazione per sviluppatori: troppo costoso e i programmatori non saranno in grado di lavorare durante l'allenamento.