São inegáveis os benefícios da revisão de código, como a redução do número de bugs, melhora da legibilidade do código, fortalecimento da cultura de feedback, entre outros. Porém, seguindo o velho princípio da física onde toda ação promove uma reação inversa e diretamente proporcional, a revisão de código pode gerar alguns "desconfortos" como a falta de clareza tanto por parte do autor quanto do revisor, falta de padronização e demora na revisão. A ferramenta codeball.ia promete atuar neste último cenário, fazendo a revisão e aprovação automática dos pull requests. Para isso, a ferramenta utiliza algoritmos de inteligência artificial com percepção multinível e, segundo o site da ferramenta, são considerados critérios que vão desde o número de linhas alteradas até a classificação do tipo de arquivo. Baseando-se nestes critérios, a ferramenta gera um indicador do "percentual de confiança na alteração" e pode-se então definir algumas ações para este percentual como: aprovação automática ou adicionar uma marcação com o resultado.
O blog da ferramenta ainda lista um caso de testes onde o codeball é comparado com PR previamente revisados. Este exemplo enfatiza que não houve falsos positivos durante o teste, sendo que este realmente parece ser o cenário mais catastrófico na utilização da ferramenta.
Caso seu código esteja disponível no github, a instalação é extremamente simples: basta adicionar a action do codeball no workflow (no momento está sendo disponibilizada apenas a integração com o Github). A ferramenta é gratuita para projetos open source, para os demais há o custo de US$ 10,00 por usuário/mês, conforme o próprio site, entende-se por usuário o autor do pull request. No site existe ainda uma frase que chama muito a atenção "Pay only if Codeball saves you money" sem dar maiores detalhes sobre como obter este tipo de isenção.
Para avaliar a eficiência do Codeball em projetos que utilizam dotnet e c#, selecionamos projetos que foram tendência no github em fevereiro de 2023, os procedimentos de pull request foram reproduzidos novamente a fim de se verificar se a ferramenta terá o mesmo resultado.
Posteriormente, foi feito o mesmo procedimento de avaliar a eficiência dos projetos, porém utilizando repositórios internos da Becomex. O objetivo desta segunda bateria é verificar como a ferramenta se comporta com diferentes perfis de desenvolvedores ou mesmo se ela considera detalhes da localização do software na sua execução.
Apesar do indicador de confiança apresentar melhora significativa, passando para aproximadamente 0.5, não foi o suficiente para a aprovação do PR. Não foi possível alcançar o
percentual mínimo para aprovação mesmo em pequenas alterações que não comprometem o funcionamento da aplicação. Um exemplo deste tipo de alteração é a utilização dos recursos mais recentes da linguagem para a mesma funcionalidade.
Dados os resultados alcançados, acredito que este é o momento ideal para nos fazermos uma indagação:
Eu preciso de uma IA para auxiliar a revisar meus pull requests?
Mas antes de responder esta pergunta devemos saber qual é o objetivo da organização ao estabelecer o procedimento de pull request, somente com um objetivo claro e quantificável, com por exemplo "Identificar e corrigir 30% dos bugs" ou "Garantir que pelo menos três desenvolvedores possam dar manutenções numa rotina" podemos definir a eficácia do processo. Definido o objetivo, podemos então estabelecer indicadores para medir a efetividade do processo, por exemplo, caso o objetivo seja a identificação dos bugs pode-se rastrear issues de bugs ao PR que as gerou, se o seu objetivo é garantir que mais desenvolvedores entendam uma rotina, pode-se verificar o tempo médio que um desenvolvedor utiliza para fazer manutenção em parte do código.
A definição e rastreamento dos objetivos torna a adoção de uma IA como revisora de pull requests menos traumáticas, mas imaginando que a ferramenta irá alcançar o seu objetivo de aprovação de 63%, que conforme o site da ferramenta corresponde aos PR aprovados sem qualquer comentário, ou mesmo LGTM (Looks Good To Me), sua adoção é necessária?
Deste ponto do artigo em diante trago apenas a minha opinião.
Nem toda alteração precisa ser revisada. Acredito que a revisão de código é um dos mecanismos de revisão de produto que podem ser adotados por uma empresa, outras revisões de produto são o teste pela equipe de qualidade e a homologação pela equipe de suporte ou mesmo pelo cliente. Dependendo de algumas variáveis como o nível da alteração, a criticidade da rotina alterada e o nível do desenvolvedor, nem toda rotina precise passar por uma revisão de código. Obviamente este tipo de decisão não deve ficar ao sabor do momento, o ideal é que durante o planejamento a equipe decida quais alterações precisam de uma revisão mais detalhada e quais não.
Sei que este pode ser o tipo de opinião impopular, mas deixar a decisão nas mãos da equipe é a melhor maneira de envolvê-los no processo, também é da equipe a responsabilidade sobre o número de bugs e sua correção.
Top comments (0)