Como você sabe se o software é bom ou ruim com base em métricas empíricas?

No momento, estou sendo solicitado a analisar um projeto que concluiu o desenvolvimento principal há cinco meses, mas ainda apresenta um alto nível de defeitos. O que acontece a cada 10 defeitos corrigidos, aumentamos pelo menos 4 e, em alguns casos, 8 defeitos.

Acredito que a prática de codificação no fornecedor é ruim e há um consenso geral sobre isso. No entanto, eu estou querendo saber se há um problema estrutural com o software? A densidade de defeitos é uma medida útil, mas mais se o software principal estiver mal escrito, tudo o que o fornecedor está fazendo é mudar o problema.

Na infraestrutura, é mais definido se algo for mal construído, que medidas você pode usar para o software, além dos defeitos por LOC?

O produto está em fase de correção de defeitos há 4 meses e ainda não solucionou defeitos críticos suficientes. Não estamos injetando novas funcionalidades, apenas corrigindo problemas de regressão.

Isso indica um problema de qualidade de desenvolvimento, que não está satisfeito. No entanto, se o produto em si é fundamentalmente defeituoso, esse é um problema diferente. A preocupação é que a base de código principal foi mal escrita e tem documentação limitada, todos os desenvolvedores externos estão mudando o problema de A para B. Depois que as equipes de desenvolvimento interno assumem o controle, estou preocupado que eles terão que reescrever fundamentalmente o código para deixe-o funcional.

Portanto, quando você aceita um produto de terceiros e é solicitado a apoiá-lo, que critérios de aceitação você usaria para definir padrões?

Além de levar nosso desenvolvedor líder a fazer uma revisão por pares de código por versão, não sabe o que mais pode ser feito?

Você não

A qualidade do software é realmente difícil de medir objetivamente. Difícil o suficiente para que não haja uma solução. Eu estou me abstendo nesta resposta de me perguntar se pode haver uma solução, mas simplesmente aponto por que definir uma seria realmente difícil.

Raciocínio por status quo

Como Kilian Foth apontou, se houvesse uma medida simples para um software "bom", todos nós o estaríamos usando e todos exigiriam.

Existem projetos nos quais os gerentes decidiram aplicar determinadas métricas. Às vezes funcionava, às vezes não. Não tenho conhecimento de nenhuma correlação significativa. O software de sistemas especialmente crítico (pense em aviões, carros etc.) possui muitos requisitos de métricas para "garantir" a qualidade do SW - não tenho conhecimento de nenhum estudo que mostre que esses requisitos realmente resultem em maior qualidade e tenho experiências pessoais com o contrário.

Raciocínio por contra-inteligência

Também sugerido por Kilian, e mais geralmente expresso como "todas as métricas podem e serão reproduzidas".

O que significa reproduzir uma métrica? É um jogo divertido para desenvolvedores: você garante que os valores das métricas pareçam realmente bons, enquanto faz coisas realmente de merda.

Digamos que você mede defeitos por LOC. Como eu vou tocar isso? Fácil - basta adicionar mais código! Crie um código estúpido que resulte em uma não operação de mais de 100 linhas e, de repente, você terá menos defeitos por LOC. O melhor de tudo: você realmente diminuiu a qualidade do software dessa maneira.

As falhas da ferramenta são abusadas, as definições são esticadas ao máximo, formas completamente novas são inventadas .. basicamente, os desenvolvedores são pessoas realmente inteligentes e você deve ter apenas um desenvolvedor em sua equipe que se diverte jogando métricas, então suas métricas serão questionáveis.

Isso não quer dizer que as métricas sejam sempre ruins - mas a atitude da equipe em relação a essas métricas é crucial. Em particular, isso implica que não funcionará bem em nenhum relacionamento de subcontratado / fornecedor terceirizado.

Raciocínio por segmentação incorreta

O que você deseja medir é a qualidade do software. O que você mede é uma ou mais métricas.

Há uma lacuna entre o que você mede e o que você acredita que isso lhe dirá. Essa diferença é meio que enorme.

