Quais são as métricas úteis para o código fonte? [fechadas]


33

Quais são as métricas úteis para capturar para o código-fonte?

Como as métricas, como por exemplo, linhas de código (executáveis) ou complexidade ciclomática, ajudam na garantia da qualidade ou como elas são benéficas em geral para o processo de desenvolvimento de software?


37
A única medida válida é WTF / s. :)
terminus


Respostas:


30

"Medir a produtividade do software por linhas de código é como medir o progresso em um avião, quanto pesa." - Bill Gates


3
Por favor, não atualize as não respostas.
Eric Wilson

3
Embora seja uma anedota divertida, essa resposta pouco contribui para a resposta dessa pergunta.
Chris Knight

7
@ Chris Esta resposta recebeu muitos votos positivos (ou "atualizações", como o FarmBoy quer chamar), porque muitos desenvolvedores acreditam que as métricas de software são inúteis. Se você não concorda ou acha que tem uma resposta melhor à pergunta, poste sua própria resposta. Comentar como você fez aqui não é produtivo; você mesmo não contribuiu com nada.
Chrisaycock

7
Meu voto negativo e comentário destinam-se a desencorajar respostas que não têm profundidade e não abordam diretamente a pergunta do OP. Essa poderia ser uma resposta muito melhor se você entrar em mais detalhes sobre o motivo pelo qual acredita que as métricas de software são inúteis no que diz respeito ao desenvolvimento e garantia de qualidade e focadas em mais do que apenas o LOC.
Chris Knight

As métricas de software são realmente muito úteis se você as usar corretamente. Ou seja, quanto mais LoC -> mais erros -> pior é a qualidade. Eu nunca vi isso falhar como uma medida de qualidade. E um avião é definitivamente melhor se fizer a mesma viagem na mesma velocidade, mas exigir muito menos peso. Obviamente Bill Gates não sabia muito sobre aviões quando disse isso, nem sabia o suficiente sobre software, ao que parece.
Pablo Ariel

12

Dê uma olhada nas postagens de Jeff sobre o assunto:

Uma visita da Metrics Maid

Engenharia de software: morta?

Também existe uma publicação antiga, mas boa, de Joel, intimamente relacionada às métricas de software, e eu recomendo fortemente a sua leitura: The Econ 101 Management Method

O ponto chave, para mim, é esse, citando Jeff: "O uso responsável das métricas é tão importante quanto coletá-las em primeiro lugar".


+1 por citar a frase única de Jeff. Sabedoria pura, endurecida pela batalha, bem ali.
Luis.espinal

11

O que me confunde sobre as métricas de código é que isso não é feito mais. A maioria das empresas informa sobre a eficiência de seus funcionários, fornecedores e sistemas, mas ninguém parece querer informar sobre código. Definitivamente, concordo com as respostas que afirmam que mais linhas de código são uma responsabilidade, mas o que seu código faz é mais importante.

Linhas de Código: Como mencionei, essa é uma medida vital e deve ser levada mais a sério, mas em cada nível. Funções, classes, arquivos e interfaces podem indicar código de fazer tudo que é difícil de manter e caro a longo prazo. É infinitamente difícil comparar o total de linhas de código versus o que um sistema faz. Pode ser algo que faz muitas coisas e, nesse caso, haverá muitas linhas de código!

Complexidade: É bom fazer essa medição em bases de código nas quais você não trabalhou e pode fornecer uma boa indicação de onde estão as áreas problemáticas. Como uma anedota útil, medi a complexidade em uma de minhas próprias bases de código, e a área de maior complexidade era a que eu passava mais tempo quando precisava alterá-la. Trabalhar para reduzir a complexidade resultou em uma redução maciça no tempo de manutenção. Se o gerenciamento tivesse essas medidas em mãos, ele poderia planejar a refatoração de iterações ou o redesenho de áreas específicas de um sistema.

Duplicação de código: Esta é uma medida muito importante para mim. A duplicação de código é um sinal muito ruim e pode apontar problemas profundos em níveis baixos do design de um sistema ou desenvolvedores que são coladores de cópias, causando grandes problemas a longo prazo e sistemas que são inatingíveis.

