Revisão de código é mais do que revisar código?

Apesar de não ser uma das práticas mais populares em times ágeis (ela não é nem citada no questionário de 2014 da VersionOne, por exemplo), a revisão de código vem ganhando seu espaço nas equipes de desenvolvimento de software. Afinal, as ditas vantagens da prática são várias: a diminuição na quantidade de defeitos e aumento da qualidade do código produzido, facilitando sua manutenção e evolução.

O próprio nome “revisão de código” deixa claro o objetivo da prática. A ideia é que o código escrito por um desenvolvedor, antes de ser promovido ao ambiente de produção, seja revisado por outro membro da equipe. Essas revisões podem ser feitas de diversas maneiras, como, por exemplo, programação pareada, ou mesmo navegando pelos artefatos modificados. Comumente, o revisor anota todos os problemas encontrados e devolve ao autor original daquele código. O autor então avalia os comentários recebidos e eventualmente os propaga para o código-fonte.

Na Caelum, em particular, as equipes fazem uso do próprio Github, o serviço de hospedagem de código, para fazer suas revisões. Após a finalização de uma história, o desenvolvedor anota a lista de commits e artefatos modificados. Um outro membro do time, em posse dessa lista, inspeciona todo o código modificado; todo e qualquer problema encontrado pelo revisor é salvo em comentários no próprio Github. O desenvolvedor original, ao receber os e-mails enviados automaticamente pela ferramenta, discute e tira dúvidas com seu revisor, e eventualmente altera o código para satisfazer a sugestão.

Interessantemente, imaginamos que um código que tenha passado revisão, tenha uma qualidade melhor, seja menos complexo, mais simples e fácil de ser entendido e mantido. Mas será que isso acontece sempre e de maneira natural? Resolvemos fazer um pequeno estudo dentro das equipes da Caelum para entender quais eram os benefícios que a revisão de código nos trazia.

O primeiro passo foi tentar medir o aumento da qualidade de código. Decidimos automatizar isso olhando para nossos repositórios no Github. Dado que todas as nossas revisões acontecem no Github, decidimos pegar todas as classes que foram revisadas, e a versão dela antes e depois da revisão. Por exemplo, a classe Aluno. Pegamos a quantidade de linhas de código antes e depois da revisão. A ideia é que esse número diminua. Fizemos isso com várias métricas de código diferentes, como complexidade ciclomática, linhas de código, falta de coesão dos métodos e acoplamento eferente.

E, para nossa surpresa, percebemos que os números não mudaram tanto assim após uma revisão. Ou seja, a qualidade do código, sob o ponto de vista dessas métricas, continuou a mesma na maioria absoluta das vezes. No desenho abaixo, você pode ver que a complexidade do código não mudou na maioria das vezes. Interessante, não?!

cweb-CCResult

Na sequência, optamos por mandar questionários para nossos desenvolvedores, perguntando a opinião deles sobre esses resultados, que eram bem contraditórios.

E a resposta deles foi bastante interessante! Os resultados mostraram que nossas equipes se beneficiam da inerente disseminação de conhecimento que acontece ao ler o código produzido por outro desenvolvedor. A percepção de redução de defeitos também acontece, já que o revisor comumente encontra problemas no código produzido pelo desenvolvedor original. Os desenvolvedores também têm a percepção de melhoria da qualidade interna, embora isso não tenha se refletido nas métricas de código coletadas.

Ou seja, a revisão de código não serve só para melhorar a qualidade do código, mas também para disseminar conhecimento entre os membros da equipe, e ajudar a encontrar bugs que o primeiro desenvolvedor deixou passar.

Se você quiser ler melhor sobre nosso estudo, pode ler o artigo que publicamos no WBMA 2014, o workshop acadêmico que acontece junto com a Agile Brazil. Em nossos cursos de agilidade, discutimos o uso de diversas práticas como revisão de código e programação pareada.

E você, faz revisão de código? Em sua opinião, no que ela ajuda sua equipe?

