Il gestore che legge il controllo della versione si impegna

Il nostro manager sta monitorando gli impegni di Git su tutti i nostri progetti; di solito questo non è un problema, e adoro il fatto che il controllo di versione fornisca un registro di tutto il lavoro che sta succedendo, specialmente per successive verifiche e analisi (nel caso qualcosa vada storto).

Tuttavia, il gestore ha fatto alcuni commenti chiedendo a cosa stanno lavorando le persone quando vede un commit che legge "correzioni di stile" o qualsiasi messaggio di commit che non fa riferimento a un numero di ticket nel nostro sistema di gestione delle attività.

Esiste una soluzione sociale o tecnica a questo?

Ulteriori informazioni: questo è un progetto di manutenzione, quindi ci sono un sacco di "dovuto fare A, poi B, poi C e poi D, e poi finalmente implementare X".

Maggiori informazioni: il particolare messaggio di commit che ha sollevato una bandiera con il manager era vicino a "includeva un modo migliore per X, Y e Z" che è più un messaggio di refactoring piuttosto che una semplice correzione stilistica.

version-control management

— Peter Mortensen
fonte

possibile duplicato di Il riferimento a bug / problema nel messaggio di commit è considerato una buona pratica?

— moscerino del

Sono d'accordo con il tuo manager. Guardare un registro di commit di due anni per capire quando qualcosa è cambiato e vedere commit come "correzioni di stile" è dannatamente fastidioso. Se il tuo manager non ti consente di aggiungere attività di refactoring nel sistema di gestione delle attività, questo è un altro problema.

— Gort il robot

Il vero refactoring è ancora più importante da catturare rispetto ai cambiamenti stilistici. Per lo meno il messaggio di commit dovrebbe dire ciò che viene refactored, ma davvero vorrei che fosse tracciato in modo che tutti sapessero cosa veniva refactored, il QA sapeva cosa testare più attentamente, ecc.

— Gort the Robot

^^^ quello che ha detto @StevenBurnap - questo è molto buona pratica. Il solo fatto di poter fare riferimento all'ID ticket anziché inquinare il messaggio di commit con lunghe spiegazioni sul tipo di miglioramenti / refactoring di tipo e sul motivo per cui sono desiderati ne vale la pena. E c'è di più, sforzo di tracciamento, comunicazione con il management / QA ecc. Ecc. E non mi dia un'idea di come sia conveniente quando il tracker di bug si integra con lo strumento di revisione dei codici VCS / codice

— moscata

Dipende completamente dalla situazione. Il manager sta reagendo a un membro del team che sta spendendo il 50% del suo tempo in refactoring o ad un singolo commit senza riferimento al ticket?

— winkbrace

Risposte:

Esiste una soluzione sociale o tecnica a questo?

Suppongo, ma questo non è un problema .

Il tuo manager dovrebbe sapere cosa state facendo. Dovrebbero assicurarsi che non stai facendo un sacco di lavoro che non fornisce alcun valore, o perché è stata data priorità al lavoro non ticket. Non c'è nulla di male in questo. In un mondo ideale, offrirà benefici, perché il tuo manager può fissare aspettative con gli affari in modo da poter svolgere tutto quel lavoro senza pressioni o interruzioni.

Diventa un problema solo se il tuo manager pensa che dovrebbe essere fatto solo il lavoro dei biglietti e impedisce che i lavori di pulizia tecnica siano biglietti. C'è sempre un debito tecnico da ripulire. Ottimizza sempre le cose perché dovresti, anche se non offrono alcun vantaggio commerciale chiaro e immediato.

— Telastyn
fonte

Se la correzione stilistica fa parte del biglietto su cui stai lavorando ed è correlata, non c'è nulla di sbagliato nel controllarlo separatamente con lo stesso numero di biglietto su cui stavi lavorando per una migliore identificazione.

Se stai solo scoprendo le modifiche che devono essere apportate e non sono correlate al ticket su cui stai attualmente lavorando, ti suggerirei di creare biglietti relativi al debito tecnologico e di inserirli nel tuo backlog per la successiva rielaborazione.

Durante la pianificazione è quindi possibile esaminare i ticket relativi al debito tecnico e collegarli ai ticket di manutenzione effettivi su cui si prevede di lavorare in questo modo per renderlo più affidabile.

Ciò ti aiuterà a eliminare quelle correzioni "dal nulla" e a mantenere tutto incapsulato nella categoria di problemi / ticket specifici su cui stai lavorando.

— AvetisG
fonte

Va bene, ma se è una soluzione banale, allora è completamente stupido.

— Lightness Races con Monica

Debito tecnico Il 99,99% delle volte non è un cambiamento banale. Ecco perché dico di fare un biglietto invece di immergermi in qualcos'altro che è un grande cambio di contesto. Se è qualcosa di banale e non correlato a ciò su cui stai lavorando, puoi comunque controllarlo sotto il nome del biglietto su cui stai lavorando con un commento separato. O meglio ancora pensare a una notazione come QFIX per una facile identificazione in seguito, in modo da non avere cambiamenti banali casuali in giro senza organizzazione.

— AvetisG

cosa succede se il gestore sta anche guardando JIRA per i nuovi biglietti e poi li mette in discussione? non mette in discussione quando i biglietti vengono spostati da uno sprint futuro a quello attuale ma non appena qualcuno crea un nuovo biglietto relativo al debito tecnico, viene messo in discussione.

— Rudolf Olah,

La notazione QFIX è qualcosa di cui dovresti parlare come squadra prima di implementarla. Si tratta solo di comunicazione, non devi solo saltare e scrivere le tue regole. Quindi prima parlane come una squadra, e poi se non sono d'accordo, vai con l'altra soluzione che è quella di controllarlo insieme al tuo biglietto principale su cui stai lavorando con un commento separato. Si noti, ancora una volta, solo se la modifica è banale, il che significa che non contiene modifiche logiche o grandi refactoring. Cambiamenti innocui, innocui, banali.

— AvetisG

@Mouse Può darsi che il tuo manager stia gestendo la micromanage o che non stia affrontando adeguatamente il debito tecnico. Tuttavia, il gestore è alla fine responsabile del progetto nel suo insieme e responsabile del codice stesso, e quindi idealmente dovrebbe essere a un certo livello consapevole di ogni pezzo di lavoro che continua e del perché.

— Gort il robot

Anche questo mi infastidisce (nessun gioco di parole previsto :).

I check-in più utili contengono commenti unici e specifici non solo per ciò che è cambiato, ma perché. A volte finisco per inserire commenti di paragrafo.

Di tanto in tanto mi trovo in situazioni in cui un requisito dell'interfaccia utente rimbalza avanti e indietro una volta iniziato lo sviluppo, richiedendo che io essenzialmente rimbalzi anche il codice (sì, il mondo reale fa schifo a volte). In questi casi, ritengo ancora più importante che i miei commenti forniscano chiarezza sul perché il rimbalzo e, soprattutto, perché il codice finisce dove si trova. Quindi, quando il management ritorna dopo aver parlato con i clienti e vuole sapere perché, posso mostrarli senza dover ricordare l'intera esperienza passo dopo passo.

— Worrystone
fonte