Devo registrare correzioni banali?

Sono in una libreria di due. E mentre capisco che un tracker di bug è utile quando il numero di programmatori è maggiore o uguale a uno, non sono così convinto che la registrazione di bug, modifiche e correzioni valga la pena di essere banale. Quando trovo un semplice bug, lo capisco, lo risolvo ed eseguo alcuni test. E poi mi sono reso conto che devo andare a registrarlo.

So in teoria che la registrazione dei bug dovrebbe essere fatta da qualche parte tra la ricerca del bug e la correzione del bug, ma se risolverlo è più veloce della registrazione, sembra un trascinamento. Nei negozi di codici più grandi, il capo presta attenzione a chi sta facendo cosa ed è bello sapere dove gli altri si stanno divertendo.

Mi ritrovo a descrivere cose che ho già risolto e poi a chiuderle all'istante. Dubito che qualcuno guarderà di nuovo questo bug chiuso. È tempo di ridurre il grasso corporeo?

È necessario registrare tutte le modifiche apportate al proprio sistema. Non c'è niente di sbagliato nel registrarlo dopo l'evento, purché si colleghi la segnalazione di bug al numero di modifica.

Quindi, se qualcosa dovesse andare storto, puoi risalire al bug e scoprire perché hai apportato la modifica che hai apportato.

Nella stragrande maggioranza dei casi hai ragione e nessuno li esaminerà mai più, ma nell'1 su 100 quando qualcosa va storto questa informazione sarà preziosa, soprattutto se il problema affiora solo 6 mesi lungo la linea.

AGGIORNARE

Ovviamente se stai ancora sviluppando una nuova funzionalità e scopri un bug in parte della funzionalità che pensavi di aver terminato, non è necessario registrarlo come modifica separata. In questi casi lo registrerei contro l'elemento che richiede la funzione principale.

Una volta che il sistema con la funzione è stata passata al QA o dal cliente, allora è necessario fare quello che ho descritto sopra.

Se si utilizza uno strumento di controllo del codice sorgente, è possibile descrivere il bug corretto nella descrizione del commit e che di solito è una documentazione sufficiente per correzioni di bug super-piccole e banali.

Inoltre, se usi un tracker di bug / funzionalità completamente integrato con il tuo controllo del codice sorgente e repository, come FogBugz e Kiln , sarai in grado di utilizzare lo strumento di ricerca globale per trovare queste correzioni di bug e vedere quali modifiche al codice hai apportato abbastanza facilmente.

Inoltre, puoi assegnare una revisione del codice al tuo partner di programmazione in modo che possa rivedere la banale correzione che hai fatto, ma sto divagando ...

Dal punto di vista delle metriche, potrebbe essere comunque utile.

Queste informazioni potrebbero essere utilizzate per mostrare al capo una serie di cose:

• abbiamo bisogno di più sviluppatori
• qualcos'altro nel processo è rotto (perché così tanti bug? l'altro ragazzo genera la maggior parte dei bug), forse mostrando che hai troppi bug. Forse c'è qualcosa che causa questo? stai rilasciando troppo presto? è stato fatto abbastanza test?
• un buon elenco di ciò su cui hai lavorato è arrivato bonus time.

Detto questo, dipende da quanto piccolo sia un bug di cui stai parlando. Ad esempio, una delle righe che ti capita di individuare mentre aggiungi nuovo codice sarebbe probabilmente inutile registrarti.

Provo a registrare tutte le modifiche apportate indipendentemente dalle dimensioni. Non sai mai quando tu, o qualcun altro (futuro o presente), dovrai tornare indietro e vedere se quel cambiamento è la possibile causa di qualcos'altro.

Il monitoraggio è importante, ma considera anche un altro scenario: quando arriva il momento della tua recensione. Accadrà formalmente di persona o in modo informale senza di te, tramite il tuo capo, raccogliendo segnalazioni dal bug tracker.

Considerali "trucchi" che finiscono per aumentare i tuoi numeri. Dopotutto, sono bug che hai risolto e dovresti essere riconosciuto per risolverli, anche se sono correzioni banali.

Li registra.

Per rispondere a ciò dipende davvero da dove ti trovi nel processo.

Questi possono applicarsi a un nuovo progetto o a un nuovo set di funzionalità in fase di progettazione.

Progettazione iniziale Se trovi dei bug sul codice che abbiamo creato durante la progettazione iniziale, non sarebbe necessario creare una traccia bug per esso. Suggerirei un commit separato per la modifica in modo da poterlo facilmente svolgere in caso di problemi in un secondo momento.

analisi

Di solito il codice è ancora considerato come un imature durante i test unitari, quindi a meno che non sia fatto da un gruppo diverso direi di no. Se il test di unità viene eseguito da un gruppo diverso rispetto a un tracker di bug, è un buon modo per formalizzare la procedura di test.

Il test CSCI dipende. È fatto da un altro gruppo? In tal caso, sì (vedi sopra). È questo l'ultimo passaggio del test prima del rilascio? Quindi sì, perché a questo punto il tuo software dovrebbe essere considerato maturo. Se sei interessato alle metriche, a questo punto sarebbe anche utile iniziare a monitorare i bug.

Per qualsiasi livello superiore di test, è necessario utilizzare il rilevamento dei bug. A questi punti il ​​tuo software dovrebbe essere considerato maturo e il monitoraggio dei bug è importante.

pubblicazione

Dovresti sempre tenere traccia dei bug sul codice rilasciato. Questo è importante per la responsabilità.

Anche la razionalizzazione di un processo per soddisfare le tue esigenze è importante. Hai davvero bisogno di un enorme sistema di tracciamento dei bug? Tutti i campi sono davvero così importanti per un team di 2 persone?

È possibile che qualcun altro possa riscontrare il bug, forse in una versione precedente del software che è stata rilasciata al mondo esterno? In tal caso, può essere utile registrare sia il bug sia la correzione.

Altri hanno suggerito che se impiega più tempo a registrare il bug che a risolverlo, non vale la pena registrarlo. Suggerisco che l'intervallo di tempo rilevante non è tra la ricerca del bug e la sua correzione, è tra il momento in cui il bug è stato introdotto e il momento in cui la correzione viene rilasciata.

Se la cronologia delle modifiche e delle versioni indica che il bug non ha mai visto la luce del giorno, registrare la correzione quando la si controlla nel controllo del codice sorgente dovrebbe essere sufficiente.

Questo è abbastanza vicino a questa domanda , ma non sono sicuro che sia un duplicato, dal momento che questo si concentra su correzioni banali .

Perché non dovresti tenere traccia dei bug, di Jon Arid Torresdal - correggili invece.

1. Durante lo sviluppo: si verifica un bug per una funzione; si aggiunge un banco di prova che rompe la build , quindi controllare nella correzione contro la funzione.

2. Dopo il rilascio: documentare il comportamento . Se prevedi di rilasciare un aggiornamento, vai a 1. Se non sei responsabile di quella versione, mantieni il test + fix nascosto in un ramo privato.

Dopo il rilascio del codice, potrebbero esserci altre priorità e, mentre la correzione del bug può essere banale, la distribuzione della correzione potrebbe non essere economica da sola, a meno che non si stia eseguendo una distribuzione continua.

Dipende da quanto sia banale, io uso questa misura:

Se ci vuole più effettuare il login esso che ci sono voluti per risolvere il problema è, che non è la pena di registrazione esso.