A revisão do código (da revisão do código em inglês ) é um exame sistemático do código-fonte do software.
Pode ser comparado ao processo que ocorre em um comitê de revisão , com o objetivo de encontrar bugs ou vulnerabilidades potenciais ou corrigir erros de design a fim de melhorar a qualidade, manutenção e segurança do software.
Uma revisão de código pode ser baseada na verificação (manual ou automatizada) de conformidade com um conjunto de regras de programação.
Se a revisão do código há muito é reconhecida como uma maneira poderosa de melhorar a qualidade do software, as organizações que implementaram uma abordagem sistemática há muito tempo são minoria. É cada vez mais uma etapa completa em qualquer processo de desenvolvimento de software, especialmente em métodos ágeis como a programação extrema .
A Hewlett-Packard avalia o retorno sobre o investimento de uma revisão de código em 10 para 1.
A revisão é aproximadamente 2 a 4 vezes mais rápida do que o teste e oferece uma melhor taxa de detecção de defeitos: testes de unidade 25%, testes de integração 45%, revisão de design 55%, revisão de código 60%.
Mas a revisão não detecta as mesmas falhas do teste.
A revisão do código pode assumir diferentes formas, mais ou menos formais. O modelo mais adequado deve ser escolhido com base na tolerância ao risco do código auditado.
Michael Fagan, um executivo da IBM, formalizou em 1976 um método de inspeção de código que se baseia na convocação de várias reuniões de auditoria. Bastante pesado, requer em média nove horas- homem para 200 linhas de código, é difícil de sistematizar para todo o código.
Tom Gilb e Dorothy Graham desenvolveram outro método de inspeção bastante popular também.
O sistema de gerenciamento de versão pode ser configurado para enviar um e-mail descrevendo cada uma das modificações feitas na árvore de origem. Os outros desenvolvedores da equipe têm a oportunidade de revisar essas mudanças.
Este método apresenta problemas de garantia de qualidade : como saber se uma modificação foi revista, se as críticas foram levadas em consideração ...
A revisão indireta é um método informal: o autor do código conduz a revisão apresentando ao revisor as alterações que ele fez no código-fonte.
Tem a vantagem de ser simples e rápido de executar. Uma de suas desvantagens é que, como o autor é o piloto da revisão, pode haver um efeito colateral ausente que ele não percebeu no momento da redação.
A eficácia comparativa da programação em pares com outros métodos de revisão de código permanece uma questão um tanto controversa. É por exemplo possível que o par não tenha distância suficiente no código.
Há software disponível para auxiliar na revisão do código:
Algum software livre:
A análise estática do programa é o uso de ferramentas como o lint e seus sucessores para verificar a conformidade com um conjunto de regras de programação . A análise estática permite automatizar (sistematizar) certos controles (complexidade do código, conformidade com as regras de codificação, etc.), mas não permite a verificação de certos pontos mais abstratos (reutilização, eficiência, cumprimento das especificações, etc.) que exigem revisão manual.
A análise estática e a revisão por pares são, portanto, complementares, possibilitando estender a revisão de código qualitativa e quantitativamente. A ferramenta de análise estática permite, em particular, descarregar verificações de detalhes e promove uma visão mais global do sistema estudado durante a revisão do código.
Uma lista de verificação é um documento que resume os pontos a serem verificados como prioridade durante a revisão do código.
Uma lista de verificação não deve conter mais de dez itens, o limite do que um ser humano normal pode memorizar. Portanto, é necessário:
Os itens devem dizer respeito apenas a coisas que muitas vezes são esquecidas: por exemplo "verifique se o método libera adequadamente os recursos para todos os casos de retorno de erro". Para fazer isso, podemos analisar as últimas 100 ou 200 correções de bugs para encontrar as causas mais frequentes de erros e transformá-las em itens da lista de verificação.
Será então interessante classificar os novos bugs por itens da lista de verificação (não esquecendo a categoria "nenhum desses itens"). Quando um item da lista de verificação dificilmente contiver mais bugs (porque terá surgido uma estratégia para evitar esse problema), será hora de substituir este item pela causa de erro mais frequente na categoria "nenhuma das anteriores. Itens ".
A auto-leitura ou revisão de código pessoal consiste em um desenvolvedor usar métodos de revisão de código (em particular uma lista de verificação) em sua produção de software para detectar e corrigir defeitos.
Um estudo realizado na Cisco mostrou que as revisões preparadas pelo autor (anotação das modificações feitas no código-fonte) retornaram muito menos defeitos. Duas hipóteses foram apresentadas:
Este estudo indica o favorecimento da hipótese otimista.
A integração contínua pode sistematizar uma etapa de análise estática e / ou revisão por pares para qualquer novo código embutido.
A equipe deve desenvolver uma cultura de compartilhamento do código-fonte, incentivando discussões sobre o código. As pessoas relutam em dedicar um tempo para entender como o código complexo funciona, portanto, o feedback será muito geral neste caso.
É difícil para um funcionário dizer ao chefe que um de seus colegas fez um péssimo trabalho. A administração deve, portanto, desenvolver um clima favorável à detecção de falhas: os bugs são um processo normal, não uma falha individual. É importante não se sentir culpado, mas se concentrar, por exemplo, no trabalho em equipe: o que importa é a qualidade final do software.
Os desenvolvedores devem aprender a dominar seus egos, distinguir entre crítica de código e crítica pessoal. Você tem que levar em consideração as pessoas que não querem mostrar seu trabalho.
A administração também deve estar convencida do valor de alocar recursos para a revisão.
As métricas são usadas para medir a eficácia da revisão.
Possíveis métricas:
Isso permite calcular, por exemplo, a densidade do defeito por linha de código, a velocidade média de inspeção de uma linha de código ou o tempo para descobrir um defeito.
A medição em grande escala na Cisco mostrou que: