#188 Seu código pode ficar muito melhor usando o SonarQube

Fernandinha: E está começando mais um Entre Chaves, o seu podcast de desenvolvimento de software. E hoje a gente vai falar sobre uma ferramenta amplamente conhecida no mundo de desenvolvimento. A gente vai falar sobre o SonarQube, que é uma ferramenta muito adotada para análise e qualidade de código. E para esse tema de hoje, Champs, está comigo aí, como sempre, Champs.

Champs: E Fernandinha, tudo bem? O Sonar, que é dor de cabeça de muito dev aí, que fica pegando no pé lá da qualidade do código, mas que está aí para um bem maior e nós vamos provar isso para a gente.

Fernandinha: Exatamente. Então para falar sobre isso, estamos aqui com o Marcelo, mais conhecido como Juninho. E aí, Juninho, como você ta?

Marcelo: Boa tarde, Fernandinha. Boa tarde, Champs. Eu sou Marcelo, mais conhecido como Juninho aqui na dti, atuo hoje como arquiteto. E estamos aí para falar um pouco sobre a ferramenta bem importante aí no dia a dia dos desenvolvedores, o SonarQube. E que às vezes a gente tem alguns desafios aí de como correções de bugs, codes smells.

Fernandinha: Exatamente. Então bora. E para complementar que o nosso time, estamos aqui com o Jeff.  E aí, Jeff, Jefferson, né?

Jefferson: Eu sou Jeff, eu sou também conhecido como Jeff aqui. Estou aqui já há três anos, como tech leader, dez anos aí de mercado, trazendo um pouco aí da experiência de ambos os lados, como dev, aquele cara que odiava essa ferramenta para o cara que hoje tem como uma das melhores amigas.

Fernandinha: Olha aí, vou querer saber essa história com certeza. Mas antes, então, de a gente entrar nessas histórias, acho que vale para o nosso ouvinte e acredito que muitos conhecem o SonarQube, mas acho que vale só a gente dar uma pequena introdução do que é essa ferramenta, qual que é o objetivo dela, para a gente entrar um pouco mais na discussão, um pouco mais aprofundada sobre. Então, quem pode puxar aí para nós?

Jefferson: Bom, acho que o SonarQube é um dos principais líderes de mercado, principalmente pela facil integração que ele tem na questão de a gente subir uma instância ali no Docker, acoplar ele muitas vezes, dependendo da ferramenta que a gente está usando. Aqui no cliente que a gente faz parte já tive a oportunidade de utilizar com Jents ou Azure, e é muito simples. Dois comandinhos ali a gente já está instalando e utilizando, fazendo análise na nossa pipeline, para poder integrar também, é muito simples. E a ferramenta ela vem com um objetivo ali de acoplar e auxiliar na qualidade de código, a fazer com que a gente siga alguns design partterns. E é uma ferramenta muito poderosa porque ela vem com a usabilidade para mais de 14 tecnologias. O SonarQube fica muito integrado ali. A minha maior expertise é em Java, então ali tem muito design partterns que a gente acaba ensinando, ou muitas vezes a gente não segue e ele nos alerta para poder seguir.

Marcelo: Complementando o Jefferson, a ferramenta é bem importante, participa praticamente de todo o ciclo de desenvolvimento de software, e ajuda o desenvolvedor a atuar proativamente na melhoria do código fonte mesmo que está sendo entregue. Então, é uma ferramenta que às vezes pode dar uns sustos em alguns desenvolvedores, mas é bastante importante tratar como uma aliada no dia a dia.

Fernandinha: Totalmente, aqui na dti a gente tem o nosso dti flow, que é o nosso fluxo de desenvolvimento de software, as nossas boas práticas de desenvolvimento de software. E o Sonar é um dos exemplos de uma ferramenta de auditoria de código que está bem integrada ao nosso fluxo de desenvolvimento, ou seja, assim que eu finalizo uma história, é super importante que eu passe pelo Sonar, seja via pipeline, como vocês mesmo falaram, ou até rodando local no interno da minha máquina, de alguma forma para fazer alguma auditoria de código.