Gráficos de dependência Encontrar dependências ruins e dependências circulares são uma medida importante no código. Isso quase sempre aponta para um design de alto nível incorreto que precisa ser revisado. Às vezes, uma dependência pode absorver muitas outras desnecessárias, porque alguém está usando addNumber em uma biblioteca de email para fazer seus cálculos financeiros. Todos ficam chocados quando a biblioteca de email é alterada e o financiamento é interrompido. Se tudo depende de uma coisa, também pode apontar bibliotecas que fazem tudo que são difíceis de manter e mal projetadas.

Uma boa medida sempre indica que todos os recursos de um sistema têm uma pequena área ocupada. Menos dependências, menos complexidades, menos duplicação. Isso aponta para um acoplamento fraco e alta coesão.


8

Essa "métrica do código fonte" não será uma porcaria?

SLOC (Raw Source Lines of Code) é a métrica mais antiga, mais fácil e mais básica que existe.

Halstead originalmente propôs um monte de métricas. Muitas pessoas estavam se divertindo muito com programas de medição de escrita até que algum esporte estragado fizesse o estudo óbvio, e demonstraram que cada uma das métricas de Halstead estava fortemente correlacionada diretamente com o SLOC.

Nesse ponto, as métricas de Halstead foram abandonadas, porque o SLOC é sempre mais fácil de medir.


1
Algum link para o estudo?
Jon Hopkins

O Google é seu AMIGO, mas aqui está um para você começar. ecs.csun.edu/~rlingard/comp589/HoffmanArticle.pdf
John R. Strohm

6
Estudo interessante, embora o estudo deles só tenha analisado programas geralmente entre 50 e 100 linhas de código. Com um problema tão pequeno e bem definido a resolver, o resultado final não parece tão surpreendente.
Chris Knight

Eu diria que, no mundo real, todos esses estudos se transformam em lama.
Warren P

Isso é verdade. Quanto mais linhas de código, menor a qualidade.
Pablo Ariel

8

As métricas de código-fonte para garantia de qualidade visam dois objetivos:

  • escrever código com menos erros dentro
  • escrever código para facilitar a manutenção

Ambos levam a escrever código da maneira mais simples possível. Isso significa:

  • unidades curtas de código (funções, métodos)
  • poucos elementos em cada unidade (argumentos, variáveis ​​locais, instruções, caminhos)
  • e muitos outros critérios mais ou menos complexos (consulte Métrica de software na Wikipedia).

7

Que eu saiba, o número de bugs encontrados está diretamente relacionado às linhas de código (provavelmente rotatividade), linguagem do módulo, programador e domínio.

Não conheço nenhuma outra métrica direta e prática bem correlacionada com bugs.

Uma coisa que eu gostaria de fazer é começar a executar os números para diferentes projetos em que estou participando - Test Coverage :: kLOC e discutir a "qualidade percebida" para ver se há uma correlação.


1
Então, quanto mais código houver, mais erros haverá nele?

3
@ Thor: sim sim. chocante, hein?
Paul Nathan

Tanto quanto me lembro, os números típicos da indústria são de cerca de 2 a 3 erros por 1.000 linhas de código para projetos médios, aproximando-se de algo como 0,5 erros por 1.000 linhas de código para software de controle de usinas nucleares ou projetos da NASA onde eles envidam uma quantidade enorme de esforço , controle, teste, revisão etc. porque falhas podem ter conseqüências muito graves. Alguém que tenha alguma referência a números que apóiam isso?
hlovdal

2
@hlovdal: 2-3 erros por KSLOC já é um valor muito baixo. Os números mais baixos que conheço nos domínios aeroespacial e de segurança são da ordem de 0,1 erros por KSLOC. Os números típicos parecem ser de 20 a 50 erros por KSLOC. Para referência, o artigo do Google para Andy German intitulado "Análise de código estático de software - Lições aprendidas".
Agendador

1
Eu contestaria esses números - depende inteiramente da linguagem, compilador e ambiente executável. Erros de digitação no código JavaScript podem levar anos para serem encontrados, mas um erro de digitação em uma linguagem compilada seria encontrado na primeira compilação.
JBRWilkinson

7

As métricas são úteis apenas se você souber o que fazer com as respostas recebidas. Em essência, uma métrica de software é como um termômetro. O fato de você medir algo a 98,6 ° F não significa nada até você saber qual é a temperatura normal . A temperatura acima é boa para a temperatura corporal, mas muito ruim para sorvete.

Métricas comuns que podem ser úteis são:

  • Erros descobertos / semana
  • Erros resolvidos / semana
  • # Requisitos definidos / liberação
  • # Requisitos implementados / liberação

