Nas últimas semanas a Guilda de testes automatizados tem feito esforços para a implantação do SonarQube nas equipes de desenvolvimento.  Todos os desenvolvedores de Blumenau já devem ter ouvido falar desta ferramenta, mas, para quem ainda não sabe, aqui vai um resumo: o SonarQube é uma ferramenta de análise de código que monitora continuamente a qualidade do código fonte.

Por que monitorar continuamente a qualidade do código? O óbvio é para manter a qualidade dos nossos produtos. O não óbvio é a segurança da equipe em permitir que mais e mais pessoas colaborem com o código, o aprendizado (o Sonar nos torna programadores melhores) e um monte de outras coisas. Acredite, após utilizar você não vai mais querer ficar sem ele.

Digamos que alguém duplicou uma classe porque não quis refatorar o código existente. O Sonar irá alertar automaticamente o aumento no código duplicado e o responsável será notificado. Alguns diriam que um code review é suficiente… Não é! Pois é humanamente impossível detectar todo código duplicado numa base de código com centenas de milhares de linhas, detectar todos os blocos de ifs que nunca são executados, detectar todos os prováveis null pointers etc.

Ficou curioso? Nós já estamos com um servidor rodando o SonarQube na Benner em sonar.benner.com.br. Utilize seu usuário e senha de rede para entrar. Caso você tenha problemas com acesso, consulte o administrador mais próximo (lista abaixo).

Como funciona

Um pipeline do Jenkins baixa os últimos fontes de um sistema, executa o scanner do Sonar e envia os resultados para sonar.benner.com.br. Este pipeline pode executar várias vezes ao dia, em horários pré-determinados ou a cada alteração no código, a equipe escolhe o que for melhor.

O scanner do Sonar basicamente procura por dívida técnica, que na prática são erros de programação, práticas não recomendadas (code smells), falhas de segurança (como senhas hardcoded), código duplicado e também código não coberto por testes.

O Sonar vai mantendo o histórico da saúde do código e monta um dashboard (overview) do projeto com a saúde atual:

Esse dashboard é bastante interativo, por exemplo, você pode clicar no indicador de code smells e ver quais são os code smells.

Conserte o vazamento!

Quando chegamos em casa e encontramos uma poça d’água na cozinha que não para de aumentar, nós iremos procurar a fonte do vazamento e estancar. Tentar secar o chão antes de consertar o vazamento vai ser inútil.

O Sonar adota essa filosofia para manter o código saudável. Quando começamos a analisar nosso código, percebemos que temos uma grande dívida técnica e que ela não para de aumentar. Reservar tempo para resolver todos os problemas é igual secar o chão sem consertar o vazamento.

A ideia é que o aumento da dívida técnica (vazamento) em código novo seja nulo, ou no máximo muito pequeno. O Sonar considera código novo tudo o que foi feito nos últimos 30 dias. Podemos saber se há um vazamento grave quando o Quality gate do projeto estiver vermelho (Failed). Quando o Quality gate estiver verde (Passed), significa que os vazamentos estão controlados.

O Quality gate do projeto só vai estar verde se:

• Manutenibilidade nível A em código novo (zero code smells)
• Confiabilidade nível A em código novo (zero bugs)
• Segurança nível A em código novo (zero vulnerabilidades)
• Máximo de 3% de código duplicado em código novo
• Mínimo de 35% de código novo coberto por testes (vamos aumentar a meta gradativamente)

O status geral dos últimos 30 dias pode ser visto na coluna amarela do Overview do projeto: Leak period last 30 days.

Gerenciamento dos problemas (Issues)

Para cada problema detectado é criado um issue em sonar.benner.com.br e o programador responsável pelo pedaço de código com problema é notificado por email para que o mesmo seja resolvido.

Para consultar seus issues acesse sonar.benner.com.br com o seu usuário de rede, selecione o projeto e clique Issues/My Issues.

O Sonar não é uma ferramenta perfeita. Às vezes um issue precisa ser removido porque é um falso positivo (sim, às vezes ele erra!), porque a solução demandaria uma refatoração grande em código legado e o risco não compensa ou ele não entendeu direito o contexto (Resolve as won’t fix). Também tem a opção de transferir o issue para outra pessoa.

Apenas os administradores do projeto no Sonar tem o poder fechar os issues como Resolve as won’t fix ou Resolve as false-positive os outros devem resolvê-los no código.

Quem são os administradores do Sonar?

• @paulo.silva (Tecnologia)
• @rafael.leonhardt (Jurídico)
• @bernardo.bugmann (ERP)
• @bruno.viek (ERP)
• @jean.klann (RH)
• @fabiano.borges (RH)
• @jan.kirsten (SISCON)
• @otavio.fevereiro (Logística)
• @matheus.silva (Logística)
• @jean.fuck (Turismo)
• @willian.kupas (WMS)

É com essas pessoas que você deve entrar em contato caso não concorde com algum issue. Porém lembre-se, o Sonar é um excelente revisor de código. Todo issue possui uma explicação.

Antes de entrar em contato com o cara acima, leia a explicação, leia novamente e leia mais uma vez. Se mesmo assim você não concordar, fale com o responsável e prepare-se por que ele vai ler mais algumas vezes antes de marcar o issue como false-positive ou como won’t fix.

Mais uma coisa: Estes administradores não são fixos. Cada equipe é responsável por escolher quem tem permissão pra isso.

Importante: Se sua equipe ainda não está monitorando continuamente a qualidade do código ou se você está sem acesso ao Sonar, entre em contato com o administrador do seu time e com seu líder!