Métricas do código fonte para medir a estabilidade do código?

17

Considerando como o software é desenvolvido durante um ciclo de lançamento (implementação, teste, correção de bugs, lançamento), eu estava pensando que seria possível ver algum padrão nas linhas de código que são alteradas na base de código; por exemplo, no final de um projeto, se o código se tornar mais estável, deve-se observar que menos linhas de código são modificadas por unidade de tempo.

Por exemplo, foi possível observar que, durante os primeiros seis meses do projeto, a média foi de 200 linhas de código por dia, enquanto no último mês foram 50 linhas de código por dia e durante a última semana (pouco antes dos DVDs do produto). foram enviados), nenhuma linha de código foi alterada (congelamento de código). Este é apenas um exemplo, e diferentes padrões podem surgir de acordo com o processo de desenvolvimento adotado por uma equipe específica.

De qualquer forma, existem métricas de código (alguma literatura sobre elas?) Que usem o número de linhas de código modificadas por unidade de tempo para medir a estabilidade de uma base de código? Eles são úteis para ter a sensação de que um projeto está chegando a algum lugar ou se ainda está longe de estar pronto para o lançamento? Existem ferramentas que podem extrair essas informações de um sistema de controle de versão e produzir estatísticas?

code-metrics

— Giorgio
fonte

1

ndepend.com/Features.aspx#BuildComparison

— AakashM

4

"Em segundo lugar, sendo o mecanismo abstrato, sua produção é subsumida em seu design. Nesse aspecto, um programa é como um poema: você não pode escrever um poema sem escrevê-lo. No entanto, as pessoas falam sobre programação como se fosse um processo e medida de produção" produtividade do programador "em termos de" número de linhas de código produzidas ". Ao fazer isso, eles registram esse número no lado errado do razão: devemos sempre nos referir a" o número de linhas de código gastas "." - Os frutos do mal-entendido , Edsger W. Dijkstra.

— yannis

3

@ Yannis Rizos: Não estou sugerindo que a LOC ou a produtividade ou a complexidade do código sejam medidas, porque sei que essa não é uma boa medida. Por outro lado, se 300 linhas de código fossem alteradas dois dias antes do envio, eu, como gerente, teria uma grande lâmpada "ALERTA VERMELHA" em mente (a menos que isso tenha sido planejado e seja o resultado de uma avaliação muito cuidadosa dos riscos ) Em geral, eu assumiria que o código que foi usado (e testado) sem ser alterado por muito tempo é "mais estável" do que o código no qual 100 linhas são alteradas todos os dias.

— Giorgio

2

@Giorgio Argh, fui interrompido (no meio da jornada de trabalho aqui) enquanto estava postando outro comentário (atingi o limite de caracteres no primeiro). Não quis dizer que você estava falando sobre produtividade; a citação de Dijkstra veio à minha mente e achei que seria interessante. De qualquer forma, as métricas de rotatividade de código se aproximam muito do que você está procurando e há muita literatura nelas. Quanto às ferramentas, o FishEye da Atlassian é espetacular.

— yannis

@Yannis Rizos: É realmente uma leitura muito interessante. Quanto ao FishEye, nós o usamos em nosso local de trabalho (para revisões); portanto, examinarei imediatamente o manual e veremos que tipo de estatística podemos produzir.

— Giorgio

17

Uma medida que Michael Feather descreveu é " O conjunto ativo de classes ".

Ele mede o número de classes adicionadas em relação às "fechadas". O encerramento da classe descreve como:

Uma aula é encerrada na data em que não há mais modificações a partir dessa data até o presente.

Ele usa essas medidas para criar gráficos como este: Gráfico de classe ativo

Quanto menor o número da diferença entre as duas linhas, melhor.

Você pode aplicar uma medida semelhante à sua base de código. É provável que o número de classes se correlacione com o número de linhas de código. Pode até ser possível estender isso para incorporar linhas de código por medida de classe, o que pode alterar a forma do gráfico se você tiver algumas grandes classes monolíticas.

— Dave Hillier
fonte

4

Desde que exista um mapeamento relativamente consistente de recursos para as classes ou, nesse caso, sistema de arquivos, você poderá conectar algo como gource ao seu sistema de controle de versão e obter rapidamente uma noção de onde a maior parte do desenvolvimento está focada (e, portanto, quais partes do código são as mais instáveis).

Isso pressupõe que você tenha uma base de código relativamente organizada. Se a base de código for uma bola de barro, você verá essencialmente cada pequena parte sendo trabalhada devido a interdependências. Dito isto, talvez isso por si só (o agrupamento durante o trabalho em um recurso) seja uma boa indicação da qualidade da base de código.

Ele também pressupõe que sua equipe de negócios e desenvolvedores como um todo tenha alguma maneira de separar recursos no desenvolvimento (seja ramificações no controle de versão, um recurso por vez, qualquer que seja). Se, por exemplo, você estiver trabalhando em três recursos principais no mesmo ramo, esse método produzirá resultados sem sentido, porque você tem um problema maior do que a estabilidade do código em suas mãos.

Infelizmente, não tenho literatura para provar meu argumento. É baseado apenas na minha experiência de usar o gource em boas (e não tão boas) bases de código.

Se você estiver usando git ou svn e sua versão do gource for> = 0.39, é tão simples quanto executar o gource na pasta do projeto.

— Carl
fonte

O gource também parece ser uma ótima ferramenta! (+1)

— Giorgio

1

