Identificando Code Smells em um projeto colaborativo com Sonarqube e Sonarlint
Quando programamos em um projeto onde o desenvolvimento do código é compartilhado entre uma equipe com vários desenvolvedores, gera-se uma preocupação em cima da questão de qualidade, arquitetura e padrões. Surgem questionamentos sobre como iremos padronizar e disseminar esse padrão de desenvolvimento entre os membros do time e novos membros que podem entrar e sobre como podemos evitar gerar códigos sem padrão e de baixa qualidade — que, ao nascer, já vêm com uma refatoração marcada para ele — os vulgos code smells.
Inicialmente, precisamos saber o que o time define ser code smells, pois existem vários padrões aceitos dentro das comunidade entre todas as linguagens. Entretanto, quem define o que fica dentro do padrão daquele projeto deve ser o próprio time de desenvolvimento do mesmo — ou a decisão poderia ser tomada entre todos os desenvolvedores da empresa, como no nosso caso. A Trinca faz uso das metodologias de Squads, Tribes, Chapters e Guilds. Possuímos dois Chapters de desenvolvimento, um para desenvolvimento Back-end e outro para desenvolvimento Front-end, e, dentro de cada um desses Chapters, nós discutimos o que consideramos como code smells em cada ponta do desenvolvimento, e essa definição é aplicada em todos os projetos desenvolvidos dentro da empresa.
Mas como e onde agrupar essas definições de code smells?
Para isso, precisaríamos de uma ferramenta que centralizasse definições de code smells e possíveis bugs no código, passasse um feedback sobre a qualidade do mesmo, integrasse com plataformas de devops e fosse integrado e indiferente de linguagem de programação. É aí que entra o SonarQube (https://www.sonarqube.org/), uma plataforma para inspeção contínua da qualidade do código que realiza revisões automáticas em múltiplas linguagens de programação.
O SonarQube é perfeito para a integração de CI (Continuous Integration) pois existem vários plugins em diversas linguagens para esteiras de build para inspeção e verificação de qualidade em um código. Por exemplo, dentro do SonarQube há um sistemas de notas para o código de um projeto, se baseando nas definições de code smells do mesmo. Então digamos que eu estou subindo um novo trecho de código em um projeto cuja a esteira possui o plugin ligado a um SonarQube. Ele irá analisar o código novo e verificar se estou subindo algum código de baixa qualidade de acordo com as definições dele. Se sim, ele pode bloquear as minhas modificações de subir no projeto.
Mas ele não precisa ser usado apenas como isso. Inicialmente, nos Chapters de desenvolvimento nós o estamos usando apenas como um repositório de definições de qualidade, pois nele existe a opção de criar um Quality Gate, que é onde ficam centralizados os bugs, code smells e vulnerabilidades do código, definidos e habilitados. Além de englobar tanto linguagens de Back-end como de Front-end, ele possui muitas definições de qualidade já como padrão dentro dele para cada linguagem. Até mesmo se não quiséssemos definir o que seriam os code smells de cada Chapter, nós poderíamos simplesmente ligar todas as definições de qualidades da linguagem e saberíamos que estaríamos entregando um código com qualidade.
Após centralizadas as definições de qualidade, como podemos ter um feedback de que o código que estamos gerando não está criando novos code smells?
Para isso, precisaríamos de uma ferramenta que analisasse o código em tempo de desenvolvimento e sinalizasse quando estamos criando algum code smells ou possível bug no código, ou seja, um Lint. Mas não poderia ser qualquer Lint, precisaria ser um que se comunicasse com o nosso repositório de definições de qualidade que está no SonarQube. Para isso, existe o SonarLint, uma extensão para múltiplas IDE’s que ajuda a detectar e corrigir problemas de qualidade enquanto você escreve o código, podendo se basear no projeto e Quality Gate de uma plataforma SonarQube, ou em modo independente que, então, usa o conjunto de regras padrão para cada linguagem.
Ok, entendi para que servem as ferramentas e no que elas ajudam, mas como seria o processo disso tudo?
É importante entender que todo esse processo de análise de qualidade de código pode ser feito para um projeto já sendo desenvolvido como um novo. Por isso, abaixo segue o processo proposto para os Chapters de desenvolvimento aqui da Trinca:
Configurar o projeto dentro do SonarQube: projetos dentro do SonarQube servem para centralizar o que ele vai analisar e como;
Definir code smells com o time: definir o que faz ou não faz sentido manter como boa prática de programação dentro do projeto;
Habilitar esses code smells no Quality Gate, definindo a criticidade de cada um, de acordo com sua importância e quantidade no código, pois não adianta botar uma criticidade severa para um code smells que existe em todo lugar no código, caso contrário o SonarQube vai bloquear o código que já estava passando e dar a ele uma nota baixíssima;
Linkar esse Quality Gate no projeto criado, assim o projeto sabe quais code smells ele precisa analisar quando for conectado em algum código;
Configurar o SonarLint da IDE de desenvolvimento, para apontar para o projeto criado no SonarQube;
Corrigir esses code smells: em muitos times, essa correção específica é considerada como débito técnico;
Após um code smells deixar de existir no projeto, mudar sua criticidade: como falado anteriormente, agora que o code smells não existe mais no código, deve ser bloqueado qualquer código novo que o conter. Então, para code smells que deixaram de existir no código, é recomendada uma criticidade alta.
No final, o importante é que o time discuta o que é considerado code smells e se preocupe com a padronização de um código e sua disseminação. Existem várias ferramentas no mercado que servem para controle de qualidade para o time, aumentando sua produtividade.
