Por que as estatísticas de confirmação de desenvolvedor são prejudiciais?

10

Acredito há muito tempo (e ouvi de outras pessoas) que acompanhar as estatísticas de confirmação, como quantas confirmações cada desenvolvedor faz por dia, é prejudicial ao processo de desenvolvimento. O motivo parece óbvio - os desenvolvedores se comprometem em incrementos menores, maximizando seu número de consolidação por dia, mas dificultando a divisão (talvez todos os patches intermediários não deixem o repositório bem formado) e mais difícil trabalhar com o histórico de consolidação (uma mudança repentinamente ocorrerá em vários commits, em vez de apenas um, reverter um patch é mais difícil etc.).

Existem estudos que mostram estatísticas de confirmação prejudiciais? Algum artigo elegante e bem discutido sobre o assunto? Igualmente aplicável seria qualquer coisa sobre por que medir a coisa errada leva as pessoas a otimizar a coisa errada, da qual esse problema é apenas um caso especial.

version-control Neil Mitchell
fonte
8
"Qualquer artigo elegante e bem argumentado"? Sua pergunta é elegante e bem fundamentada. O que mais você precisa? Você forneceu ampla evidência de que os números são triviais e, portanto, inúteis. O que mais você quer do que sua pergunta elegante e bem argumentada?
S.Lott
Os desenvolvedores precisam ter tentado trabalhar com a localização e a correção de bugs nos cenários de confirmação grande e confirmação pequena para ver as diferenças.
Eu não acho que reunir a estatística seja prejudicial por si só, mas usá-lo para avaliar programadores seria. Nosso VCS reúne essas informações, junto com uma infinidade de outras estatísticas, e está disponível para toda a equipe, mas quase nunca as analisamos. Portanto, não, reunir a estatística não é prejudicial.
precisa saber é
Não estou debatendo grandes e pequenos commits aqui (eu pessoalmente sou um tipo de sujeito de commit pequeno), apenas pressão externa para alterar o tamanho do commit para falsificar uma estatística (o que nunca pode ser bom). Eu estou procurando idealmente em algum lugar eu posso apontar outros em, então eu não tenho que fazer o argumento de mim :)
Neil Mitchell
2
Eu acredito que esse quadrinho de Dilbert é o caso e tudo o que eu já vi.
Ebneter

Respostas:

8

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

É esse o tipo de coisa que você está procurando? Existem milhares de artigos "você só consegue o que mede" encontrados pelo Google.

S.Lott
fonte
11
Normalmente, eu não aprovaria uma resposta basicamente apenas com link + sem trecho, mas neste caso específico, acho que está bem, já que "a resposta" seria apenas a própria pergunta de qualquer maneira.
o0 '.
6

É uma estatística divertida de medir, mas não é mais útil do que registrar o número de horas que um desenvolvedor trabalhou durante a semana.

Por um lado, não leva em consideração a qualidade do código. Um desenvolvedor pode estar se comprometendo continuamente, enquanto continua corrigindo erros em seu código. Isso mostraria um grande número de confirmações, em comparação com um desenvolvedor que confirma um pedaço de código finalizado e polido. Você não pensaria que o cara com maior número de confirmações era o melhor desenvolvedor.

Da mesma forma, alguém que relaxa e navega no SO o dia inteiro apenas para confirmar uma vez por dia teria a mesma contagem de confirmação que o desenvolvedor dedicado que passou o dia inteiro codificando apenas para fazer uma confirmação final no final do dia para manter seu código seguro.

Se você possui um sistema no qual as linhas de código confirmadas são contadas, o cara que passa pelos arquivos de origem 'refatorando' cada colchete para o estilo preferido dele terá um valor enorme. O cara que fez o bug de 1 linha sup-importante mal aparecerá.

Portanto, não faz nenhuma estatística significativa, mesmo que os desenvolvedores não joguem o sistema. Não deve fornecer nada, exceto um gráfico bonito. No entanto, todo mundo gosta de estatísticas, então eu diria que as mantenha, mas não as use para nada além de diversão.

gbjbaanb
fonte
Embora sua opinião seja interessante, a questão real parece ser "existem estudos ...?" qual sua resposta não aborda.
Bryan Oakley
"número de linhas". Pode levar vários dias para pesquisar um problema que acabará resultando em um patch de linha única.
5
apenas um conto , mas clássico.
Wrikken
Esse "vários dias" (ou pelo menos várias horas) de pesquisa, resultando em uma correção de linha muito importante, mas única, acontece com bastante frequência na minha experiência.
Johan