Métricas objetivas para a qualidade do software [fechado]

Existem vários tipos de qualidade que podem ser medidos em produtos de software, por exemplo, adequação à finalidade (por exemplo, uso final), manutenção, eficiência. Alguns deles são subjetivos ou específicos do domínio (por exemplo, bons princípios de design da GUI podem ser diferentes entre culturas ou dependentes do contexto de uso, pense em uso militar versus uso do consumidor).

O que me interessa é uma forma mais profunda de qualidade relacionada à rede (ou gráfico) de tipos e sua inter-relação, ou seja, a quais tipos cada tipo se refere, existem grupos claramente identificáveis ​​de interconectividade relacionados a uma rede adequadamente arquitetura hierárquica ou, inversamente, existe uma grande 'bola' de referências de tipo (código 'monolítico'). Além disso, o tamanho de cada tipo e / ou método (por exemplo, medido em quantidade de código de bytes Java ou .Net IL) deve fornecer algumas indicações de onde grandes algoritmos complexos foram implementados como blocos monolíticos de código, em vez de serem decompostos em mais gerenciáveis ​​/ sustentáveis pedaços.

Uma análise baseada nessas idéias pode ser capaz de calcular métricas que são pelo menos um proxy de qualidade. Os pontos exatos de limiar / decisão entre alta e baixa qualidade eu suspeito que sejam subjetivos, por exemplo, como manutenibilidade queremos dizer manutenibilidade por programadores humanos e, portanto, a decomposição funcional deve ser compatível com o funcionamento da mente humana. Como tal, pergunto-me se pode haver uma definição matematicamente pura da qualidade do software que transcenda todo o software possível em todos os cenários possíveis.

Também me pergunto se isso é uma ideia perigosa, que se proxies objetivos de qualidade se tornarem populares, as pressões dos negócios farão com que os desenvolvedores busquem essas métricas em detrimento da qualidade geral (aqueles aspectos de qualidade não medidos pelos proxies).

Outra maneira de pensar sobre a qualidade é do ponto de vista da entropia. Entropia é a tendência dos sistemas de reverter de estados ordenados para estados desordenados. Qualquer um que já tenha trabalhado no mundo real, em um projeto de software de médio a grande escala, apreciará o grau em que a qualidade da base de código tende a se degradar com o tempo. As pressões dos negócios geralmente resultam em mudanças que se concentram em novas funcionalidades (exceto onde a qualidade em si é o principal ponto de venda, por exemplo, em software aviônico), e na deterioração da qualidade por meio de problemas de regressão e da funcionalidade 'calçar sapatos', onde ela não se encaixa bem. uma perspectiva de qualidade e manutenção. Então, podemos medir a entropia do software? E se sim, como?

Essa é uma ideia perigosa. Proxies "objetivos" de qualidade levam diretamente a recompensas de gerenciamento e os desenvolvedores perseguem essas métricas à custa da qualidade real.

Esta é a lei das consequências não intencionais.

Qualidade - embora importante - é apenas um pequeno aspecto do software. A funcionalidade e o valor criados pelo software são muito, muito mais importantes que a qualidade.

Todas as métricas levam à atividade para otimizar a métrica. Isso, por sua vez, tem consequências que você pode não gostar.

Software é muito complexo. É difícil entender como é realmente complexo.

Mesmo coisas "óbvias" como a cobertura do código do teste de unidade podem perder tempo. Chegar a 100% pode exigir a criação de testes realmente mais complexos que o código trivial que está sendo testado. Obter 100% de cobertura pode envolver um custo inaceitável. [A alternativa para código trivial, pequeno e raramente usado é teste por inspeção. Mas isso não se encaixa no jogo de métricas de 100%.]

Outro exemplo é a complexidade ciclomática. É uma das melhores medidas de qualidade de código. Mas pode ser criado criando muitas funções pequenas que podem ser mais difíceis de ler (e mais difíceis de manter) do que uma função maior. Você termina nas revisões de código em que concorda que pode não ser muito legível, mas atende ao limite de complexidade.