Isso acontece o tempo todo em todos os tipos de empresas ao nosso redor. Você já viu decisões baseadas em KPIs (principais indicadores de desempenho)? É exatamente o mesmo problema - você quer que uma empresa se dê bem, mas mede outra coisa.

Raciocínio por quantificabilidade

Métricas podem ser medidas. Qual é a única razão pela qual lidamos com eles. A qualidade do software, no entanto, estende-se muito além dessas entidades mensuráveis ​​e é muito difícil quantificá-la: Qual é a legibilidade do código-fonte? Quão extensível é o seu design? Quão difícil é a integração de novos membros da equipe? etc etc.

Julgar a qualidade do software apenas por métricas e fechar os olhos para as partes da qualidade que você não pode quantificar certamente não vai funcionar bem.

editar:

Sumário

Deixe-me salientar que o exposto acima é sobre objetivamente julgar se o software é bom ou ruim com base em métricas. Isso significa que não está dizendo nada sobre se e quando você deve aplicar métricas.

De fato, essa é uma implicação unidirecional: métricas ruins implicam código incorreto. Unidirecional significa que um código incorreto não garante métricas ruins, nem boas métricas garantem um código bom. Por outro lado, isso por si só significa que você pode aplicar métricas para julgar um software - quando você mantiver essa implicação em mente.

Você mede o software A e as métricas ficam muito ruins. Então você pode ter certeza de que a qualidade do código é ruim. Se você mede o software B e as métricas estão corretas, não tem idéia da qualidade do código. Não se iluda pensando em "métricas boas = código bom" quando realmente é apenas "código bom => métricas boas".

Em essência, você pode usar métricas para encontrar problemas de qualidade, mas não a própria qualidade.

Sim, você pode dizer que o código tem problemas de qualidade observando as métricas até certo ponto.

Mais especificamente, execute uma ferramenta de análise de complexidade na base de código e você terá uma idéia de se o código é bom ou ruim.

Por exemplo, você pode executar o monitor de origem .

O que isso lhe dirá é a complexidade do código. Posso dizer que todos os sistemas problemáticos que experimentei tiveram números ruins. Complexidade em 10s a 100s de métodos bem acima dos limites aceitáveis. Números terríveis. Terrível complexidade, aninhamento, profundidade, etc. Isso levará a muitos problemas, taxa de defeitos alta e constante, alterações difíceis de executar, sem quebrar outra coisa, etc.

Outra coisa são os defeitos. Com o tempo, o sistema deve se estabilizar. Idealmente, os novos defeitos devem tender para zero ou achatar para um número baixo, o que significa que os defeitos novos e atuais devem diminuir com o tempo.

O enredo deve ser algo como isto:

Defeitos ao longo do tempo

Se eles permanecerem constantes ou aumentarem, o software não será bom. Você tem apenas 4 meses, então eu daria mais alguns meses a um ano. Após 6 meses a um ano, se você tiver um fluxo constante de defeitos, será de má qualidade. Sua equipe desenvolveu outra bola de barro .

Próximos testes. Você os tem? Se não houver menos qualidade, mais erros, mais rotatividade. Se você os possui, métricas como cobertura de código são boas para ter uma idéia de quanto código está sendo coberto, mas não mede a qualidade . Eu já vi grandes números de cobertura de código, mas os testes reais eram uma porcaria. Eles não estavam testando nenhum comportamento ou funcionalidade do sistema. Os desenvolvedores estavam apenas escrevendo-os para melhorar os números das métricas de gerenciamento. Então você precisa fazer testes e eles precisam ser bons. As métricas de cobertura de código por si só não são um indicador de qualidade.

Revisões de código, você as está realizando? Caso contrário, menos qualidade. Isso é especialmente importante para desenvolvedores juniores. Se você está agilizando, basta adicionar uma tarefa de revisão de código à sua história chamada "revisão de código". Se a gerência quiser rastrear números, você precisará de uma ferramenta que rastreie avaliações como o Crisol . Acho que os números ou métricas de revisão de código não são tão importantes aqui, além do fato de que eles devem fazer parte do seu processo. Nem todo check-in precisa de uma revisão. Porém, as revisões podem ajudar a garantir que as pessoas não reinventem a roda ou escrevam códigos que outras pessoas não possam entender e / ou manter.

