Devo registrare correzioni banali?

Devi registrare ogni modifica apportata al tuo sistema. Non c'è niente di sbagliato con la registrazione dopo l'evento - purché si colleghi il bug report al numero di modifica.

Quindi, se qualcosa va storto, puoi rintracciare il bug e scoprire perché hai apportato la modifica che hai fatto.

Nella grande maggioranza dei casi hai ragione e nessuno li guarderà mai più, ma nell'1 su 100 quando qualcosa va storto questa informazione sarà preziosa - specialmente se il problema affiora solo 6 mesi prima linea.

Aggiorna

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

Una volta che il sistema con la funzione è stato passato al QA o al cliente, allora è necessario fare ciò che ho delineato sopra.

Se si utilizza uno strumento di controllo del codice sorgente, è possibile descrivere il bug corretto nella descrizione del commit e di solito è sufficiente documentazione per correzioni di bug minime e minime.

Inoltre, se utilizzi un bug / tracker di funzioni che è completamente integrato con i tuoi repository e il tuo controllo sorgente, come FogBugz e Forno , potrai 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 soluzione banale che hai apportato, ma sto divagando ...

Dal punto di vista della metrica, potrebbe essere ancora utile.

Questa informazione potrebbe essere usata per mostrare al boss 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 di avere troppi bug. Forse c'è qualcosa che sta causando questo? stai liberando troppo presto? è stato eseguito un test sufficiente?
• un buon elenco di ciò su cui hai lavorato è arrivato il momento del bonus.

Ciò detto, dipende da quanto piccolo sia un bug di cui stai parlando. Ad esempio, le fodere che si individuano durante l'aggiunta di un nuovo codice potrebbero essere inutili da registrare, ad esempio.

Cerco di registrare ogni modifica apportata indipendentemente dalla dimensione di esso. 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 lì tramite il tuo capo che recupera i rapporti dal bug tracker.

Considera loro "gimmes" che finiscono per aumentare i tuoi numeri. Dopotutto, sono bug che hai corretto e dovresti essere riconosciuto per correggerli, anche se si tratta di correzioni banali.

Registrali.

Per rispondere a questo dipende davvero da dove ti trovi.

Possono essere applicati a un nuovo progetto o a un nuovo set di funzionalità in fase di progettazione.

Design iniziale Se trovi bug sul codice che abbiamo creato durante la progettazione iniziale, la creazione di una traccia di bug non sarebbe necessaria. Vorrei suggerire un commit separato per la modifica in modo da poterlo facilmente srotolare se trovi un problema in seguito.

testing

Il codice è al solito immagine riflessa ancora durante i test unitari quindi, a meno che non sia fatto da un gruppo diverso, direi di no. Se il test delle unità viene eseguito da un gruppo diverso da un bug tracker è un buon modo per formalizzare la procedura di test.

Il test CSCI dipende. È fatto da un altro gruppo? Se è così allora sì (vedi sopra). È questo l'ultimo passo del test prima del rilascio? Allora sì, perché a questo punto il tuo software dovrebbe essere considerato maturo. Se sei interessato alle metriche, sarebbe utile iniziare a tenere traccia dei bug a questo punto.

Per qualsiasi livello più elevato di test, dovresti usare il bug tracking. In questi punti il tuo software dovrebbe essere considerato maturo e i bug di tracciamento sono importanti.

di uscita

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

Anche la semplificazione 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 una squadra di 2 persone?

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

Altri hanno suggerito che se è necessario più tempo per registrare il bug piuttosto che per risolverlo, non vale la pena registrarlo. Suggerisco che l'intervallo di tempo rilevante non è tra la ricerca del bug e il suo fixing, è tra il momento in cui il bug è stato introdotto e il momento in cui la correzione è stata rilasciata.

Se la cronologia delle modifiche e delle versioni indica che il bug non ha mai visto la luce del giorno, allora la registrazione della 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 - risolvili invece.

1. Durante lo sviluppo: si verifica un bug per una funzionalità; aggiungi un caso di test che interrompe la compilazione , quindi verifica la correzione rispetto alla funzione.

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

Dopo che il codice è stato rilasciato, potrebbero esserci altre priorità e, sebbene il bug possa essere banale, la distribuzione della correzione potrebbe non essere economica da sola, a meno che non si stia eseguendo una distribuzione continua.

Dipende come banale, io uso questa misura:

If it takes longer to log it than it took to fix it, it ain't worth logging it.