Jefferson: Isso mesmo, Fernandinha. Inclusive facilita no processo do CodeReview, porque acaba que se quando a gente tivesse que fazer as revisões de código, a gente pegar tudo, às vezes que o Sonar aponta, ia ser um trabalho muito mais intenso, do que a gente já utilizando o Sonar antes para poder conseguir atacar esses pontos. Principal auxílio que eu acredito que ele traz, quando a gente está fazendo o CodeReview, é na questão de que ele aponta o seu problema e ele já traz uma possível solução. Então ele diz, olha, essa solução aqui está sendo guiada através de tal design parttern, que a gente vai seguir e poder evoluir com ele. Então, isso aqui é importante devido a tal e tal. E se for um problema de vulnerabilidade no mesmo sentido. Ele vai dizer, ó, é vulnerabilidade, e que somos aí para pegar em tal biblioteca, e a gente está evitando utilizar devido a isso.

Champs: Trazer uma pergunta pouco polêmica aqui, que a gente tem o SonarLint também, né? A gente usa a extensão lá no nosso IDE e consegue fazer algumas análises ali pelo SonarLint. Só o SonarLint já não seria suficiente para me ajudar a tratar a qualidade do meu código. Qual que é a grande vantagem de eu realmente usar o SonarQube ou integrar ele de alguma forma?

Jefferson: Uma das principais vantagens de utilizar é a geração dos relatórios, e a gente ter um acompanhamento ali ao longo do tempo de como estava a nossa ferramenta. E o SonarQube, ele vem com algo mais implemental que ele traz ali também as questões do OWASP 10, que são as 10 principais vulnerabilidades que a gente tem aí, envolvendo segurança. E além disso, ele traz também para a gente algumas análises, que é um pouco confuso como ele faz, mas por exemplo, se a gente tiver 15 code smells, ele vai dizer, olha, esses code smells aqui leva 3 horas para poder normalizar o seu ambiente, para que você fique sem vulnerabilidade, sem problemas aqui no seu código. Então, ele tem uma forma de fazer aquele cálculo provavelmente é muito baseado em como ele faz na sugestão que ele está fazendo para refatoração, em quanto tempo levaria para você refatorar todo o sistema. Mas ele já traz isso aqui, meio que de bate-pronto para você. Então, é nosso amigo também quando a gente está falando de débito técnico, ao passar das sprints, quanto tempo a gente levaria para voltar e arrumar algum problema que a gente acabou deixando.

Marcelo: Se não me engano, o SonarLint também às vezes não pega tudo o que o SonarQube pegaria. Eu pelo menos já tive essas experiências. E às vezes o SonarQube não aponta nada para mim na IDE e após o processo de análise do SonarQube, o SonarQube trouxe alguns apontamentos que no caso não foi visto no momento de desenvolvimento.

Jefferson: Perfeito, tem um ponto importante também que a gente tosse aqui em um cliente, que a gente já fez parte, é que o SonarLint não é tão configurável, ele faz análise conforme os parâmetros que ele tem. E o SonarQube dá para a gente configurar algumas coisas. Um exemplo, a gente tinha um legado que tinha muita vulnerabilidade e o legado, o código era uma documentação. Então, já tinha um cliente que estava lá há mais de 10 anos, aquela pessoa já saiu, não tinha nenhuma documentação. E a gente começou a ligar algumas regras no Sonar para obrigar a construção do código com comentários. Então, a partir de agora, a gente tem que ter 30% da classe com comentários explicando o que estava acontecendo, cada método, para depois a gente gerar um swagger e utilizar aquilo ali como uma migração para novas tecnologias, por exemplo.

Fernandinha: Uma outra coisa que eu fiquei pensando em relação a vantagens é que o Lint na minha máquina local depende do desenvolvedor e da boa vontade dele para executar, certo? E o SonarQube eu posso integrar em um pipeline, colocar um quality gate e realmente impedir uma publicação, um merge, caso as quality gates sejam violadas.

Champs: Realmente, você conseguir integrar nossos pipelines, colocar quality gates e só permitir com que seu código suba caso determinados níveis de qualidade ali determinados estejam definidos mesmo e esteja tudo passando, é uma vantagem realmente que você não vai ter no Lint.

Fernandinha: Mas o Jeff falou um negócio ali de uma experiência dele com sistemas legados e aí eu lembrei de uma minha também, que teve uma época em que eu usava o SonarQube no sistema legado e era assim, sei lá, quantos anos, sei lá, de code smells, enfim, não lembro se era nessa ordem de grandeza, mas era um negócio realmente absurdo da quantidade de code smells que existiam nesse legado. E claro que a gente não tinha nem a pretensão de zerar esse indicador.  E aí, na experiência de vocês, o que fazer nesse cenário? Eu uso o Sonar num legado e lido com, sei lá, eu tenho essa quantidade de code smells, mas eu não posso passar desse número, ou eu nem uso?

