È generalmente utile includere i problemi JIRA nei commenti di codice?

Vorrei provare ad evitare tali commenti. Anche se penso che ci sia un posto per loro dove hai un requisito particolarmente fastidioso. Quale senza, chiunque potrebbe volere refactoring il codice. ad es.

//must log to the database instead of standard logging, 
//stupid requirement from those crazy DBAs!! see TKCT-1234

o in modo simile potresti inserire un link

//work around stolen from this stackoverflow answer http://stackoverflow....

Ma non per i motivi per i quali dichiari un aumento dell'accoppiamento. In effetti do il nome di tutte le mie filiali di funzioni dopo il ticket per cui sono. Quindi è possibile rintracciare tutto il lavoro su un ticket, se necessario, anche se la cronologia del commit. (puoi anche fare qualcosa di intelligente per chiudere automaticamente se ti senti intelligente)

No, non sono preoccupato di cambiare il sistema di ticketing. Ma quello che mi sono reso conto è che è raro che qualcuno possa guardare indietro i biglietti una volta terminato.

Quindi il commento è utile perché dice la tua futura sostituzione:

"No i have not made a mistake, someone told me it had to be this way. Look! here is the ticket number to prove it!"

Ma non andranno a controllare quel biglietto. La vita è troppo breve.

Se ti abitui a mettere ovunque commenti di riferimento ai biglietti, allora perdono il loro impatto. Invece di essere una bandiera "leggi questo è super importante!" diventano solo confusione.

Generalmente i requisiti dovrebbero essere registrati attraverso il mezzo dei test. Se i test vengono superati, i requisiti devono essere soddisfatti, non dobbiamo preoccuparci di come sono stati originariamente dichiarati.

Per i commenti sul codice, c'è pochissima utilità. Per i commenti sul controllo della versione, sono molto utili per i motivi illustrati di seguito.

I commenti di codice dovrebbero essere usati per aiutare a comprendere l'intento di cose complicate.

Cattivi tipi di commenti al codice:

• Updated EHS 10/24/2015 - se volessi saperlo, userei il controllo di versione per trovare chi ha scritto quali linee.
• For spec 0.4 - che può essere parte dei commenti di commit, ma non mi aiuta a capire meglio il codice
• Altre varianti dello stesso tipo di cosa.

Se esistono commenti sul codice, dovrebbero aiutare a capire in che modo il blocco di codice si riferisce al dominio aziendale.

Se JIRA e il tuo controllo di versione sono collegati, allora sì, hanno senso per i messaggi Accetta .

• Il riferimento al ticket fornisce la tracciabilità delle modifiche richieste al lavoro richiesto
• JIRA non è l'unico strumento di tracciamento dei ticket in grado di eseguire questa sincronizzazione.

Consiglio vivamente un formato di commento simile al seguente:

 DIGIT-827: We only need to use the following for V4 of the computation.

JIRA e quasi tutti gli strumenti con questa integrazione sono abbastanza intelligenti da riconoscere il numero del biglietto e associarlo al ticket che viene risolto. Ciò significa che un URL completo è non richiesto . Significa anche che puoi ottenere i vantaggi e fornire commenti significativi per il particolare commit tutto in una riga.

Quando visualizzi il ticket in JIRA, vedrai l'elenco delle modifiche con tutti i commenti nel contesto della descrizione, ecc.

Sì, ma solo in rari casi.

In genere immagino che la maggior parte del codice verrà scritta in connessione con un ticket JIRA, quindi non lo commentare regolarmente con l'id del ticket - questo è il motivo per cui è la colpa di git. Ma in alcuni casi il codice potrebbe essere controintuitivo - forse il modo più ovvio per scrivere il codice non funziona e c'è stata una discussione sul perché non sul biglietto. In tal caso, prenderei in considerazione l'aggiunta di un commento con il riferimento del ticket.

Se una parte del codice deve risolvere un bug noto in un'altra parte, prenderei in considerazione l'aggiunta di un riferimento di ticket.

Non credo che questo ti leghi troppo strettamente a JIRA, come se volessi migrare da JIRA a un sistema alternativo, puoi esportare i tuoi problemi JIRA come CSV e importarli nell'altro sistema. L'ID del problema potrebbe cambiare durante questo processo, ma dovresti essere in grado di conservare l'ID del biglietto JIRA da qualche parte sui biglietti importati.

Metti i problemi di Jira nei commenti di commit, quindi usa un plugin per collegare i commit all'effettiva Jira.
I nostri messaggi di commit iniziano con:

JIRA: XBVS-1222 Fixes bugs...

Ad esempio, quindi i hook tra bitbucket e jira collegano i commit alla jira. Quindi è facile vedere a quale Jira si riferisce in eclissi, ad esempio, facendo clic con il tasto destro sul numero di riga e selezionando "Mostra cronologia revisioni", penso che lo si chiami comunque. Il numero e i commenti del tuo numero di Jira saranno evidenziati sulla colonna del numero di riga, e passando con il mouse ti forniranno i dettagli.

Non è certamente una pratica terribile includere i problemi JIRA nei commenti di codice, ma questa tecnica accoppia strettamente / manualmente due preoccupazioni eterogenee (problemi e codice) e può richiedere aggiornamenti a più sistemi / locations (JIRA, ovunque nella fonte è menzionato il problema, cronologia del controllo della versione).

I commenti al codice sono in generale problematici perché spesso non vengono aggiornati.

Un approccio migliore potrebbe trovare un modo per integrare il sistema di rilevamento dei problemi con il sistema di controllo della versione, in modo che le due preoccupazioni possano essere gestite separatamente, in modo automatico.