Também me pergunto se isso é uma ideia perigosa, que se proxies objetivos de qualidade se tornarem populares, as pressões dos negócios farão com que os desenvolvedores busquem essas métricas em detrimento da qualidade geral (aqueles aspectos de qualidade não medidos pelos proxies).

Bingo, e não "se" sobre isso. Isso é chamado de "Disfunção de Medição" e foi observado e escrito muitas vezes Joel escreveu um artigo sobre ele em 2002, referindo um livro de um professor de Harvard.

Isso não significa que essas métricas sejam inúteis, apenas que nunca se deve basear incentivos ou políticas explicitamente nessas medições de proxy. Se você deseja melhorar a qualidade, uma métrica de proxy com um valor muito ruim é provavelmente um bom ponto de partida. Mas você não pode concluir que a qualidade é boa apenas porque todas as suas métricas têm grandes valores.

O que me interessa é uma forma mais profunda de qualidade relacionada à rede (ou gráfico) de tipos e sua inter-relação, ou seja, a quais tipos cada tipo se refere, existem grupos claramente identificáveis ​​de interconectividade relacionados a uma rede adequadamente arquitetura hierárquica ou, inversamente, existe uma grande 'bola' de referências de tipo (código 'monolítico').

Parece fan-in e fan-out. Fan-in conta o número de módulos que chamam um determinado módulo e fan-out conta o número de módulos chamados por um determinado módulo. Um sinal de aviso a ser usado seria o módulo que possui uma grande entrada e saída de ventiladores, pois isso pode indicar um design inadequado e um alvo importante para refatoração ou reprojeto.

Além disso, o tamanho de cada tipo e / ou método (por exemplo, medido em quantidade de código de bytes Java ou .Net IL) deve fornecer algumas indicações de onde grandes algoritmos complexos foram implementados como blocos monolíticos de código, em vez de serem decompostos em mais gerenciáveis ​​/ sustentáveis pedaços.

Uma medida simples seria linhas de código. Você pode decompô-lo em linhas totais de código em todo o projeto e em linhas de código por módulo (talvez usando módulos de tamanhos diferentes). Você pode usar isso como um indicador de aviso, indicando que você deve revisar módulos específicos. Um livro sobre medições e métricas de qualidade de software discute alguns trabalhos que indicam que a relação entre taxas de defeitos e tamanho do módulo é curvilínea, onde o defeito médio por KSLOC vem com módulos com um tamanho entre 175 e 350 SLOC.

Algo um pouco mais complexo seria a complexidade ciclomática, projetada para indicar a testabilidade, a compreensibilidade e a manutenção de um sistema. A complexidade ciclomática conta o número de caminhos independentes através de um aplicativo ou módulo. O número de testes e, portanto, o esforço necessário para produzir e executar os testes, está fortemente relacionado à complexidade ciclomática.

Os pontos exatos de limiar / decisão entre alta e baixa qualidade eu suspeito que sejam subjetivos, por exemplo, como manutenibilidade queremos dizer manutenibilidade por programadores humanos e, portanto, a decomposição funcional deve ser compatível com o funcionamento da mente humana.

Não tenho certeza de que é esse o caso.

Por exemplo, houve pesquisas que sugerem que a memória de trabalho de um ser humano pode conter apenas 7 objetos mais / menos 2 . Provavelmente, isso é interessante para medir a entrada e saída de fãs - se eu estiver trabalhando em um módulo e estiver conectado a mais de 7 outros módulos, provavelmente não conseguirá acompanhar exatamente o que esses outros módulos estão na minha cabeça.

Também houve trabalho sobre a relação de defeitos com métricas, como complexidade ciclomática. Como você deseja minimizar defeitos em seu sistema, é possível identificar pontos que precisam de mais testes ou refatoração, conforme identificado pela alta complexidade ciclomática.

