Perché le statistiche di commit degli sviluppatori sono dannose?

Ho creduto a lungo (e sentito da altri) che tenere traccia delle statistiche di commit, come il numero di commit che ogni sviluppatore fa ogni giorno, è dannoso per il processo di sviluppo. Il motivo sembra ovvio: gli sviluppatori si impegneranno in incrementi più piccoli, massimizzando il loro numero di commit al giorno, ma rendendo più difficile il sezionamento (forse tutte le loro patch intermedie non lasceranno il repository ben formato) e più difficile lavorare con la cronologia del commit (una modifica avverrà all'improvviso in più commit, anziché in uno solo, è più difficile ripristinare una patch, ecc.).

Ci sono studi che mostrano che le statistiche di commit sono dannose? Qualche articolo elegante e ben discusso sull'argomento? Altrettanto applicabile sarebbe qualcosa sul perché misurare la cosa sbagliata porta le persone a ottimizzare la cosa sbagliata, di cui questo problema è solo un caso speciale.

version-control

— Neil Mitchell
fonte

"Qualsiasi articolo elegante e ben discusso" ?? La tua domanda è elegante e ben argomentata. Cosa ti serve ancora? Hai fornito ampie prove del fatto che i numeri sono banalmente giocati e quindi inutili. Cosa vuoi di più della tua domanda elegante e ben argomentata?

— S. Lott

Gli sviluppatori devono aver provato a lavorare con la ricerca e la correzione di bug in scenari con commit di grandi dimensioni e commit piccoli per vedere le differenze.

Non penso che raccogliere le statistiche sia dannoso in sé, ma usarlo per valutare i programmatori lo sarebbe. Il nostro VCS raccoglie queste informazioni, insieme a una miriade di altre statistiche, ed è disponibile per tutto il team, ma non le guardiamo quasi mai. Quindi no, raccogliere le statistiche non è dannoso.

— MarkJ,

Non sto discutendo qui di commit grandi o piccoli (sono personalmente un tipo di commit piccolo), ma semplicemente una pressione esterna per cambiare la dimensione del commit per falsare una statistica (che non può mai essere buona). Idealmente sto cercando un posto in cui posso indicare gli altri, quindi non devo discutere personalmente :)

— Neil Mitchell,

Credo che questo fumetto di Dilbert sia il caso e tutto ciò che abbia mai visto.

— ebneter,

Risposte:

http://www.mit.edu/~hauser/Papers/Hauser-Katz%20Measure%2004-98.pdf

È questo il tipo di cosa che stai cercando? Esistono migliaia di articoli "Ottieni solo ciò che misura" trovati da Google.

— S. Lott
fonte

Normalmente non voterei sostanzialmente una risposta solo link + nessun estratto, ma in questo caso specifico la trovo bene, dato che "la risposta" sarebbe comunque la domanda stessa.

— o0 '.

È una statistica divertente da misurare, ma non più utile della registrazione del numero di ore di lavoro di uno sviluppatore durante la settimana.

Per uno, non tiene conto della qualità del codice. Uno sviluppatore potrebbe impegnarsi continuamente mentre continua a correggere i bug nel suo codice. Ciò mostrerebbe un gran numero di commit, rispetto a uno sviluppatore che commette un pezzo di codice finito e raffinato. Non penseresti che il ragazzo con il conteggio di commit maggiore fosse lo sviluppatore migliore.

Allo stesso modo, qualcuno che si rilassa e naviga in SO tutto il giorno solo per impegnarsi una volta al giorno avrebbe lo stesso conteggio di commit dello sviluppatore dedicato che ha trascorso tutto il giorno a programmare solo per eseguire un commit finale alla fine del giorno per mantenere il suo codice al sicuro.

Se hai un sistema in cui vengono contate le righe di codice impegnate, il tipo che passa attraverso il "refactoring" dei file sorgente ogni parentesi graffa nel suo stile preferito avrà un valore enorme. Il tizio che ha fatto il bugfix supremo di 1 riga si presenterà a malapena.

Quindi non ha alcuna statistica significativa anche se gli sviluppatori non giocano il sistema. Non dovrebbe fornirti altro che un bel grafico. Tuttavia a tutti piacciono le statistiche, quindi direi di tenerle, ma non usarle per altro che divertimento.

— gbjbaanb
fonte

Mentre la tua opinione è interessante, la vera domanda sembra essere "ci sono studi ...?" a cui la tua risposta non risponde.

— Bryan Oakley,

"numero di righe". Potrebbero essere necessari diversi giorni per ricercare un problema che alla fine si tradurrà in una patch a linea singola.

solo una favola , ma classica.

— Wrikken,

Questi "diversi giorni" (o almeno diverse ore) di ricerca che hanno portato a una correzione molto importante ma a linea singola si verificano abbastanza spesso nella mia esperienza.

— Johan