Vocês praticam inspeção de código?

Se eu tivesse que dar uma palestra sobre qualidade de código e pudesse escolher apenas um tema, escolheria inspeção de código. Esta é uma das melhores técnicas para reduzir a quantidade de bugs no software, mas infelizmente é muito pouco utilizada pelas empresas. Isso porque parar um desenvolvedor por algumas horas para simplesmente “olhar o código de outro” parece uma perda de tempo muito grande para a maioria das empresas.

Se você também pensa assim, espero que tenha paciência de ler este post até o fim. Provavelmente mudará de ideia.

Para começar, vou colocar aqui dados de algumas empresas de porte razoável sobre o assunto:

• Um defeito é encontrado a cada 4h de teste, contra 4,4 defeitos que são encontrados durante 1h de revisão (Hewlett-Packard);
• Inspeções são 20x mais rápidas que testes (Russell);
• 82% dos problemas são resolvidos antes de testar (IBM);
• 1 defeito é encontrado a cada 3 minutos de inspeção (Shell);
• Custo de manutenção dos códigos inspecionados é 1/10 do custo dos códigos não-inspecionados (Imperial Chemical).

Interessante, não?

A seguinte tabela foi extraída com base nos livros Software Defect-Removal Efficiency (Jones, 1996) e What we have learned about Fighting Defects (Shull 2002). Ela indica qual é, em média, a porcentagem de defeitos removidos utilizando cada uma das seguintes técnicas comuns de qualidade:

Técnica para encontrar defeitos	Qtde de Defeitos
Inspeções de design informais	35,00%
Inspeções de design formais	55,00%
Inspeções de código informais	25,00%
Inspeções de código formais	60,00%
Prototipação	65,00%
Unit-tests	30,00%
Testes de integração	35,00%
Testes de Regressão	25,00%
Testes do sistema	40,00%
Testes Beta (com menos de 10 usuários)	35,00%
Testes Beta (mais de mil usuários)	75,00%

Note que apenas a prototipação e os testes beta de alto volume encontram mais problemas do que a revisão de código.

Muitas empresas tentam aumentar a qualidade dos produtos aumentando a quantidade de testes do sistema. Isso é a mesma coisa que se pesar com mais frequência para ver se diminui o peso.

Não estou dizendo que os testes devem ser substituídos pelas revisões de código, mas sim que as duas técnicas devem ser utilizadas em conjunto.

Muito bonito na teoria, mas a minha equipe é pequena e não temos condições de parar desenvolvedores para fazer revisão de código!

Será?

Uma pesquisa mostra que a média de linhas de código desenvolvida por cada programador em um projeto de software é de 10 a 50 LOCs por dia. Isso parece absurdo em um primeiro momento, considerando que é possível escrever esta quantidade de linhas em poucos minutos, mas é preciso considerar também o tempo que os desenvolvedores perdem debugando, testando, tentando entender o código e corrigindo defeitos. Quantas vezes você já não passou um dia inteiro e não escreveu uma linha sequer?

O fato de você realizar uma inspeção de código irá diminuir a quantidade de defeitos no produto, aumentando a qualidade e diminuindo o tempo de manutenção. Assim, com esta prática, é possível entregar um produto de maior qualidade em um tempo igual ou menor de desenvolvimento.

Isso se prova com dados de campo: um estudo realizado pelo Laboratório de Engenharia de Software da NASA sobre 50 projetos indicou que, na média, os projetos com menos defeitos por linha de código tiveram um tempo de desenvolvimento menor do que os com maiores índices de defeito, porém com um custo igual (Code Complete, McConnell, 2004).

Outras opiniões?

• A IBM revelou que cada hora investida em inspeção de código previne cerca de 100 horas de trabalho em testes e correções de defeitos;
• Raytheon reduziu o custo de correções de defeitos de 40% do custo total do projeto para 20% através de uma iniciativa de inspeções (Haley 1996);
• a HP reportou que seu programa de inspeção economiza em média 22 milhões de dólares por ano (Grady e Van Slack, 1994);
• 11 programas foram desenvolvidos pela mesma equipe de desenvolvimento. 5 deles foram desenvolvidos sem utilizar revisão de código e tiveram uma média de 4,5 erros por 100 linhas de código. Os outros 6 foram inspecionados e e tiveram uma média de 0,82 erros por 100 linhas de código (Freedman e Weinberg, 1990).

Além disso, outra vantagem da revisão de código é a troca de conhecimento entre a equipe. Tanto quem desenvolveu quanto quem está revisando o código podem aprender bastante com o processo.

Mas que maravilha! E então, como é o processo de revisão de código?

Várias técnicas de revisão de código podem ser aplicadas. Atualmente, um dos modelos de desenvolvimento ágil mais conhecidos, o eXtreme Programming, utiliza o pair programming, que é um tipo de inspeção de código on-the-fly.