Eu me deparei com essa resposta e passei as seis horas seguintes brincando com Gource. Não tenho certeza se isso merece +1 ou -1, mas, caramba, essa é uma ferramenta interessante.

— 22413 RonU

@RonU: Você pode usar o gource para visualizar o estado do repositório em um intervalo de tempo personalizado. O ponto é que ele visualiza a atividade em sua base de código ao longo do tempo. A facilidade de interpretação das informações depende de muitos fatores, como expliquei na minha resposta acima. Sim, é uma ferramenta incrível, se você quiser a "imagem grande", então acho que merece um +1;) #

— Carl

Sim, quando eu disse "seis horas", não quis dizer que eu executei um sim do Gource para aquela época ... apenas que brinquei com muitas opções, canalizei para o ffmpeg, possivelmente adicionei uma trilha sonora épica etc. foi bastante a toca do coelho. :)

— RonU

Deixe-me adivinhar. A trilha sonora foi o Harlem Shuffle em loop;)

— Carl

0

O uso da frequência das linhas modificadas como um indicador para a estabilidade do código é pelo menos questionável.

Inicialmente, a distribuição ao longo do tempo das linhas modificadas depende muito do modelo de gerenciamento de software do projeto. Existem grandes diferenças nos diferentes modelos de gerenciamento.

Em segundo lugar, a vítima nesta suposição não é clara - é a menor contagem de linhas modificadas causada pela estabilidade do software, ou simplesmente porque o prazo termina e os desenvolvedores decidiram não fazer algumas alterações agora, mas fazê-lo após o liberação?

Em terceiro, a maioria das linhas é modificada quando novos recursos são introduzidos. Mas o novo recurso não torna o código não estável. Depende da habilidade do desenvolvedor e da qualidade do design. Por outro lado, até erros graves podem ser corrigidos com poucas linhas alteradas - nesse caso, a estabilidade do software aumenta significativamente, mas a contagem de linhas alteradas não é muito grande.

— johnfound
fonte

"Depende da habilidade do desenvolvedor e da qualidade do design.": Mas você precisa de pelo menos algum tempo para testar as alterações para ter confiança suficiente para não ter introduzido nenhum erro. Até os desenvolvedores mais habilidosos podem cometer erros de digitação, por exemplo, se estiverem sob pressão, fizerem muitas horas extras ou tiverem dormido muito pouco. Além disso, se você aplicar o princípio aberto / fechado, após algum tempo, o número de alterações (correções de bugs) deverá diminuir. De qualquer forma, afirmei explicitamente na minha pergunta que o resultado de tal medição pode mudar de acordo com o processo de desenvolvimento.

— Giorgio

BTW, o código pode ser instável não porque os desenvolvedores são ruins, mas porque os requisitos não são claros e o projeto ainda está em fase de prototipagem.

— Giorgio

@Giorgio: Claro que você está certo. Mas foi exatamente isso que escrevi: a contagem de linhas modificadas depende muito de muitos fatores. Alguns deles relacionados à estabilidade do código, outros não. É como tentar calcular quantas pessoas fazem sexo, medindo a energia elétrica, assumindo - menos energia - menos luzes - mais sexo. Embora esteja provado que a taxa de natalidade está aumentando após grandes apagões. ;)

— johnfound

-1

Robustez é um termo relacionado à função correta de um conjunto de instruções, não à quantidade, verbosidade, concisão gramatical do texto usado para expressar essas instruções.

De fato, a sintaxe é importante e deve estar correta, mas qualquer coisa além disso, pois se refere à função desejada das instruções, observando as 'métricas' das instruções, é semelhante a traçar seu futuro lendo o padrão de folhas de chá na parte inferior da tela. você xícara de chá.

A robustez é medida por meio de testes. Testes unitários, testes de fumaça, testes de regressão automatizados; testes, testes, testes!

Minha resposta para sua pergunta é que você está usando a abordagem errada na busca de uma resposta para uma de robustez. É um arenque vermelho que linhas de código significam algo mais do que linhas de ocupação de código. Você só pode saber se o código faz o que você deseja fazer se testar se está fazendo o que é necessário.

Revise os equipamentos de teste adequados e evite o misticismo do código métrico.

Muitas felicidades.

— Sassafras_wot
fonte

3

Eu afirmei explicitamente que não estava sugerindo LoC como uma medida da complexidade do código. Eu estava sugerindo as alterações no código como uma medida de estabilidade do código: um pedaço de código tem requisitos funcionais estáveis e uma implementação estável e testada que atende a esses requisitos?

— Giorgio

Eu não quero discutir com você, mas respeitosamente o afastar da loucura da falta de sentido na métrica do código. Reli a pergunta e todos os seus exemplos indicam um desejo de inferir um relacionamento entre as linhas de código serem alteradas e a robustez resultante. Entendo que, quanto mais palavras você digita, maior a probabilidade de você digitar um erro de digitação. Mas sou tão contra o princípio do que você pede que devo sair fortemente a favor de você abandonar sua busca dessa maneira. Boas práticas de teste = boa probabilidade de robustez.

— Sassafras_wot

"Boas práticas de teste = boa probabilidade de robustez.": Concordo totalmente. É por isso que estou sugerindo que um pedaço de código que foi alterado recentemente precisa ser testado novamente antes de termos certeza de que está correto.

— Giorgio

Existem várias definições de estabilidade e uma delas é o que você está argumentando. É uma interpretação semântica diferente da que eu fiz. Tomei estável para dizer, que é "não sujeito a extrema muda" ao invés de "resistentes à mudança"

— Dave Hillier