As duas primeiras medidas avaliam as tendências. Você encontra bugs mais rapidamente do que pode corrigi-los? Dois resultados possíveis: talvez precisemos de mais recursos para consertar bugs, talvez precisemos parar de implementar novos recursos até o alcançarmos. Os dois segundos fornecem uma imagem de quão perto você está de ser feito. As equipes ágeis chamam de gráfico de "queima".

Complexidade ciclomática é uma métrica interessante. No conceito básico, é o número de caminhos de execução exclusivos em uma função / método. Em um ambiente pesado de teste de unidade, isso corresponde ao número de testes necessários para verificar todos os caminhos de execução. No entanto, apenas porque você tem um método que tem uma complexidade ciclomática de 96 não significa que seja necessariamente um código de buggy - ou que você precisa escrever 96 testes para fornecer confiança razoável. Não é incomum o código gerado (por meio de geradores WPF ou analisador) criar algo tão complexo. Ele pode fornecer uma idéia aproximada do nível de esforço necessário para depurar um método.

Bottom Line

Toda medida que você faz precisa ter o seguinte definido ou é inútil:

  • Uma compreensão do que é "normal". Isso pode ser ajustado ao longo da vida do projeto.
  • Um limite fora do "normal" onde você precisa executar algum tipo de ação.
  • Um plano para lidar com o código quando o limite for excedido.

As métricas que você utiliza podem variar bastante de projeto para projeto. Você pode ter algumas métricas usadas em projetos, mas a definição de "normal" será diferente. Por exemplo, se um projeto descobriu uma média de 5 erros / semana e o novo projeto descobriu 10 erros / semana, isso não significa necessariamente que algo está errado. Pode ser que a equipe de teste seja mais meticulosa desta vez. Além disso, a definição de "normal" pode mudar ao longo da vida do projeto.

A métrica é apenas um termômetro, o que você faz com ela depende de você.


Outro bug relacionado a isso que pode ser útil em alguns casos são os erros por linhas de código. Em geral, as bases de código maduras devem ter um número bastante baixo de bugs por linhas de código, em oposição aos aplicativos que ainda estão em desenvolvimento.
rjzii

@ Rob Z, com qualquer métrica, as pessoas farão o suficiente para otimizar essa métrica. Em bugs por linha de código, um desenvolvedor pode introduzir uma variável não utilizada que eles incrementam apenas para aumentar o número de LOC sem bugs (já que os contadores SLOC podem detectar vários pontos e vírgulas). Obviamente, isso também aumenta artificialmente a quantidade de código a ser percorrida.
Berin Loritsch

6

O código fonte é um passivo, não um ativo. Com isso em mente, medir linhas de código é análogo ao rastreamento de dólares gastos durante a construção de uma casa. Isso precisa ser feito se você quiser ficar abaixo do orçamento, mas não necessariamente pensaria que gastar US $ 1.000 por dia é melhor do que gastar US $ 50 por dia; você gostaria de saber quanto da casa foi construída para esse dinheiro. É o mesmo com as linhas de código em um projeto de software.

Em resumo, não há métricas úteis para o código-fonte, porque a medição do código-fonte por si só não é útil.


4

Como o código fonte é simplesmente uma combinação de sequência, seleção e repetição. Se eu descrevesse o software mais ideal que poderíamos esperar razoavelmente produzir, seria o seguinte. Software com quase 100% de cobertura de código de teste usando a menor quantidade de linhas de código necessária para realizar o trabalho e, no entanto, flexível o suficiente para suportar alterações.


2
100% de cobertura é apenas 100% se cobrir todos os caminhos, não apenas todas as linhas. Em qualquer software realista, a cobertura de 100% do caminho é uma péssima meta a ser estabelecida, porque será muito caro alcançá-lo e ainda informará apenas que seu código se comporta como projetado, não que o design em si seja sólido. Você pode ter brechas na segurança e ter 100% de cobertura de caminho.
Joeri Sebrechts

+1 Mais código fonte não é necessariamente melhor.
Larry Coleman

Somente aplicativos muito simples são passíveis de 100% de cobertura de teste (tornando a cobertura redundante). É computacionalmente caro (se não inviável) obter 100% de cobertura de teste para software complexo. Conhecemos esse fato há seis décadas. Em segundo lugar, o teste apenas informa que você não encontrou um erro - não garante que não haja erros relacionados à qualidade, tamanho ou complexidade estrutural (algo que também é conhecido há muito tempo). no software é semelhante a um físico que não conhece realmente as leis da termodinâmica.
Luis.espinal