Por fim, você terá que avaliar o código, nenhuma métrica ajudará em nada. Todo projeto de código problemático tinha essas qualidades:

• Estruturas de dados ruins. Tudo é uma string ou o XML é passado em todos os lugares e analisado em todos os lugares, objetos-deus ou estruturas de dados genéricas ou desnecessariamente complexas, sem modelo de domínio.
• Na falta de organização ou estrutura, qualquer projeto não trivial deve ter alguma divisão ou estratificação que separa a lógica. Dê uma olhada aqui ... Se você não vê esse tipo de organização ou separação (mistura de lógica em todos os lugares), o sistema será mais difícil de manter e entender.
• Sobre abstrações. Às vezes o inverso é verdadeiro, o sistema é abstraído. Se tudo for uma interface e uma classe abstrata, ou você precisar navegar por várias classes do tipo "wrapper", a qualidade será ruim porque os novos desenvolvedores não poderão navegar pelo inchaço do objeto.
• Código difícil de entender. Se você é um desenvolvedor experiente e está procurando um código tão difícil de entender, ele terá problemas de qualidade. Minha métrica pessoal é que, se eu estou olhando para o código e é difícil seguir ou me faz sentir burra, ou sinto que estou desperdiçando muitos ciclos cerebrais para descobrir a lógica, então é um código ruim. Se os desenvolvedores experientes tiverem dificuldades para acompanhar, imagine como será para os desenvolvedores mais novos. Eles vão apresentar problemas.

Meu conselho seria executar uma análise de complexidade no código. Não compartilhe os resultados; em vez disso, faça uma investigação independente (consulte o código) e faça uma determinação da integridade geral da base de código. A partir disso, forme um plano de ação e tente corrigir algumas das áreas complexas do código.

O triste com as métricas é que você pode acabar melhorando os valores resultantes de suas métricas, mas não a qualidade pretendida a ser medida por elas ...

No Visual Studio, há uma configuração para tratar avisos do compilador como erros. Agora, algumas pessoas não entendem os avisos e, para obter o código compilado, usarão truques simples (como 'aviso de desativação de programa' ou adição de uma palavra-chave 'nova' a uma função / propriedade que oculta um membro não virtual de uma base classe).

Se você tiver acesso ao código-fonte, poderá executar a análise de código estático. Para projetos .Net, você pode usar, por exemplo, FxCop ou ReSharper InspectCode. Quando usadas corretamente pela equipe de desenvolvimento, as ferramentas ajudarão a melhorar a qualidade. Mas é claro que são possíveis algumas "correções" para remover avisos sem entendê-los.

Você pode olhar para testes automatizados / UnitTests: qual é a cobertura do código? Mas a cobertura por si só não informa se os testes realmente verificam o código, ou apenas o executaram uma vez.

Buscar alta qualidade é uma atitude, que pode ser suportada por muitas ferramentas e suas métricas, mas métricas sem a atitude dos desenvolvedores não ajudam.

Uma coisa que você deve considerar, além de coletar uma métrica como a injeção de defeitos, é descobrir a origem dos defeitos. Muitas vezes, isso está relacionado à especificação.

Basicamente, existe um erro na especificação, uma ambiguidade na especificação, deixada para os implantes decidirem ou é um bug na implementação.

Uma abordagem mais qualitativa é perguntar se o software é útil? Se você se esforçar o suficiente, poderá encontrar defeitos em qualquer software. No entanto, se funcionar bem o suficiente para ganhar dinheiro, pode não ser tão ruim.

No fundo, não há como saber.

