metrics lg

Motivação

Buscar algo simples, rápido e automatizado que mostre possíveis pontos de melhoria no código.

Não entrei a fundo em todas as ferramentas, era mais um spike para ver o que as ferramentas oferecem com as configurações padrões, e qual delas é mais interessante dedicar mais tempo.

O que foi feito

Peguei como base esse código de dojo do Daniel e segui alguns artigos de como obter métricas usando Gradle. O resultado está nesse fork, no branch metrics. Foco especial no build.gradle.

Como rodar o projeto

Requisitos:

# Baixar o projeto
git clone https://github.com/adamatti/badCodeDojoJavaProblems.git
cd badCodeDojoJavaProblems

# Mudar para o branch metrics
git checkout metrics

# Iniciar o sonar (opcional)
docker-compose -f docker-compose.yml up -d

# Rodar as verificações
gradle check jacocoTestReport sonar

Os relatórios html estarão disponíveis na pasta build/reports, ou no Sonar (http://localhost:9000, default admin/admin).

Você pode entrar no marketplace do sonar (http://localhost:9000/admin/marketplace) e instalar plugins adicionais (recomendados: CheckStyle, FindBugs, Groovy - para o codenarc, PMD)

Considerações sobre as ferramentas

  • CheckStyle / PMD: Regras e relatórios precisam ser configurados. Não vejo valor em quebrar um build se

    • Faltar um javadoc

    • Arquivo contem tab

    • Arquivo package-info.java ausente

    • Arquivo não termina com nova linha

É, não curto muito lint, não acho que isso agrega valor. Achei poucas regras interessantes, dentre elas linha muito longa e magic numbers.

  • CodeNarc: só consegui fazer funcionar a validação em arquivos groovy. Necessita de mais tempo para uma configuração melhor.

  • CheckStyle / SpotBugs: acharam apenas 7 warnings, nenhum significativo

  • Jacoco: Relatório muito completo e detalhado, mostrando cobertura por linha, métodos, classes…​ Ainda que o exemplo usado não tenha testes.

  • Sonar: é uma baita ferramenta! Dentre os pontos fortes:

    • muita informação e de forma organizada

    • bugs priorizados

    • fácil navegação entre o código e os bugs / warnings / code smells

    • comparação entre analises

    • Mostra uma das métricas mais importantes(IMO): cognitive complexity

Ferramentas usadas:

  • Jacoco: cobertura de testes

  • CheckStyle: estão disponíveis as configurações do google e antiga Sun. Tive problemas com a primeira (não investi tempo suficiente para entender / resolver), acabei usando a segunda

  • PMD

  • FindBugs

  • SpotBugs: é uma continuação do [FindBugs], produziu os mesmos resultados. Mesmo assim, os dois estão habilitados no projeto (FindBugs e SpotBugs)

  • CodeNarc

  • Sonar: para publicação dos resultados

Ferramentas não usadas nesse momento

Ferramentas pagas não avaliadas

.mas disponíveis aqui se alguem quiser tentar:

Próximos passos

  • Avaliar outras ferramentas

  • Configurar melhor as ferramentas usadas

  • Procurar ferramentas similares para Javascript

  • Evoluir o metrics-tracker

Concluindo…​

Métricas automatizadas são "interessantes", e podem apontar partes de código mais complexas, apontar onde possívelmente tenha mais problemas. Mas não vão resolver problemas de design, qualidade, entrega de valor. Dito isso, eu focaria:

  • Ver opções de formatação automática, tipo editor config (ou mesmo configurações de IDE)

  • Sessões de design / arquitetura / planejamento

  • Melhores code reviews

  • Convenções do time (ex: usar ou não lint? Anotações?)

  • Estudos de clean code, DDD, organização de código / classes

  • Testes funcionais: para garantir que as funcionalidades estão ok. Parece obvio, mas vejo muita gente focando só em teste unitário, considerando a "unidade" métodos.

  • Estudo de TDD. Só esse ponto já dá outro post. Acredito muito nessa visão #goFastForever, fazer certo da primeira vez. Esse gráfico do Martin Fowler também diz isso.

E você leitor? Alguma verificação automatizada? Recomenda alguma métrica para focar? Como garantir qualidade de código para todos os níveis? Agradeço qualquer feedback.