@ luis.espinal Um software tão grande que é computacionalmente caro demais para testar é um software incrivelmente mal escrito. Está perto de não ter idéia de como criar software funcional.
Pablo Ariel

@ PabloAriel - "Software tão grande que é computacionalmente caro demais para testar" << Não foi isso que eu disse. Leia o comentário (talvez duas ou três vezes) para se certificar de que você está realmente lendo o que pensa estar lendo.
Luis.espinal

4

Uma anedota para mostrar por que as contagens do KLOC são inúteis (e até prejudiciais) para medir o desempenho.

Anos atrás, trabalhei em um grande projeto (mais de 70 pessoas em nossa empresa, outras 30 em nosso cliente) que usavam as contagens da KLOC como a única medida de desempenho de equipes e indivíduos.

Para o nosso esforço do ano 2000 (informa há quanto tempo :): fizemos uma grande limpeza da seção do código pela qual minha equipe era responsável. Terminamos o lançamento escrevendo cerca de 30.000 linhas de código, não três meses ruins de trabalho para 5 pessoas. Também acabamos descartando outras 70.000 linhas de código, um trabalho muito bom por 3 meses de trabalho, especialmente combinado com o novo código.

Resultado final do trimestre: -40.000 linhas de código. Durante a análise de desempenho após o trimestre, recebemos uma repreensão oficial da empresa por não atender às nossas exigências de produtividade de 20.000 linhas de código produzidas por trimestre (afinal, as ferramentas mostraram que produzimos -40.000 linhas de código), o que resultaria em todos nós listados como de baixo desempenho e ignorados em promoções, treinamento, aumento de salário etc. etc., se o gerente de projeto e a equipe de controle de qualidade não tivessem intervindo e conseguido a reprimenda revertida e substituída por uma recomendação.

Alguns meses depois (essas coisas levam tempo), fomos informados de que a empresa estava revisando seus padrões de produtividade e contratamos uma equipe de especialistas para criar um novo sistema baseado na análise de pontos de função.


Por que você não mostrou as diferenças ?!
Reinierpost

Eu acho que foi o que foi feito. Mas se um sistema é tão rígido que nem toca um alarme quando um ponto de dados tão flagrantemente falso aparece, não será muito bom.
Jwenting

2
Sua resposta não mostra que o KLOC é inútil, mostra como não usá-los.
Neil N

2
mostra que confiar neles como uma medida de produtividade é míope, confiar neles como a única medida é idiota. Em outros projetos que usam o KLOC como uma medida de produtividade e mesmo de qualidade, aumentamos os números com facilidade, criando padrões de codificação que causam cargas de linhas (práticas de reforço de C ++, linhas vazias extras com apenas um breve comentário em todos os lugares, dividindo as condições em uma declaração if sobre 3 linhas, etc.).
Jwenting

1
Usar o SLOC como uma métrica de produtividade é simplesmente idiota e provavelmente nunca dará bons resultados. Usar o SLOC como uma métrica de qualidade indicando manutenção e número de defeitos é mais sensato, com todas as advertências já discutidas nesta questão.
Redcalx #

2

Estou surpreso que ninguém tenha mencionado os testes de declaração / decisão de cobertura de unidade (porcentagem de código exercido por testes de unidade) ainda.

A cobertura do código é útil, pois você sabe qual porcentagem do aplicativo não falha catastrofricamente; com o restante de sua utilidade depende da qualidade dos testes de unidade.


a cobertura do código também é uma métrica falsa (embora possa ter algum uso). Ele convida a escrever testes sem sentido apenas para obter uma cobertura mais alta. E é claro que há coisas que nunca serão cobertas, e as pessoas começarão a evitar escrever essas coisas. por exemplo, eu vi ferramentas de cobertura de código que sinalizavam o JavaDoc como código e, é claro, não seriam cobertas. outra ferramenta sinalizou todas as linhas vazias como não sendo cobertas por testes. Você concorda que acabar com os comentários e os espaços em branco no seu código é pior do que perder testes de unidade para alguns levantadores, espero?
jwenting

Absolutamente, testes de unidade ruins doem mais do que ajudam de várias maneiras. Por exemplo, você pode obter 100% de cobertura de código para um conjunto de testes que não possuem uma única declaração.
StuperUser

1