Marcelo: Eu já tive essa experiência também, viu, Fernandinha? Inclusive, o legado, quando a gente atuou nele, não tinha o Sonar, quando a gente configurou, a gente tomou até um susto, né? A quantidade de code smells, de bugs que tinha, era impossível de a gente ficar trabalhando o tempo inteiro para poder zerar aquilo. Uma abordagem que a gente tomou foi para códigos novos, a gente ter essa configuração das métricas, para que a gente garanta que o código entregue não incremente o número já existente quando rodou aquela primeira análise. E a outra ideia também é já ir atacando as vulnerabilidades ou bugs principais do sistema que a gente via como crítico e aí gerava um backlog de débito técnico, com a parte em cima disso, até para poder tirar os itens de maior criticidade ali.

Jefferson: Perfeito, a experiência que eu tive foi um pouco parecida com o que o Marcelo falou, que foi a questão de, quando a gente ligou o Sonar, que a gente foi para trás e viu 200 horas aqui de débito tecnico, talvez numa poc  a gente consiga trazer isso para novas tecnologias com algo mais arrumadinho, e o cliente abraçou, foi bem legal. Mas existe também algo que é muito necessário, que é como a Fernandinha mencionou, que a gente tem que partir sempre da premissa de, eu sei que está ruim, a gente está aqui para tentar melhorar, mas eu também não posso piorar. Então, eu sou muito a favor de a gente ligar e ir monitorando e dizendo, olha, daqui a gente não pode piorar não, a gente tem que voltar, tem que manter e entender as principais vulnerabilidades que aqui está sendo demonstrada para a gente ir atuando.

Fernandinha: Nesse exemplo que eu dei, a gente também optou por ir por esse caminho, de não podemos piorar, a gente não vai, a gente sabe que a gente não vai melhorar infinito, apesar de que a gente volta e meia, conseguia corrigir uma quantidade grande de code smells, mas a gente sabia que não iria zerar, mas a gente também não podia piorar. Então, a gente foi com essa mentalidade aí e que foi uma mentalidade do escoteiro de sempre ir, quando eu estou mexendo numa classe, eu vejo lá que tem alguns code smells, ir lá corrigindo aos pouquinhos, por aí vai.

Champs: Mexendo num legado é sempre mais complicado, eu tive essa experiência também, o Juninho conhece bem o legado que a gente enfrentou lá e o sonar é muito bom para a gente ter visibilidade do que às vezes está invisível desses code smells, desses problemas, mas tem vezes também que no legado você não consegue resolver. A gente tem um cenário, por exemplo, nomes de variáveis que estão mal definidos, que estão apitando no sonar, mas que a gente às vezes opta por manter ruins para ficar no padrão do código antigo, já que você não consegue refatorar todos os nomes do projeto inteiro. Então, esse é um exemplo, por exemplo, de um code smell que a gente optou por, em algumas classes que a gente estava mexendo que já eram antigas, por manter, para ficar mais fácil da manutenção, do que realmente melhorar ali. Então, quando falo do sonar, o cenário legado é bem complicado, só que, de fato, dar essa visibilidade, trazer esses problemas à tona, eu acho que é a grande vantagem. Então, acho que não tem por que não usar.

Fernandinha: E o sonar tem algumas métricas que ele mede. Ele mede code smells, ele mede vulnerabilidades, cobertura de código e bugs. Só que, às vezes, essas coisas são meio confusas com o desenvolvedor para entender. Então, queria se vocês pudessem, dar algum entendimento dessas métricas, acho que seria legal pro episódio.

