O Sonarqube não é seu inimigo.

Fala galera! Hoje eu decidi escrever sobre algo que para muitos devs acaba sendo um vilão por vários motivos. Quem nunca ouviu? “Esse Sonar não adianta nada”, “É só gastar tempo atoa”, “Isso não muda em nada a qualidade do meu código”, “Não preciso testar, meu código é muito bom”, “O prazo está apertado demais para usar o Sonar”, “Podíamos está fazendo uma nova feature”…

Existem vários motivos e que de fato são válidos para você que muitas vezes cria um código de difícil manutenção.

• O prazo muito apertado
• Gastar tempo com testes é perda de tempo, que eu podia está fazendo uma nova feature
• Gastar tempo com o débito técnico é perder tempo que eu podia está gastando com uma nova feature

Durante a minhas experiências como dev eu já escrevi muita coisa que eu não fazia ideia de que podia facilitar minha vida e a dos outros devs que também iam manter o código que eu escrevia.

Só quando você entende que de fato tem ganho em escrever um bom código, você de fato da uma chance para o Sonarqube ser um dos seus melhores aliados e não inimigo. Mas o que mais acontece é isso ser “empurrado” para os devs, sem que eles entendam de fato o ganho que se tem no uso do Sonar, muitas vezes tem a obrigação de fazer de qualquer jeito só para atender as regras do Sonar e pronto, sobe que tá “legal”.

Vamos lá, entendo que vários projetos tem prazos apertados e muitas vezes usamos isso como “desculpa” para criar um código e não verificar as críticas de análise estática do Sonar e deixar cada vez mais o projeto com débitos técnicos, mal escrito e até você mesmo quando for manter depois, terá dificuldades!

Falo isso com muita propriedade, pois mesmo trabalhando em lugares com um percentual mínimo de testes, avaliação estática do código eu era um cara que fazendo meus próprios projetos, não escrevia testes e não olhava para o Sonar por causa do “prazo”. No meu caso em específico, porque eu queria ver o produto pronto e testá-lo rapidamente(o que não deixa de ser um bom motivo, mas a pergunta é, isso vale a pena?).

Criei uma API para um aplicativo de controle de chamadas da escola da minha igreja. Escrevi o código da API + o código do aplicativo em um mês, testei e consegui alcançar o meu objetivo… porém, passou um bom tempo depois e eu resolvi mexer nessa API novamente e adivinha, odiei ter que manter o código que eu mesmo escrevi, pois demorava muito para entender alguma classe específica e já havia feito muito tempo que eu nem tocava naquele código. Estava colhendo aquilo que plantei lá atrás. Decidi mudar a minha mentalidade e seria muito mais fácil que eu aplicar isso para outras coisas novas que eu fosse criar, do que aplicar na minha própria API que já estava construída, mas como eu disse, mudei completamente a minha mentalidade sobre a qualidade do meu código e usei o Sonar como um dos meus maiores aliados nessa mudança.

Veja como era o código da minha API:

Além de ter muitos code smalls, não tinha sequer uma classe de teste e o que é pior ainda, olha essas imagens:

A complexidade cognitiva e ciclomática dos meus códigos não estavam muito legais, esse era o real motivo de fato que fizeram eu odiar manter o código que eu mesmo escrevi.

Decidi mudar isso e fazer o meu código baseado no clean code(mas isso é um assunto longo para falar disso agora) e o Sonar foi um grande Aliado!

Vamos lá, primeiro eu decidi refatorar as minhas classes que estavam com uma complexidade alta demais, com isso fui separando as responsabilidades e deixando cada classe com apenas uma responsabilidade em específico. Diminuindo a complexidade deles, comecei a escrever todos os testes para as minhas classes e isso também foi um ótimo indicador, pois se eu demorava demais para escrever o código de alguma classe em específico, eu entendia que aquela classe ainda precisava ser refatorada e ter menos resposabilidade.

Com tudo isso o código da minha API ficou assim:

Repare que o código além de ter uma boa cobertura, está sem débitos técnicos, code smalls e etc…

Agora olha só a complexidade do “novo” código:

O que isso tudo tem de vantagem?

• Quando eu quiser criar uma nova feature mesmo que eu fique anos sem mexer no código, vai ser muito mais simples criar essa nova feature.
• Corrigir um bug não será tão doloroso
• Na sua carreira, 70% de tudo que você vai fazer é manter código e não escrever código novo, se você não fizer disso algo prazeroso vai acabar tornando-se um dev cansado do trabalho.
• O seu cérebro vai se adaptar(acredite, vai mesmo) a criar códigos com maior qualidade.

Enfim pessoal, o Sonar é uma ferramenta muito boa que pode lhe ajudar a ser um programador muito melhor, faça dele um dos seus aliados e não seu inimigo. Espero ter ajudado alguém.