11 Comentários

  1. Diego Sousa 06/01/2015 at 12:34 #

    Interessante o assunto. A algum tempo venho acompanhando suas publicações nessa área e está me parecendo um ótimo assunto para desenvolver um TCC. Mais especificamento no estudo de qualidade de código e a implicação na facilidade da sua evolução.

  2. Tiago A Santos 06/01/2015 at 16:33 #

    Não utilizamos revisão de código na empresa ainda, mas deveremos implantar essa técnica nós próximos meses, e esse texto veio em boa hora.

  3. Fernando Franzini 07/01/2015 at 09:38 #

    Também usamos essa pratica. Nos temos uma anotação chamada de @QA(revisor=”Bart”, date=”01/01/15″) que é coloca sobre que as classes que passaram pela revisão, de forma que possamos ver se o codigo ja passou pela revisão e quem fez. Os mesmos resultados do artigo foram percebidos por aqui. Único ponto negativo dessa pratica em relação a programação em par é a questão do “tempo de feedback.” Na programação em par, código é revisado NO EXATO momento que ele é escrito e na revisão, ele é revisado depois, gerando o feedback dias depois. Isso impacta diretamente no timebox da iteração do time.

  4. Lucas Lopes 07/01/2015 at 11:47 #

    Olhar a revisão de código como forma de disseminar o conhecimento é uma ótima sacada! Ainda não tinha pensado nisso e olhando para minha caminhada como líder de equipe percebo que aprendi muito realizando a revisão de código dos demais membros. Sempre insisto para que realizem as revisões, por exemplo, durante o commit e update do código fonte. É uma prática que já é uma rotina no meu caso.

  5. Guilherme 08/01/2015 at 15:20 #

    Olá Maurício Aniche.

    Primeiramente gostaria de parabeniza-lo pelo post, além de bem escrito está abordando um tema, que na minha opinião, é relevante e por mais discutido que seja, poucas pessoas resolvem colocar em prática, a nossa querida “Qualidade de código”.

    Infelizmente na equipe onde trabalho essa não é uma prática comum (quem sabe se encaminhar esse post para os demais membros uma chama não se acende). Os códigos são implementados, a aplicação é testada e se tudo ocorreu como esperado o sistema vai para produção.

    A minha participação (como comentarista neste post) é minha experiência. Por diversas equipes e diversos projetos que participei, várias vezes, quando me deparava/deparo com um código legado vejo possíveis melhorias, algumas mais simples, outras já mais complexas. Entretanto minha maior contribuição aqui não é o que vi dos outros, mas o que foi visto do que produzi/produzo. Em algumas ocasiões quando um outro desenvolvedor (geralmente com mais experiência) se deparou com meus códigos ele encontrou “erros” similares aos identificados por mim, coisa que eu não vi e/ou não sabia que a linguagem possibilitava fazer.

    De fato não é demérito algum (isso claro na minha opinião) que um código seja revisado. Muitas das vezes o desenvolvedor cria um cenário para a solução de um problema na cabeça dele e não consegue enxergar por uma outra ótica, não é um caso de ser bom ou ruim, é um caso de ponto de vista ou pensamento diferente.

    Dessa forma receber/fornecer ajuda na avaliação dos códigos do projeto onde se trabalha só tem a agregar no resultado final, um pouco de tempo a mais, que no futuro se reverte em manutenção de código facilitada.

    Bom, de qualquer forma espero ter agregado algo no post para os futuros leitores. Mais uma vez, parabéns Aniche pelo post, um tema bom, comum e pragmático no dia-a-dia dos desenvolvedores.

    Até.

  6. Sidney Amaral 15/01/2015 at 23:24 #

    Parabéns pela ótima abordagem do tema no post. Time e empresa são muito beneficiados com a revisão de código, mas implantar é dureza 🙂 Mais uma vez, parabéns!

  7. Frederico Maia 21/01/2015 at 10:40 #

    Fazemos revisão de toda tarefa implementada e concordo plenamente com o trecho em negrito. Ainda prefiro a programação em par para tarefas mais complexas ou para membros novos no time, nesses casos não temos revisão pois já é feita no mesmo momento.
    A cultura da revisão é complicada de implantar, mas vale a pena e toda equipe deveria fazer.

  8. Yelken Gonzales 22/01/2015 at 12:08 #

    Mauricio,

    Parabéns pelo post.

    Já trabalhei em uma empresa que revisava o código e o ganho com isso foi que diminuímos consideravelmente a quantidade de atividades de retrabalho e até da própria equipe de testes porém o projeto se estendeu muito.

    Na empresa atual, não fazemos isso e quando percebo um erro de código quando estou dando manutenção em algum módulo não tenho tempo para corrigir e muitas vezes o desenvolvedor que fez aquele código já está em outra atividade então fica difícil parar e corrigir.

    Com isso geramos mais versões, tem mais atividades de retrabalho, os testes encontram mais erros e assim por diante.

    Minha conclusão é que vale a pena sim revisar código e o tempo gasto compensa pois com certeza a qualidade do software é outra.

  9. Maurício Aniche 22/01/2015 at 12:42 #

    Oi pessoal,

    Obrigado pelo feedback. Revisar código é mais difícil que parece. E a parte boa é que você pode dar o foco que quiser para isso: revisar código para disseminar conhecimento, para melhorar qualidade interna, para encontrar bugs, e etc!

  10. Michel Souza 22/01/2015 at 16:47 #

    Muito bom o artigo, ótimo ponto de vista apresentado. Obrigado!

  11. Phillippe Santana 27/08/2016 at 12:42 #

    Olá, achei estranho: se entendi corretamente, as pesquisas de vocês mostraram uma *percepção* de melhoria de qualidade, mas isso não foi refletido nas métricas. Parece que o pessoal *acha* que melhorou, mas que na prática essa melhoria não aconteceu. É isso mesmo? Não consideram necessário que haja impacto real nas métricas para concluir que a revisão de código, da forma como está sendo feita, está realmente valendo a pena?

Deixe uma resposta