Marcelo: É isso mesmo, Fernandinha. O sonar, quando ele rodar análise, ele já apresenta essas métricas para a gente, igual você especificou. O code smell, basicamente, são formas de melhorias para poder escrever um código melhor. Até para poder manter a manutenibilidade da aplicação, até a facilidade de ler, entender aquilo, remoção de código que não está sendo utilizado, comentários desnecessários. Tem o bug que, no caso, a análise consegue identificar alguma possível quebra de aplicação. Como, por exemplo, null pointer que, às vezes, não foi testado ou validado, então, ele traz isso como indicador de melhoria também. Tem a parte de vulnerabilidade que ele mostra se tem alguma possível ingessão de código dentro da sua aplicação, seja qualquer outro tipo de vulnerabilidade e segurança, ele consegue identificar também. Tem a parte de cobertura, igual você falou, então, quando a gente desenvolve os testes unitários na nossa aplicação, ele consegue identificar se os testes unitários estão cobrindo as nossas classes que estão sendo testadas. Tem a parte de duplicação de código que ele ajuda a entender se você está gerando linhas repetidas que, às vezes, poderiam ser implementadas num método único ou uma funcionalidade única. Então, são várias métricas que, quando o sonar roda essa análise, consegue trazer para o desenvolvedor aí para até escrever um código melhor e um código limpo.

Jefferson: Aqui, a gente teve essa experiência também de fazer a quebra por dois sonar. O primeiro, a gente tinha uma cobertura de código e inferior as demais porque a qualidade do código era um código um pouco mais antigo, um código legado que a gente estava buscando não piorar a ele, mas, quando a gente está dentro de um código que houve algumas vulnerabilidades e alguns code smells, que são críticos e têm diversos alarmes que ele faz, a gente tem que tentar mapear e criar um debito tecnico que ali pode ser um reforço de acordo com os insumos que a própria ferramenta dá para a gente buscar a priorização ali dentro do time para conseguir a atuação. Além dessas informações, o quality gate que é muito importante que ele vai fazer uma validação dentro da nossa pipeline, por exemplo, hoje a gente tem uma pipeline aqui que é exigido 90% de cobertura de código. Então, muitas vezes o desenvolvedor está fazendo ali a sua atividade e está incorporando, ele vai fazer uma entrega e existe um conflito entre a entrega dele com de outra pessoa. É comum. E quando o código cresce, que existe uma duplicação, ele faz dois alertas. Um principal que é, olha, a cobertura de código não está sendo atendida e um segundo que é alguém está copiando o código. Dependendo da versão do sonar, a gente já conseguiu ver que lá existe uma análise até se a gente está copiando o código direto de algum lugar e colando diretamente no nosso código. Se a gente copiou um código, existe análises em clientes que a gente já participou que ele verifica se a gente copiou um código, por exemplo, do GitHub e colou diretamente no nosso código ali, a gente está usando o código de terceiro. Entende? Vai fazer uma validação se a gente está fazendo copy paste, se a gente está usando algum anti parttern também, é muito importante entender se a gente está fazendo algo que vai fazer com que nossa aplicação não seja mais legal ao longo do tempo.

Champs: Eu acho que é bem legal evidenciar a questão dos débitos técnicos de como que todo mundo citou, que se deparando com código legado a quantidade de débitos técnicos que tem, quando você já nasce um projeto conectado ali no sonar e você mantém isso num nível adequado, você consegue gerenciar muito melhor isso. É claro que o débitos técnico é um pouco mais subjetivo, você não vai garantir que seu código está sensacional só de passar nas métricas do sonar. Mas você já garante muito menos problemas do que poderia.

Fernandinha: E além de que instrumentar seu código com métricas, a gente já falou mil vezes aqui no Entre Chaves, a importância de a gente ter métricas dos nossos códigos para avaliar a qualidade. Afinal, a gente está ali produzindo um tanto de coisa, se a gente não tem métrica, a gente não sabe se está evoluindo ou não, a gente não sabe se a gente está provocando impacto em outras coisas, se a gente está piorando a qualidade do nosso código. Então, trabalhar sempre com número de forma objetiva, em relação à qualidade, parece uma excelente prática.

Champs: E outra coisa que eu fui pensando, aqui já puxando outra pergunta, é que com a gente tendo muita interferência da inteligência artificial, em termos de desenvolvimento, o quanto que o sonar continua ou deixa de ser uma ferramenta interessante de ser usada nesse contexto, queria  saber  na experiência de vocês, a gente tendei copilots tendo a própria geração de código por IA, com chatGPT, com outras opções. O quanto que isso impacta no uso do sonar? A gente não precisa mais usar o sonar porque tem essas ferramentas, ou a gente precisa usar o sonar mais ainda porque tem essas ferramentas?

Fernandinha: Então só complementando, porque eu tinha colocado exatamente a mesma pergunta, mas até indo além, o sonar também está pensando em ter funcionalidades de IA, ou já está abraçando funcionalidade de IA também pra isso.

