Bug clustering nel codice sorgente

Question

Bug clustering nel codice sorgente

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

8

Ci sono molte affermazioni sull'esistenza di cluster di bug o difetti. Una semplice ricerca rivela più risultati, ad esempio: 1 , 2 , 3 , 4 , 5 .

Tuttavia, tutte le prove citate sono aneddotiche e non sono riuscito a trovare alcun dato concreto a sostegno di ciò. Mentre la mia esperienza non contraddice queste affermazioni, le persone amano vedere i pattern anche quando non ce ne sono (anche una distribuzione uniforme dei bug produrrà cluster, e potrebbe essere più facile da ricordare quando devi correggere 10 bug in un posto piuttosto che 10 cose non correlate su tutto il codebase).

Sono sinceramente curioso di sapere se questo fenomeno esiste davvero, ma non sono riuscito a trovare alcuna fonte oggettiva o semi-oggettiva (come nei test, negli esperimenti, nello studio, ecc.) che dimostrerebbe che il cluster di difetti si verifica realmente.

Naturalmente, sto bene assumendo l'ipotesi del cluster bug come buona pratica (anche se è falsa, non farà troppo male). D'altra parte, i dati concreti potrebbero far luce sul perché. È a causa di quei giorni si ha un terribile mal di testa (per qualsiasi motivo)? O forse perché alcune parti del codice sono difficili e altre sono facili? O forse è il posto di responsabilità di quei due ingegneri che non si amano?

La mia domanda: esiste effettivamente un effetto di clustering dei difetti? C'è qualche dato concreto non aneddotico che è meglio spiegato da questa ipotesi?

testing debugging engineering maintenance

posta dtldarek 15.11.2016 - 16:32

fonte

4 risposte

Leggi altre domande sui tag testing debugging engineering maintenance

Creare un front-end AngularJS per un'applicazione Microservices Gestione degli errori nel sistema distribuito

score 3 · Answer 1

Gli studi formali come questo raramente esistono nello sviluppo del software, probabilmente perché la programmazione (nonostante la sua associazione con le macchine) è principalmente uno sforzo umano, non uno meccanico.

Ieri stavo correggendo un bug in un'istruzione SQL che coinvolgeva due istruzioni SELECT e UNION. Entrambi i SELECT restituivano lo stesso risultato a causa di un semplice errore in un JOIN. Risolvere il problema, tuttavia, ha scoperto un altro bug mascherato dal primo bug.

score 3 · Answer 2

Non ho dati a portata di mano, ma sono abbastanza sicuro che l'ipotesi del clustering sia vera. La mia ipotesi migliore sono che questi due casi avvengano più o meno frequentemente:

un pezzo di codice o algoritmo è complesso (forse l'implementazione è più complessa del necessario) e il programmatore originale non ha compreso appieno cosa potrebbe fare il suo codice a causa della complessità.
il codice non è stato testato bene

E - ovviamente - una combinazione di entrambi. I test sono difficili, ma testare codice complesso è molto più difficile di un ordine di grandezza. E con la crescente complessità, specialmente quando il codice non è ben testato, nella mia esperienza, il numero di potenziali bug in un pezzo di codice aumenta in modo sproporzionato.

Quindi, se trovi diversi bug in una determinata porzione di codice, è probabilmente una parte di codice mal testata e complessa, che ti dà un'alta possibilità di trovarne altri nella stessa area.

score 2 · Answer 3

Nella mia esperienza:

Il clustering si verifica quando il lavoro viene interrotto. Dì che qualcuno è stato spostato dal progetto in modo che il suo lavoro non sia stato completamente testato, o forse completato, e / oi risultati non siano stati completamente compresi.

Il clustering si verifica anche a causa del problema "programmatore non valido". Diciamo che 5 persone hanno lavorato su qualcosa e uno di loro era al di sotto degli standard. I bug saranno associati al suo lavoro.

Si applica il principio di Pareto (ovvero la regola 80/20). Circa l'80% degli effetti proviene dal 20% delle cause. link Nota che questa osservazione risale ai computer precedenti.

score 0 · Answer 4

Non c'è alcun paradosso nel clustering degli errori. E i nostri pregiudizi cognitivi accarezzano la fiamma.

In base alla distribuzione normale in qualsiasi momento, alcune parti del codebase sono significativamente più baciate di altre. Ogni nuovo bug è più probabile che si trovi nella parte del buggy.
Quindi quello che stai per risolvere è già condannato con una buona possibilità di avere un'azienda.

È lo stesso di "le disgrazie non vengono mai singolarmente".