È buona prassi mettere un'analisi dei bug e correggere il codice nella segnalazione di bug?

Per inserire l'analisi dei bug in questa sezione è una buona pratica, per i motivi che hai menzionato (evita solo di essere eccessivamente prolissi).

In questo modo, le persone che lo leggono (compreso il tuo sé futuro) saprebbero quanto fosse delicato il problema e quanto impegno sia stato fatto nelle analisi e nei risultati. Inoltre, in questo modo si semplifica la manutenzione nel caso in cui siano necessarie ulteriori modifiche correlate alla correzione, poiché si potrebbe leggere la segnalazione di bug e capire perché le cose sono state cambiate in un modo o nell'altro.

_{Non aspettarti che questo direttamente ti faccia notare da una gestione più alta, perché questa è una questione diversa, una questione di visibilità sul posto di lavoro , e ciò richiederebbe altre abilità e approcci. Ai fini della visibilità, i dettagli inseriti nei rapporti bug svolgono solo un ruolo secondario ausiliario, consentendo di trovare e ottenere rapidamente questi dettagli quando necessario. Essere in grado di estrarre rapidamente una spiegazione chiara per questioni tecniche difficili può dare una certa visibilità al margine, ma non garantisce un vantaggio importante.}

Inserire un codice di errore (ad eccezione dei frammenti rilevanti per l'analisi) in una segnalazione di bug è un'altra questione, in genere una cattiva pratica, come previsto in VCS .

I tracker con buoni problemi integrati con VCS possono anche indirizzare automaticamente i lettori alle modifiche relative alla correzione. Per un esempio su come potrebbe essere, dai un'occhiata a Integrazione di JIRA con Subversion :

JIRA's Subversion integration lets you see Subversion commit information relevant to each issue. Subversion integration can be implemented either by using Atlassian FishEye or the Subversion add-on... both solutions allow you to link JIRA to related code changes in Subversion.

Commits will appear in this tab if the commit log mentions the issue key ('TEST-3' above)...

"Qual è la migliore pratica per uno sviluppatore di mostrare tali cose a un management superiore per farsi notare?"

Nella mia esperienza, la gestione superiore di solito non ha la capacità di capire ciò che avresti comunque scritto. Più ti allontani dallo sviluppo, meno capiscono profondamente. Se fai hai una gestione superiore competente per il tuo livello, parla semplicemente con loro. Ho scoperto che i geek della gestione superiore sono ancora geek e amano parlare di hack geek.

Se sei veramente interessato all'autopromozione, tieni un diario di bordo di tutti i tuoi successi, insieme a quanto sono stati difficili. Al momento della revisione, sarai preparato con esempi specifici.

"Come sviluppatore di software, è buona prassi mettere un'analisi dei bug e correggere il codice nel rapporto sui bug?"

Analisi dei bug? Sì. Altri sviluppatori hanno bisogno di vedere come hai risolto il bug se si imbattono in un problema simile, soprattutto perché tirare un diff e capirlo può essere noioso (se lasci il vecchio codice commentato e descrivi l'intera correzione in un commento, vergogna su voi).

Codice di correzione? Assolutamente no. DRY non è solo all'interno della base di codice, ma all'interno degli artefatti e delle informazioni di processo: lega il check-in al numero di bug / caso tramite tooling o commenti di controllo e, se vogliono vedere come lo hai risolto, dovrebbe essere facilmente recuperabile. Pensala in questo modo: se hanno la capacità di visualizzare e comprendere il codice e di capire davvero la complessità del tuo lavoro, probabilmente hanno comunque accesso al controllo del codice sorgente.

Ogni luogo in cui ho lavorato, avevamo almeno due meccanismi per documentare le correzioni dei bug. Un log di modifiche modificato dallo sviluppatore e il registro di commit modificato anche dallo sviluppatore. In genere, quest'ultimo viene inserito come "messaggio" quando si esegue il commit del file sul controllo del codice sorgente.

Seguo sempre due principi quando corregge un bug e lo commetto.

Per prima cosa, inserisco sempre un breve riassunto del bug, della correzione e del modulo a cui è applicato nel registro delle modifiche. Tieni sempre presente il tuo pubblico per questo testo: tutti. Dagli altri sviluppatori e da te stesso, per supportare e QA, lo staff di vendita e persino i clienti. Tutti devono capire la voce del tuo log. Ciò significa che in una certa misura stai scrivendo al minimo comune denominatore, ma devi comunque descrivere il bug e la correzione in modo tale che la spiegazione sia chiara e non imbarazzante per l'azienda. Ricorda, i clienti potrebbero leggere questo. E sii breve . Ho scelto meno di 10 parole.

In secondo luogo, aggiungo informazioni dettagliate sul problema e sulla correzione nel registro di commit. Il pubblico di questo testo è molto ristretto: te stesso e altri sviluppatori. Ottieni informazioni tecniche e dettagliate utili. Dal momento che questo è impegnato per il controllo del codice sorgente, sarà lì per sempre sotto forma di registro della cronologia.

Anche dal momento che la modifica viene inviata al controllo del codice sorgente, ricorda che il controllo del codice sorgente stesso è uno strumento di documentazione delle modifiche che può e viene utilizzato per spiegare i cambiamenti tecnici. Se uno sviluppatore vede qualcosa nel registro delle modifiche che desidera dettagli molto specifici, controllerà la cronologia dei controlli di origine e confronterà le modifiche con la versione precedente affiancata. Lo faccio sempre. Ciò significa che non devi essere dettagliato in nessuna delle tue voci di registro relative a che hai modificato. Le mie voci di registro dettagliate sono rare e sono sempre incentrate su perché . Di nuovo, il perché dovrebbe anche essere documentato nel codice come commenti.

Ora, per quanto riguarda la tua domanda:

What is the best practice for a developer to show such things to higher management to get noticed?

Enfasi mia. Parliamo di questo. Venendo dal punto di vista del management superiore, suggerirò di non farlo. Vieni fuori come uno stronzo lamentoso, lamentandoti sempre di quanto sia duro il tuo lavoro e quanto sei fantastico. Almeno potrebbe essere percepito in quel modo. Riflette male a voi di sfogliare. Attenersi ai fatti, portare a termine il lavoro e prendere a calci in culo. Ti noterai attraverso la qualità del tuo lavoro. Se non lo fai, vai avanti.

Ho lavorato su un progetto, dove era "standard" per inserire il codice di una correzione di bug nel file di Word. Eravamo un team di tre sviluppatori e un manager e un manager non erano in grado di utilizzare il software di controllo delle versioni per fare esattamente quello che era stato pubblicato nel file Word. La cosa è morta durante lo sviluppo del progetto, dal momento che noi sviluppatori non abbiamo visto il valore e abbiamo dimenticato di aggiornare i file. Non vorrei tornare su questa strada di nuovo.

Tuttavia, non c'è nulla di sbagliato nel rapporto di analisi dei bug. Ma non farlo. Se non ci sono crisi e bug non causa danni alle imprese, è solo una perdita di tempo.

È logico inserire una buona quantità di informazioni, ma è discutibile se possa aiutarti a "farti notare".

Potrebbe essere una cosa minuscola in un elenco di molte altre cose che ti contraddistinguono come uno sviluppatore coscienzioso a cui potrebbe prestare attenzione.

La direzione non la vede in questo modo.

Un dipendente che risolve un problema in breve tempo sarà sempre considerato più prezioso di chi risolve un problema più a lungo. Non importa se un problema fosse più difficile da capire e molto più importante per il progetto - di solito si può presumere che i propri superiori non capiscano i problemi tecnici in gioco, e assumeranno che ogni sottopeso esagera la difficoltà di tutto ciò che viene dato, Scotty-from-Star-Trek-style.

Ciò che dovresti fare per dimostrare il tuo valore è quello di stabilire metriche formali che sono applicate al tuo flusso di lavoro ed eccellere su di esse. Ad esempio, una misura che i gestori sembrano apprezzare è una velocità di rotazione (punti della storia soddisfatti, numero di problemi risolti).