Quanto menor o commit, melhor, geralmente. Trata-se de ferramentas de SCM, não de código em si, mas é uma métrica muito mensurável. Quanto menor o commit, mais fácil é ver cada alteração como uma unidade atômica; mais fácil é reverter mudanças específicas e identificar quando as coisas quebraram.

Contanto que nenhum commit interrompa a compilação ...


1

Essas não são métricas absolutas muito úteis em termos de progresso, mas podem ser usadas para fornecer uma idéia geral do estado do código.

Consideravelmente a Complexidade Ciclomática Eu descobri que é útil em termos de visualização da modularidade de uma determinada base de código. Você geralmente deseja uma baixa complexidade, pois isso significa que o número de fontes por módulo é baixo e há muitos módulos.


1

Costumo trabalhar em um pacote C ++ gigante e, ao procurar um código problemático que valha a pena refatorar a Complexidade Ciclomática ou o horrível FanIn / FanOut, geralmente são boas bandeiras vermelhas para procurar. A correção de problemas normalmente leva a melhorias em toda a base de código.

É claro que esses números podem servir apenas como uma dica sobre o que valeria a pena examinar. Tornar isso um limite rígido após o qual falhar uma compilação ou recusar uma consolidação seria ridículo.


1

Existem muitas situações no meu trabalho em que uso métricas de código:

Ao escrever o código

O maior e talvez o mais importante uso no meu trabalho diário é no Checkstyle , uma ferramenta para desenvolvedores de java que verifica continuamente as métricas (entre outras coisas) do meu código em relação a um conjunto de regras que definimos e sinaliza lugares onde meu código não cumprir essas regras. À medida que desenvolvo o código, ele informa em tempo real se meus métodos se tornam muito longos, complexos ou acoplados, o que me permite retroceder e pensar em refatorá-lo para algo melhor.

Os desenvolvedores são totalmente livres para violar todas as regras, pois nunca se aplicam a todas as situações. As "regras" existem para estimular o pensamento e dizer "Ei, essa é a melhor maneira de fazer isso?"

Durante revisões de controle de qualidade / código

A primeira coisa que geralmente faço quando faço uma revisão de código é verificar a cobertura do código que estou revisando em conjunto com uma ferramenta de cobertura de código que destaca quais linhas de código foram cobertas. Isso me dá uma idéia geral de quão completo é o código de teste. Realmente não me importo se a cobertura é de 20% ou 100%, desde que o código importante seja bem testado. Assim, a porcentagem coberta é um tanto sem sentido, mas 0% com certeza se destaca como um polegar dolorido como algo que eu quero examinar com cuidado.

Também verifico quais métricas acordadas pela equipe foram "quebradas", se houver, para ver se concordo com o desenvolvedor que estava OK ou se posso sugerir maneiras de melhorá-las. O fato de essas métricas de desenvolvimento terem sido acordadas em nossa equipe para a criação de um novo código fez com que grandes incursões na melhoria de nosso código. Escrevemos muito menos métodos monolíticos e somos muito melhores no princípio da responsabilidade única agora.

Tendências de melhorias no código herdado Temos muitos códigos herdados que gostaríamos de melhorar. As métricas a qualquer momento são bastante inúteis, mas o que é importante para nós é que, com o tempo, a cobertura do código aumenta e coisas como complexidade e acoplamento diminuem. Portanto, nossas métricas são conectadas ao servidor de Integração Contínua, permitindo que analisemos o tempo para garantir que estamos no caminho certo.

Conhecendo uma nova base de código A única vez em que utilizo linhas de métrica de código-fonte é ao olhar para uma base de código com a qual não estou familiarizado. Isso me permite avaliar rapidamente o tamanho aproximado do projeto em comparação com outros com os quais trabalhei. Usando outras métricas, também posso ter uma idéia mais aproximada da qualidade do projeto.

O principal é usar métricas como pontos de partida para tendências, discussões ou caminhos a seguir e não gerenciá-las religiosamente para números exatos. Mas acredito firmemente que eles podem ajudá-lo a melhorar o código correto quando usado corretamente.


0

P: Quais são as métricas úteis para capturar para o código-fonte?

Para negócios:

A: Número de horas-homem

Para o supervisor do programador:

A: Não importa. Vamos fazer tudo hoje

Para auto-estima do codificador:

A: Número de SLOC (linhas de código-fonte)

Para a mãe do codificador:

A: Coma mais desses pães franceses macios e beba chá

continuou nos comentários abaixo ...


Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.