Jefferson: Respondendo a pergunta do Champs, eu, por exemplo, eu gosto muito de usar IA pra poder gerar, usar IA pra gerar alguns códigos pra mim e eu tenho notado que a IA realmente já tem entregado alguns códigos de qualidade e acredito que a tendência é cada vez mais ela tendo melhorias nesse ponto. Mas eu ainda assim não substituiria o sonar por completo até porque eu acho que, querendo ou não, ali é uma garantia de que a gente não faça entregas com margem de erro, margem de quebra e em produção.

Marcelo: Perfeito. Eu acho que toda ferramenta é como se cada desenvolvedor fosse o Batman, a gente tivesse o cinto ali do Batman com ferramentas e cada ferramenta ele tem um propósito e a gente tem que usar bem ele. Hoje em dia, com avanço da IA no meu dia a dia é muito importante eu uso com uma certa frequência mas, por experiência, saber perguntar bem e analisar o que ela está dando de retorno pra gente. Acredito que nem todo mundo na equipe, principalmente hoje na alta demanda do mercado, a gente recebe muita pessoa aqui na dti que a gente está treinando que a gente está evoluindo e a gente precisa dar conselhos evoluir um pouco mais as skills técnicas de cada pessoa e isso não dá pra gente evoluir rotineiramente ali a cada hora, a cada comitt e o sonar já vai dando alguns viés daquela pessoa. Então serve como uma auto validação. Eu estou fazendo uma validação aqui e vi que deu um erro que deu um problema eu vou corrigir e depois vou chamar aqui o meu líder vou chamar aqui o arquiteto pra gente trocar uma ideia entender o que é daquilo mas é mais uma ferramenta que a gente vai utilizar que a gente vai ter como oportunidade de utilizar implementado também acredito que ela não vai entrar em desuso não, ela vai incorporar ali aí junto a ela não sei se tem ainda também, mas ela vai incorporar e vai facilitar e evoluir ainda mais.

Fernandinha: eu concordo com o pessoal principalmente pelo até um fator que eu já falei que eu acho que a adoção e eu já falo um pouco disso também. A adoção de IA no desenvolvimento ainda depende também da adoção própria do desenvolvedor, individual do desenvolvedor, do quanto ele quer utilizar e nesse tema ainda de IA e de sonar eu estava entrando no site aqui do SonarSource que é o dona ai do ecossistema do sonar lint, o sonar cloud e o sonar qube de fato. E assim, a primeira abertura do site deles aqui está “clean coding in the age of the generative AI” eu acredito que eles estão evoluindo a ferramenta deles para incluir mesmo todo esse hype da IA generativa pra fazer até análise mais assertivas.

Champs: é, só concordando com todo mundo mas são ferramentas complementares. Hoje ainda eu vejo hoje em dia o github tem uma métrica de que hoje na verdade outubro do ano passado, ele falou que 45% do código hoje no github já é gerado por AI então assim, acho que hoje deve ser ainda maior esse número, então assim, tem muito impacto sim da geração de código por AI nos nossos códigos mas eu não acho que a nula realmente sonar na minha experiência pessoal hoje pode até ter mais necessidade de usar o sonar para a gente não gerar códigos sem saber o que a gente está fazendo. Então ainda assim, acho que é muito importante ter que passar por esse tipo de validação e eles podem ser muito complementares tanto a IA nos ajudando a escrever códigos com menos code smells para o sonar analisar quanto a gente usando a IA para evitar os code smells também, uma POC que eu tenho feito recentemente aí, vou entregar o ouro hein. A gente montou meio que um code guide, um guide de código mesmo que a gente quer seguir no nosso projeto e a gente está montando uma estratégia de prompt para falar assim para o co-pilot “analisa esse código de acordo com o meu code guide e me fala o que ele está em desacordo com o que eu quero seguir de qualidade de código”. Então fica uma coisa até mais personalizável. Talvez venha a ser uma funcionalidade do Sonar no futuro, mas é algo que eu acho que pode ser complementar ainda mais

Marcelo: Você falando disso aí lembra da questão do Jefferson falou do Quality Gate, que a gente consegue fazer as configurações do Quality Gate porque que a gente não conseguiria fazer algumas customizações assim em cima disso para fazer até a própria quebra do build?

Jefferson: Mas aí também é aquela questão que o Champs acabou de falar que ela ainda precisa de um input humano. No sonar ele vai fazer a validação do que está entrando ali que vai ficar disponível para os nossos usuários utilizarem. Então, garantiria que a gente não estava fazendo nada de errado ali ou subindo alguma coisa de errado.