Para a pergunta original (antes da resposta filosófica): O que o produto deve fazer e o faz? Medir pela contagem / densidade de defeitos não é suficiente. Eu não sabia dizer se isso era uma biblioteca ou um aplicativo, qual o tamanho da base de código, qual o tamanho do domínio do problema e qual a gravidade dos defeitos. Por exemplo, não lidar com um dos 123 formatos de entrada pode ser um defeito trivial ou uma interrupção de exibição, dependendo da importância do formato não ser tratado adequadamente. E melhor do que nada é um alto padrão.

Suposição que faço para esta pergunta: Há uma diferença entre Código e Software. Defino software como o que um cliente / usuário usa para resolver um problema, enquanto o código é o material de construção do software.

O software pode ser medido apenas subjetivamente. Ou seja, a métrica que importa para o software é se as pessoas a usam para resolver um problema. Essa métrica depende do comportamento do outro, portanto, é subjetivo. Nota: Para alguns problemas, um software pode ser bastante útil e, portanto, considerado de alta qualidade (Excel para cálculos), mas não um software de qualidade para um problema diferente (Excel para reproduzir arquivos MP3).

O código pode (geralmente) ser medido com métricas empíricas . Mas a interpretação não é 'sim / não' para qualidade, ou mesmo realmente em uma escala de '0 a N'. Métricas são comparadas com um padrão. Portanto, as métricas podem encontrar áreas de preocupação definidas pelo padrão, mas a ausência de áreas de preocupação não prova que esse é um código de qualidade. Por exemplo, métricas úteis: Compila? Não -> Não é de qualidade. Sim -> ???. Passa no teste de unidade? Não? Talvez? (porque, o código de qualidade do teste de unidade é?), Sim -> ???.

Assim, como a Prova de Incompletude de Godel mostrou para axiomas da matemática (ou seja, existem declarações matemáticas que não podem ser provadas verdadeiras ou falsas para qualquer conjunto finito de axiomas), acho que nunca poderíamos realmente responder 'é essa qualidade código?' para cada pedaço de código. Intuitivamente, provavelmente existe um mapeamento entre métricas de software para responder a qualidade e axiomas matemáticos para responder comprovadamente verdadeiro ou falso.

Outra maneira de argumentar é entrar na linguagem natural. William Shakespeare, Lewis Carroll e Mark Twain foram todos escritores de sucesso e amados por muitos pela qualidade de seus escritos. No entanto, que padrão de gramática, vocabulário, estilo ou voz poderíamos aplicar que os classificaria consistentemente mais do que os alunos do 12º ano? E, embora seja possível criar alguma medida sintética para esses três, como classificaria o Livro de João (KJV), JRR Tolkien, Homer, Cervantes, etc.? Em seguida, jogue Burroughs, Faulkner, Hemingway, Sylvia Plath e assim por diante. A métrica não funcionará.

Eu mediria isso auditando (e procurando desvios) no processo deles.

Eu procuraria evidências de um processo para entregar o controle de origem central envolvido, o sistema central de compilação e um processo que garantisse que o código fosse testado antes da integração na ramificação liberada.

Eu também procuraria evidências de como eles modificaram seus processos em resposta a situações em que os defeitos passaram pelo processo de liberação.

Se eles não conseguirem passar nesse nível de auditoria, não será possível esperar que eles entreguem versões confiáveis ​​consistentes.

Se eles passarem nessa auditoria e melhorarem continuamente seu processo, é provável que sua consistência na produção melhore ao longo do tempo.

Se isso não for corrigido, é provável que eles tenham um problema de arquitetura de código que torne problemático a extensão e o teste de sua base de código atual; nesse caso, não há boas opções.

Se você está procurando medições totalmente automatizadas, recomendo os seguintes: Grupo de aprimoramento de software

É essencialmente um agregado de várias métricas que podem ser extraídas automaticamente do código-fonte (como cobertura de teste de unidade, tamanho da função, emaranhamento de classe, duplicação, LOC etc.). Esses valores são então convertidos em uma classificação de 1 a 5 estrelas.

Eles também têm um livro decente descrevendo todas as suas métricas na prática que valem uma leitura: 'Criando software de manutenção' .