Usando resultados de compilação contínuos como parte das métricas de análise de desempenho? [fechadas]

Fechadas. Esta questão está fora de tópico . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela esteja no tópico do Software Engineering Stack Exchange.

Fechado há 4 anos .

Meu chefe está planejando usar as métricas de nossa criação contínua (cria e executa testes em todas as confirmações) como parte de nossas análises de desempenho (em nossa métrica de 'qualidade'). Isso me parece uma péssima idéia, mas eu gostaria de saber se alguém estudou isso ou já viu isso antes.

Meu pensamento é que nossos desenvolvedores não façam tantos testes quanto de outra forma, por medo de que os testes falhem. Eu sinto que ele está transformando uma ferramenta valiosa de desenvolvedor em um bastão para vencer os desenvolvedores.

O contra-argumento óbvio é que ele promoverá as pessoas com mais cuidado antes de se comprometerem e, portanto, levando a uma qualidade superior.

Estou fora da base aqui? Deixe de lado a questão de saber se devemos ou não fazer análises de desempenho - isso já foi respondido em outro lugar.

continuous-integration

— Michael Kohne
fonte

Qualquer sistema que possa ser utilizado em jogos é uma entrada horrível para uma avaliação de desempenho.

— 101311 Steve Jackson

Todo mundo tem a opção de não testar?

— JeffO

@ Steve, e "sistemas" que não podem ser usados oferecem uma visão minúscula e estreita da imagem maior. Para rastrear com precisão o desempenho, seria necessário trabalho de pernas.

— maple_shaft

Observe que algumas coisas funcionam bem em máquinas de desenvolvedores, mas falham no servidor de compilação (uma dependência acidental de um jar externo, maneira incorreta de usar / e \ nas caixas Linux etc.). O principal motivo do servidor de construção é capturar essas coisas, não incomodar ninguém por não testá-las primeiro. Em outras palavras, essa é uma péssima idéia.

Acompanhamento: Depois que começamos a fazer isso, descobri que o maior problema não tinha nada a ver com os outros engenheiros e a vontade de escrever testes adequados, mas sim com o fato de que nossos testes existentes eram REALMENTE instáveis, portanto, todos os commit tinham uma chance muito grande de romper sem culpa da pessoa que está fazendo o commit. Esse fator atenuou o entusiasmo de todos em testar muito mais do que quaisquer efeitos da análise de desempenho.

— Michael Kohne

Respostas:

As análises de desempenho são boas, mas e métricas úteis, como:

Porcentagem de cobertura do teste de unidade em recursos
Capacidade de cumprir prazos
Documentação clara e concisa
Siga as convenções de codificação apropriadas
Comunica-se bem com os outros
Capacidade de transformar requisitos e histórias de usuários em tarefas

Todas essas são boas maneiras de medir o desempenho, mas os problemas que a gerência parece ter com eles são que eles realmente exigem ... ummm ... bem, você sabe ... TRABALHO REAL por parte deles.

Infelizmente, a maioria dos gerentes tem a atitude: "Para o inferno, eu quero julgar meus funcionários por métricas que não exigem que eu acompanhe o que estão fazendo".

— maple_shaft
fonte

+1 por fornecer algumas boas opções de quais métricas são úteis.

— David Ruttka

Jogar com o sistema aqui é bastante provável, na minha opinião, e seu chefe precisa encontrar maneiras de impedir que isso seja realidade. O outro caso que você não mencionou é onde os desenvolvedores cometem muitas vezes, para que ocorra uma enxurrada de check-ins em que o número de modificações é relativamente baixo, como se houvesse alguma parte da revisão em que a contagem de builds é usada dessa maneira. é onde isso se torna uma nova ferramenta que pode ser mal utilizada com facilidade. Estou pensando em check-ins onde algo é renomeado ou o espaço em branco é alterado é um check-in e conta como alguma forma de produtividade seria a visão pedante.

— JB King
fonte