Vou explicar aqui um processo formal de revisão. Você pode adaptá-lo conforme a sua necessidade, porém não recomendaria grandes mudanças se sua empresa ainda não está habituada com a prática.

Processo de Revisão

Antes de explicar o processo, gostaria de ressaltar duas coisas:

• Para sistemas simples, uma pessoa consegue revisar de 400 a 500 linhas de código por hora. Para sistemas críticos, complexos ou embarcados, esta média cai para cerca de 150 linhas por hora (nestas linhas não consideramos comentários ou linhas em branco);
• Um revisor aguenta revisar um código por, no máximo, 2h seguidas.

Dito isso, vamos às pessoas envolvidas no processo:

Moderador: É o responsável por fazer o processo andar. Ele deve mover a revisão a uma velocidade que seja rápida o suficiente para ser produtiva, porém não tão rápida a ponto de que os defeitos não sejam encontrados. Também é o responsável por organizar as reuniões e definir quem deve revisar o quê.

Autor: A pessoa que desenvolveu o código. Participa das reuniões e deve ser o responsável por posteriormente aplicar as correções.

Revisor: É a pessoa que irá revisar o código (ou o design, se for o caso). Se for fazer revisão de código, deve ser um programador qualificado, de preferência que esteja envolvido com o processo, mas, obviamente, que NÃO seja o autor!

Escrituário (tá, foi a melhor tradução que eu encontrei para scribe!): pessoa responsável por escrever um relatório com os problemas encontrados durante a reunião. Esta pessoa pode ser o próprio revisor, mas é comum utilizar outra pessoa para liberar o revisor para suas outras atividades. É uma prática comum utilizar estagiários para este fim, com o intuito de que eles, desta forma, adquiram conhecimento e experiência (ok, as empresas utilizam estagiários porque são mais baratos do que os desenvolvedores, mas eu não queria chegar neste ponto...).

Não é comum que gerentes participem das revisões de código, pois isso pode constranger os outros participantes, principalmente se o gerente da equipe for um idiota (se você é gerente, você deve saber se a sua equipe te considera um idiota ou não). Os gerentes podem e devem acompanhar os resultados da revisão, mas não devem acompanhar o processo para que o foco da prática não passe de técnico para político.

As fases da revisão são:

Planejamento: O autor entrega o código (ou seja lá o que for ser revisado) para o moderador. Este decide quem deve realizar a revisão e quando. Dependendo da quantidade de trabalho, é até aconselhável que mais de um revisor seja convocado.

O moderador deve imprimir o código e reunir quaisquer outros documentos que considere importante.

Overview: Quando os revisores não são familiarizados com o projeto, é possível marcar uma reunião com os revisores e o autor, para que este dê uma visão geral do código que eles irão revisar. Esta reunião deve durar no máximo 1h, mas deve ser evitada se possível.

Preparação: Cada revisor trabalha sozinho eu seu código ou modelo que estiver revisano. É interessante que a empresa possua um checklist para facilitar o trabalho, ainda mais se a empresa segue um padrão de desenvolvimento.

Os revisores devem estar cientes das duas coisas que ressaltei no começo do tópico (quantidade de linhas para revisar por hora e tempo máximo que deve durar uma revisão).

Reunião de Inspeção: Nesta reunião, o moderador escolhe alguém (além do autor) para ler o código e explicá-lo. É interessante que o código esteja projetado na parede ou em um quadro, para que todos possam vê-lo. Assim que o código é passado, os erros encontrados são levantados e discutidos com a equipe. O escrituário é responsável por registrá-los. O moderador é responsável por manter a reunião produtiva e evitar que a equipe comece a discutir assuntos irrelevantes à revisão.

Esta reunião não deve durar mais do que duas horas.

Relatório de Inspeção: Um relatório com os problemas encontrados deve ser formalizado e enviado para todos os participantes. O relatório deve conter a lista dos defeitos e a severidade de cada um. Este relatório pode ser um documento de texto enviado para todos por e-mail ou um registro formal em algum bugtracker, não importa.

Retrabalho: O moderador distribui os defeitos encontrados para a equipe. Em geral o autor é responsável por corrigi-los, mas não necessariamente.

Follow-up: O moderador é responsável por acompanhar o andamento da correção dos defeitos encontrados. Dependendo da quantidade e da complexidade dos defeitos encontrados, um novo processo de revisão pode ser necessário na sequência.

É isso pessoal. Uma coisa que se deve ter em mente é que a revisão de código é apenas um processo de qualidade de software, assim como os testes do sistema, e NÃO deve ser utilizado para outros fins além deste. Um erro comum que leva o processo ao fracasso é utilizar o resultado das revisões para julgar ou humilhar o autor. Ou seja, dar um chapéu de burro porque alguém cometeu um erro besta é mais besta ainda.

Espero que tenha convencido vocês da importância deste processo, e boa revisão para todos!