Também me pergunto se isso é uma ideia perigosa, que se proxies objetivos de qualidade se tornarem populares, as pressões dos negócios farão com que os desenvolvedores busquem essas métricas em detrimento da qualidade geral (aqueles aspectos de qualidade não medidos pelos proxies).

É o caso de quaisquer medidas ou métricas. Eles precisam ser usados ​​para entender o sistema e tomar decisões informadas. A frase "você não pode gerenciar o que não pode medir" vem à mente. Se você deseja um software de alta qualidade, precisa de algumas medidas e métricas para avaliar essa qualidade. No entanto, há um outro lado disso. Você não pode gerenciar exclusivamente pelos números. Você pode usar os números para tomar decisões informadas, mas não pode tomar uma decisão apenas porque os números dizem isso.

Existem métricas ou proxies para muitas das qualidades das quais você está interessado:

1. Linhas de código
2. Fan in, fan out
3. Taxa de erro por 1000 linhas de código
4. Complexidade ciclomática
5. Cobertura de código
6. Cobertura do ponto de decisão
7. Proporção de erros corrigidos / introduzidos pelas atividades de manutenção
8. Análise de ponto de função

Existem alguns problemas com todos esses itens:

1. Trabalho sendo realizado para otimizar a métrica - uma tendência universal; exacerbado maciçamente se alguma das métricas for usada como base para avaliação ou recompensa para equipes ou indivíduos.
2. Não conheço nenhuma métrica livre de contexto. Isso implica que nenhuma comparação é possível entre lojas - apenas dentro das lojas, ao longo do tempo. As métricas resultantes dessas comparações ainda são valiosas - "estamos produzindo código mais corretamente agora do que um ano atrás".

O efeito total dessas questões é que métricas como essas provavelmente só serão valiosas em uma cultura mais ampla - como TQM, garantia de qualidade (não controle), melhoria contínua, kaizan etc. É necessário definir elementos da cultura. e como ele precisa mudar. Se você defini-las, métricas como essas se tornam ferramentas essenciais para ajudar a melhorar a qualidade do código, práticas de trabalho, produtividade etc. Sem esse contexto mais amplo, as métricas gerarão trabalho para otimizar a métrica; se tornará a ferramenta do contador de grãos para aumentar a produtividade e diminuir os custos; e se tornará um obstáculo a ser jogado pela equipe de desenvolvimento.

Você pode estar obcecado com métricas ou com as melhores pessoas, ferramentas, práticas de engenharia e controle de qualidade que você pode pagar. Eu ficaria muito mais feliz com vários gênios de controle de qualidade paranóicos que leram 'Fooled by Randomness' e que gostam de automatizar do que um monte de relatórios bem formatados com números.

Há esse problema fundamental com as métricas.

Praticamente todas as métricas propostas foram mostradas, no mundo real, em código real, fortemente ou muito fortemente correlacionadas com o SLOC bruto (linhas de código-fonte).

Foi isso que matou as métricas de Halstead, na década de 1970. (Por acidente, um dia, por volta de 1978, participei de uma palestra de um novo PhD sobre as métricas de Halstead, na qual ele apontou isso.)

Mais recentemente, a complexidade ciclomática de McCabe demonstrou estar fortemente correlacionada com o SLOC bruto, a tal ponto que o cara que fez o estudo se perguntou em voz alta se a métrica de McCabe nos dizia algo útil.

Sabemos há décadas que grandes programas eram mais propensos a ter problemas do que os pequenos. Sabemos há décadas que grandes sub-rotinas eram mais propensas a ter bugs do que pequenas. Por que precisamos de métricas misteriosas para nos dizer isso, quando olhar para quatro páginas de impressoras espalhadas sobre uma mesa deve ser suficientemente convincente?

Dadas todas as outras respostas aqui, me sinto meio boba com essa pequena. Dê uma olhada no Crap4j , que tenta classificar os métodos em java pelo quanto eles fedem. (O projeto parece abandonado.)

Ele usa uma combinação de complexidade ciclomática e cobertura de teste. Como qualquer outra métrica, é possível jogar.