Monitora correzioni di bug nel codice

Non dovresti tenere traccia delle correzioni dei bug nel codice. Potrebbe avere senso tenere traccia di alcuni bug un corretti nel codice, come avvertimento ad altri sviluppatori che guardano a quel codice che ha dei bug che non hai risolto nel risolvere il problema. Qualcosa come:

//Currently crashes - see PRJ110-345
myObject.initialize();

Ma notare nel codice che il bug è stato corretto è inutile, perché il bug è qualcosa che non dovrebbe essere parte del codice in primo luogo - perché documentare qualcosa che non è lì e non dovrebbe essere Là? Posso facilmente introdurre nuovi bug nel codice digitandone in modo casuale i comandi, ad esempio posso impostare myObject in null in posizioni casuali. Hai intenzione di documentare su ogni riga perché myObject non è impostato su null su quella linea?

Il posto dove mettere questi commenti è nel controllo del codice sorgente - e sembra che tu non stia usando il controllo del codice sorgente, quindi dovresti iniziare a usarne uno - Suggerisco > Git. Un controllo sorgente (tra le altre cose che fa) rappresenta la cronologia del tuo progetto come commit: ogni commit è un diff che (insieme ai commit precedenti) descrive come il codice ha guardato prima del cambiamento e come appare dopo il cambiamento, e ti permette per inserire un messaggio di commit che descrive il cambiamento - cosa hai fatto e / o perché. Qui è dove si documenta la correzione del bug.

Quindi, invece di guardare i commenti nel codice, guardi i messaggi di commit e vedi cosa hanno fatto i tuoi compagni di squadra: Ecco come appare su BitBucket . In questo modo, il tuo codice rimane pulito ma puoi comunque accedere a tutte le informazioni.

Non è possibile dare a ogni riga del codice sorgente un riferimento a tutti i ticket interessati. Questa è semplicemente troppa informazione, e la maggior parte sarà superata poco dopo averla scritta. Questi tipi di commenti sono preziosi, ma dovrebbero essere i commenti di commit nel sistema di controllo della versione, piuttosto che i commenti di codice nei file di origine.

Ma se sto leggendo il tuo post correttamente:

I am working in a project in which at many point I need to change the code and fix the bug of the system but how can I inform other team members about this change?

Sembra che la tua vera preoccupazione sia come assicurarsi che il resto del tuo team sappia perché questa linea di codice è come la prossima volta che la leggono. In altre parole, come rendere leggibile il codice. Di solito ci sono altri modi per ottenere questo risultato che scalano meglio.

Se cancellare questi oggetti è una cosa normale e tutti i membri del team hanno familiarità con il concetto di checkAndClear (), è sufficiente rendere il codice un po 'più auto-documentante:

checkedObject = uncheckedObject.checkAndClear();

La maggior parte delle volte, questo tipo di cose dovrebbe essere sufficiente.

Se questa è una cosa insolita che richiede qualche tipo di spiegazione, oltre ad essere autocritica, lascia un commento che spiega il vero problema:

// Normally we don't need to clear these objects manually, but this one
// comes from Foo.lib which sometimes returns garbage values
checkedObject = uncheckedObject.checkAndClear();

Vorrei lasciare un riferimento esplicito a un ticket nel codice se ci aspettassimo qualche modifica futura al codice e il ticket riguardi la realizzazione di tale modifica:

// TODO: refactor Foo.lib to stop returning garbage values (PRJ1234)

Ciò impedisce a chiunque di aprire un ticket duplicato, o di duplicare il lavoro già svolto per quel ticket, e il bug tracker ha maggiori probabilità di avere informazioni aggiuntive se qualcuno ha lavorato su di esso.

Se provi a registrare le correzioni nel codice, finirai con un pasticcio di commenti nel tempo che lasceranno il codice illeggibile.

Come minimo, è possibile registrare il numero di Jira - PRJ110-345 - nel commento quando si controlla il codice in es. git, o qualsiasi altra soluzione di controllo del codice sorgente che si sta utilizzando.

Un'altra opzione per usare Stash e collegarlo a Jira. In questo modo, le tue modifiche verranno visualizzate in Jira.

Probabilmente la soluzione migliore è creare un nuovo ramo per ogni problema. In questo modo tutte le modifiche relative a PRJ110-345 vengono memorizzate in un ramo PRJ110-345. Al termine, unire nuovamente al master. In questo modo hai una registrazione completa di tutte le modifiche accessibili semplicemente esaminando la cronologia del ramo.