Champs: Eu acho que haveria a possibilidade de integrar essa inteligência no Quality Gate também. É uma ideia. A gente está mais do que na era da IA e do sonar, estamos na era da experimentação. Eu acho que dá para experimentar e fazer muita coisa nova que está surgindo no dia.

Fernandinha: Beleza, eu acho que a gente discutiu aqui bastante coisa sobre o porquê usar, o que é o sonar, como é o futuro, se o sonar vai ficar obsoleto ou não, mas dado que um time ficou convencido aqui que faz todo sentido olhar de forma objetiva para a qualidade de código. Beleza, e aí? Quero começar a usar, o que fazer? Quais são as boas práticas?

Jefferson: Uma das primeiras intenções é, hoje o sonar ele tem a sua versão economic quando é para todo mundo utilizar ele gratuitamente e desde que não seja para fins comerciais. Então, baixa, coloca ele numa instância do Docker, integra ele ali e depois com um simples plugin você consegue colocar ali, dependendo da sua pipeline, tem plugins na Azure e no Gents nas principais pipelines. Então você vai colocar um plugin e a partir de agora você vai colocar uma configuração ali na sua pipeline para quando ele passar, quando você fizer um request integrar uma determinada branch, ele passe ali pelo Sonar e faça as devidas validações. Você consegue customizar qual a porcentagem de cobertura que você quer exigir qual a quantidade de code smells que sua aplicação pode aceitar. Hoje a gente tem aplicações aqui que é cobertura de 90% de cobertura de testes, zero code smells e se eu não me engano é no máximo 10% de redundância de código, de código duplicado.

Marcelo: E complementando o que o Jeff falou, a gente tem além do Sonar Qube, as outras ferramentas que a gente citou aqui também, que é o próprio Sonar lint que já pode ser usado diretamente nas IDEs no Visual Studio, no IntelliJ a gente instala como um plugin mesmo e tem até essa questão, a gente falou muito do Sonar Qube e existe também o sonar cloud que já é um serviço que é oferecido na nuvem que dependendo facilita até essa integração com o repositório do desenvolvedor, mas a configuração realmente é bem simples a documentação que eles disponibilizam no site é bem intuitiva. Então, eles oferecem suporte para várias tecnologias então hoje as mais utilizadas no mercado provavelmente tem o suporte de integração e com o Sonar e é isso.

Champs: Uma outra coisa que eu acho que vale ressaltar também que a gente comentou brevemente é a parte do OWASP. A parte do OWASP tem também como definir quality gate pra quebrar na pipeline, se tiver alguma vulnerabilidade do OWASP, lá da análise do OWASP? Só porque eu já usei avaliando manualmente, mas eu não usei configurado na pipeline.

Jefferson: Da sim, altamente acoplado e ele já tem algumas algumas métricas, eu não vou lembrar quais são as regras, mas a primeira se for uma crítica severa do OWASP ele quebra na hora, ele não deixa subir e se for medium, parece que a partir de 3 ele já quebra também mas é totalmente configurável e automatizável pra não deixar uma médium, por exemplo.

Champs: Tô tendo vários insights hoje relacionados a IA, sonar e o sonar se quiser se escutarem esse episódio vão ter várias ideias, mas essa própria sugestão de vulnerabilidades críticas ou de problemas de code smells bem encontrados que ele já tem da sugestão se você olhar a documentação, a gente sabe que tem ferramentas como o próprio copilot, por exemplo e outras IAs que geram código que já geram sugestões de correção nos requests. Talvez a gente já consegue hoje construir alguma coisa que integra na pipeline e analisando essas vulnerabilidades que o Sonar aponta, já surgiram as melhorias de código automaticamente. Talvez o Sonar venha a fazer isso de alguma forma talvez a gente não possa trabalhar de alguma forma, mas também tô viajando aqui já nas possibilidades. Mas seria bem legal.

