Revisão de Código

O processo de revisão de código é há muito defendido pela IBM, de facto desde 1974. Inicialmente designado por “inspecção de código”, um processo formal de análise estática para validar se o software vai ao encontro do requisitos. Este processo era lento mas mesmo assim a IBM conseguiu atingir significativas melhorias na qualidade do código entregue.

A empresa (IBM) quase duplicou o número de linhas de código entregues nos produtos de software do System/370 desde 1976, enquanto o número de defeitos por milhares de linhas de código foi reduzido em dois-terços – Michael Fagan

Graças a ferramentas colaborativas de controlo de versões, conseguiu-se agilizar este procedimento, tornando-o num processo de rotina diária. Na minha equipa, todos os dias, cada engenheiro lê, revê, avalia e comenta o código de algum colega. O objectivo é se aumentar a confiança no código que entrará em produção, reduzindo o número de bugs. O processo de revisão implica que o código poderá ser actualizado e novamente revisto. Esta troca de informação deverá ocorrer o número de vezes necessárias até que a equipa – quem produziu o código e quem reviu – esteja totalmente confiante com o resultado.

Não existem regras rígidas de como deverá funcionar este processo. Com a disseminação do procedimento, o bom senso imperou e começaram a surgir, de diferentes fontes, boas práticas aconselhadas.

A empresa SmartBear Software desenvolveu um pequeno white-paper com 11 boas práticas para um eficaz processo de revisão de código:

  1. Rever menos de 200-400 linhas de código (LOC) de cada vez.
    • Mais de 400 linhas de código exigirão maior tempo de atenção, além de ser desmoralizador para o revisor saber de ante-mão que irá passar o dia inteiro a rever “aquele” código.
  2. Apontar para um rate de revisão numa ordem inferior das 300-500 LOC/hora.
    • É preferível que se analisem menos linhas de código mas que se procura situações como bugs, possíveis falhas de segurança, possíveis falhas de optimização e até possíveis falhas no desenho ou arquitectura do código.
  3. Ter tempo suficiente para rever adequadamente, e com calma, mas nunca mais de 60-90 minutos.
    • Por ser uma tarefa que exige atenção ao detalhe, a capacidade de concentração irá decair drasticamente quanto mais tempo levar a tarefa a concluir. Por experiência própria, após 60 minutos de revisão eficaz de código, ou se faz uma pausa (ir beber um café, levantar da cadeira e fazer alguns alongamentos, ler um artigo, etc) ou se começa a ser complacente com algum código e deixa-se de se analisar situações sensíveis como questões de segurança, optimização e escalabilidade.
  4. Autores deverão anotar o código-fonte, antes do processo de revisão começar.
    • É importante que o autor do código encaminhe os seus colegas para quais os ficheiros que devem ser revistos, evitando que código já revisto seja novamente validado.
  5. Estabelecer objectivos quantificáveis para o processo de revisão de código e capturar métricas para se poder melhorar o processo.
    • É importante que a equipa de gestão tenha forma de quantificar se o processo de revisão de código é eficaz, como por exemplo, contabilizar o número de bugs reportados pelo cliente.
  6. Lista de validação melhoram substancialmente os resultados tanto para os autores como para os revisores.
    • O que rever? Sem uma lista, cada engenheiro poderá procurar por algo em particular e deixar ao esquecimento outros pontos importantes.
  7. Validar que os defeitos foram de facto corrigidos!
    • Não basta um revisor indicar onde estão as falhas ou sugerir melhorias. E não se trata de uma questão de confiança nos colegas. É importante verificar que, de facto, as alterações também foram bem implementadas.
  8. Managers deverão cultivar uma boa cultura de revisão de código, em que encontrar defeitos é visto como algo positivo.
    • É necessário evitar a cultura de “porque não escreveste bem à primeira?”. Interessa sim que não se encontrem bugs em produção. No desenvolvimento e no processo de revisão é onde se devem encontrá-los. É importante existir espaço para que um engenheiro possa errar. Só assim poderá aprender algo novo.
  9. Atenção ao efeito “Big Brother”.
    • Similar ao ponto 8, mas na perspectiva do engenheiro. É importante se ter noção de que as sugestões ou bugs reportados nas revisões de código são quantificáveis. Estes dados deverão servir aos managers para analisarem se o processo está a funcionar, se um engenheiro está com alguma dificuldade em particular, mas nunca deverão ser utilizados para avaliações de performance.
  10. O factor Ego: Fazer sempre alguma revisão do próprio código, mesmo que não tenham tempo para fazê-lo até ao final.
    • Saber que o nosso código vai ser revisto por terceiros alerta-nos para sermos mais cautelosos no que produzimos.
  11. As revisões de código feitas de forma “leve” são eficientes, práticas e eficazes em encontrar erros.
    • Não é necessário se entrar no procedimento descrito pela IBM há 30 atrás, onde 5-10 pessoas se fecham em reuniões periódicas com impressões de código e rabiscam a cada linha de código. Utilizando ferramentas como o Git, é possível se participar no processo de revisão de código, escrever comentários associados a linhas específicas, debater soluções através de mensagens assíncronas com o autor, etc.

Aconselho a lerem o documento para terem uma visão mais aprofundada de cada ponto.

Não é possível refutar que a revisão de código irá melhorar a qualidade do código produzido, diminuindo o número de bugs e melhorando o desenho. Existem algumas mais valias adicionais como a partilha de conhecimento entre colegas e a mentoria de elementos mais juniores da equipa.

É um facto que este processo, mesmo que feito de uma forma mais leve, consumirá tempo ao projecto. Ao processo de revisão, temos de adicionar o tempo de resposta do autor e novamente o tempo de nova revisão. Numa tentativa de agilizar este consumo de tempo, aconselho que, após duas tentativas de revisão sem sucesso, o autor e o revisor se sentem lado a lado e debatam o pedaço de código que está a causar o problema.

Mas é importante recordar uma frase que se encontra no site da IBM –  Slow down to go faster (abranda para ires mais rápido).

Gostaria de terminar com uma nota, que tenho como demasiado importante. O processo de revisão de código exige que toda a equipa de desenvolvimento demonstre uma elevada inteligência emocional. Regra geral os programadores têm um ego forte e sentem-se “pais” do código por si escritos. Por vezes não é fácil aceitar comentários menos construtivos. Comentário totalmente destrutivos, provocantes ou jocosos “farão mais mal que bem”, podendo mesmo destruir o espírito de uma equipa. É importante acompanhar esses elementos, tentar que modifiquem as suas atitudes ou, em último recurso, retirá-los da equipa.