Fernandinha: Existem algumas outras já, existem extensões aí do próprio Azure, falar mais da Azure que é o que eu mais acompanho. O próprio Azure Boards que a plataforma da Azure também, o portal da Azure que você consegue criar uma subscrição da Azure com o recurso da OpenAI e você consegue fazer revisões por request utilizando as APIs da OpenAI, do ChatGPT, mas, às vezes, vamos ver, ne? Se o sonar também vai ter alguma funcionalidade dessa, até então, acredito que eu não vi nada semelhante. Mas, eu tava querendo puxar só uma última discussão aqui em relação a custo. Porque todas essas ferramentas talvez o línter, aí o sonar lint, acredito que não. Mas o sonar cloud e o sonar qube, como o Jeff falou, talvez o cube pra fins não comerciais também é gratuito, mas pra fins comerciais de mercado, tanto o cube quanto o cloud são pagos. E aí queria conversar com vocês um pouco sobre essa parte do custo do quanto que vale, como que é. O trade-off sempre entre o custo daquela de tratarmos qualidade de código com uma ferramenta e o custo de fazer isso de forma por exemplo, se usando um lint mesmo, um sonar lint mesmo que é gratuito.

Jefferson: bom, hoje em dia existe algumas formas que ele vai poder cobrar e normalmente vai ficando mais barato, conforme a quantidade de usuários que a empresa vai disponibilizar para ficar usando, mas vai se eu não me engano, desde 160 dólares para a versão developer, para um desenvolvedor tá por ano ali por ano. 160 dólares até uma versão de 200 mil dólares para uma empresa de 10 mil pessoas, por exemplo, e aquela licença fica compartilhada entre todos e todo mundo iria utilizar.

Champs: 200 mil dólares?

Jefferson: Acabei de confirmar, 252 mil dólares por ano para 100 milhões de análises.

Champs: Mas, então são esses dois tipos de especificação que existem hoje ou tem mais alguma possibilidade?

Jefferson: Bom, eu entrei aqui nessa parte do planos e preços e ele consegue disponibilizar de três formas. A primeira é para um desenvolvedor, ele analisando ali, então fica em torno de 160 dólares para até 100 mil registros analisados e pode se estender até quase 70 mil dólares por ano para 20 milhões de linhas analisadas. E na versão Enterprise começa por ano básico de 21 mil dólares por ano até 1 milhão de linhas analisadas e 252 mil dólares para até 100 milhões de linhas analisadas.

Champs: Então, assim, concluindo mesmo não é barato, não é uma licença barata, acaba que muitas grandes empresas hoje têm uma receita que consegue bancar esses tipos de ferramentas e mesmo não sendo barato, é algo que acaba se pagando bastante, né? É melhorar nessa gerência de débito técnico a longo prazo, né? Você otimiza muito a qualidade do seu código, o tempo de desenvolvimento que, no final das contas é dinheiro também, né? Então é algo que se paga nesse sentido, né? Para projetos menores empresas que não têm condição de custear uma ferramenta dessa ainda assim é muito recomendável o uso do linter, né? E de fazer a gerência de débito técnico do seu código assim, da maneira que for possível, né?

Jefferson: É, é muito importante que o pessoal adote o uso do línter. Há alguns ferramentas, como por exemplo o Angular, ele já traz o próprio linter ali, quando a gente traz o governo, a gente pode rodar o linter ele já faz a análise está ali e acordo com os parâmetros que ele tem. Nenhuma ferramenta hoje de mercado, pelo que eu dei uma olhada é tão poderosa quando Sonar, mas existe também opções OpenSource que dá para ir incorporando e utilizando como, por exemplo, um carro chefe que eu pensou ser aí é o PMD que dá para acoplar tão facilmente quanto ao sonar e ele também faz algumas análises e direciona quando debitos técnicos, quality gate, etc.

Fernandinha: Beleza, a gente acha bem legal assim, né? Conhecer um pouquinho mais do Sonar. Essa ferramenta, como eu falei no início que é muito utilizada pelos desenvolvedores no dia a dia. A gente falou então sobre o porquê utilizar as métricas se o sonar vai ser substituído ou não com IA, se a gente deveria continuar usando e falamos aqui que sim. É uma ferramenta extremamente importante, mas caso você não tenha uma ferramenta como essa, não tenha acesso ou, enfim, não acredite que sua empresa que faça sentido para sua empresa adquirir uma ferramenta dessa faz todo sentido utilizar um linter porque a gente acredita bastante na importância de ser objetivo em qualidade de código, de analisar qualidade de código de forma objetiva para que a gente consiga historicamente melhorar os nossos códigos produzidos e, no futuro, não ter código que a IA enfim, surgira que seja código ruim. E é isso, gente, tão muito obrigada e é isso, até a próxima, tchau, tchau.