Autor: leomachadop | Afiliação: Mackenzie | Email: leomachadop@gmail.com | Data: 06/2016

Revisão de código é o nome dado à prática de um membro da equipe verificar e revisar o código escrito por outro membro. Diante desse cenário, podemos fazer as seguintes perguntas:

• Será que os profissionais gostam de realizar as revisões?
• Eles acreditam que isso possa fazer diferença em seu ambiente de trabalho?
• Segmentos diferentes na tecnologia da informação influenciam a forma como a revisão é realizada?
• A experiência muda a forma como os profissionais realizam a revisão?

Considerando essas perguntas, o trabalho tem como objetivo avaliar se a prática da revisão de código pode ajudar no desenvolvimento de software dentro das empresas, por meio de um questionário elaborado e aplicado utilizando as afirmações encontradas na literatura.

1. Introdução

Equipes de desenvolvimento de software estão constantemente guiadas por diversos desafios em seu cotidiano. Tarefas complexas por si só consomem muito esforço e, mesmo assim, após a conclusão, podem resultar em falhas ou problemas que não são encontrados no momento do desenvolvimento, mesmo com testes unitários. Independentemente do projeto, a qualidade do software deve ser prezada a todo momento, desde o levantamento dos requisitos até a implantação do sistema.

De acordo com CZERWONKA et al. (2015), existem diversas razões para que a revisão de código seja utilizada no contexto de engenharia de software, dentre elas destacam-se:

• Encontrar defeitos;
• Garantir a manutenção do código a longo prazo;
• Ferramenta de difusão de conhecimento;
• Transmitir progresso contínuo.

ANICHE (2013) afirma que a revisão de código tem se mostrado muito eficiente quanto à passagem de conhecimento para os integrantes da equipe. Quando o revisor analisa o código produzido, quem está sendo revisado argumenta o motivo que o levou a fazer daquela forma e porque utilizou determinada ferramenta, o que contribui muito para o profissional e para o time como um todo.

FAGAN (1976) propôs a ideia da revisão de código formal, também chamada de inspeção de código, que se difundiu rapidamente. No modelo proposto, as pessoas possuem papéis específicos e devem possuir as seguintes funções:

• Moderador: Considerada a pessoa chave, não necessariamente deveria ser técnico ou especialista no software que está sendo inspecionado, ajudando na objetividade da inspeção. Deve ter liderança sobre a equipe que está realizando a inspeção;
• Designer: Responsável pela concepção do programa;
• Programador: Responsável por traduzir o design em código;
• Tester: Programador responsável por realizar os casos de testes ou outra forma de testar o produto do designer/codificador.

Dentro do modelo proposto por FAGAN (1976), ao final da revisão, o moderador deve produzir um relatório com tudo que foi discutido e falado na inspeção para garantir que todas as questões levantadas na inspeção sejam abordadas no retrabalho.

FAGAN (1976) afirma que a equipe ideal para revisão de código é composta por 4 pessoas, embora isso possa variar de acordo com as circunstâncias. Caso o código pertença a mais de um programador, os envolvidos podem realizar a inspeção de código. As inspeções devem ser agendadas e gerenciadas com a mesma atenção que outras partes do projeto, caso contrário, poderão ser adiadas ou até mesmo evitadas. O resultado disso a curto prazo tem efeito negativo, e o adiamento repetido pode alongar o cronograma geral e aumentar o custo do projeto.

CZERWONKA (2015) afirma que as inspeções foram concebidas como reuniões formais nas quais os participantes se preparam com antecedência. Ao contrário das inspeções formais, a revisão de código não exige que os participantes estejam no mesmo lugar nem em um horário fixo, facilitando a realização das revisões em equipes geograficamente distribuídas.

De acordo com BACCHELLI (2013), a revisão de código moderna é um processo mais informal do que o proposto por FAGAN (1976) e pode ser feita com o apoio de ferramentas, reuniões pessoais e verificação com o colaborador. COHEN et al. (2006) apresenta cinco formas de realizar a revisão de código:

• Formal inspections: Modelo proposto por FAGAN (1976);
• Over-the-shoulder: O autor que solicita a revisão mostra as alterações realizadas a um membro da equipe, que examina e discute o que foi feito. Se o revisor encontra algo errado, pode-se realizar a programação em pares para obter a melhor solução;
• E-mail pass-around reviews: O autor envia o código para as pessoas que ele gostaria que realizassem a revisão. Estes examinam os arquivos, fazem perguntas e discutem com o autor e outros as mudanças necessárias. Esta técnica pode gerar alta troca de e-mails e dificuldades na coleta de dados;
• Tool-Assisted reviews: Mecanismo moderno para realizar revisões de código com ferramentas especializadas que coletam, transmitem e exibem arquivos, comentários e defeitos, além de coletar métricas para maior visibilidade sobre os números obtidos;
• Pair Programming: Na metodologia ágil eXtreme Programming (XP), o código é produzido por duas pessoas, que revezam as atividades conforme determinado pela empresa ou pela dupla. Esse processo de verificação é importante para evitar erros no desenvolvimento e é uma forma de revisão de código.

COHEN et al. (2006) afirma que alguns grupos de programadores não utilizam a revisão de código devido a dois motivos:

• Ego;
• O trabalho de realizar a revisão de código.

Quanto ao ego, COHEN et al. (2006) afirma que, quando alguém está avaliando o código, quem está sendo avaliado pode ver o processo como construtivo ou uma crítica. Isso pode levar a duas classes de programadores: colaboradores que, quando confrontados com problemas, tentarão resolvê-los e veem a revisão de código como algo benéfico para o projeto; e isolacionistas, que continuarão tentando resolver problemas sozinhos, sem pedir ajuda. COHEN et al. (2006) também enfatiza que isso não é exclusivo de programadores, podendo ocorrer em uma escala maior de profissionais.

1.1 Objetivos

1.1.1 Objetivo Geral

O objetivo é verificar como os profissionais de TI aceitam o processo de revisão de código e avaliar como este processo ocorre.

1.1.2 Objetivos Específicos

Os objetivos específicos do projeto são os seguintes:

• Verificar se os profissionais realizam a revisão, e se sim, como realizam;
• Verificar se os profissionais acreditam que esta prática aumenta a qualidade do software;
• Verificar se os profissionais gostam de realizar a revisão ou se se opõem a esta prática;
• Aprimorar a forma como a revisão é realizada e como ela pode ser melhor aplicada de acordo com a empresa;
• Verificar como se sentem ao revisar o código e quando são revisados;
• Avaliar como a revisão de código pode auxiliar em um projeto de desenvolvimento de software.

1.2 Problemas da Pesquisa

De acordo com TERVONEN (1997), a dificuldade em realizar o controle da qualidade da inspeção está no fato de que se trata de um trabalho mental e não pode ser diretamente observado. Isso significa que é difícil utilizar métricas de controle para saber se o inspetor está realmente concentrado e avaliar quando o processo de inspeção está completo.

A realização da pesquisa dentro de ambientes corporativos é extremamente difícil, pois as empresas tratam seu código fonte e suas informações com sigilo. Funcionários muitas vezes são obrigados a assinar termos de segurança da informação que os impedem de falar sobre o projeto. Para este trabalho, seria interessante analisar o commit e comentários dos desenvolvedores, além de aplicar as validações de código feitas na pesquisa de ANICHE (2013). Portanto, a pesquisa será feita na forma de questionário com total sigilo dos dados pessoais.

1.3 Justificativa

A pesquisa deve ser realizada para que empresas da área de TI, independentemente do processo de desenvolvimento de software, analisem e verifiquem os níveis em que os profissionais podem ser melhores para revisar o código e ser revisado. Também poderão ser obtidos resultados sobre como os profissionais preferem que a revisão seja realizada.

Com os resultados obtidos, as empresas poderão verificar se a prática da revisão de código é adequada em seu processo de desenvolvimento de software e a forma como deve ocorrer. Entre os benefícios, podemos citar e mensurar quando o profissional pode se sentir incomodado com esta prática, o que pode gerar problemas dentro do time. A pesquisa tem como objetivo auxiliar as empresas no que diz respeito ao bem-estar do time.

A grande contribuição que a pesquisa poderá oferecer é verificar se os profissionais realmente acreditam que a qualidade do software aumenta com esta prática, ou se ela pode não ajudar durante o desenvolvimento, de acordo com o nível de qualificação. Podemos partir do pressuposto que a qualidade, conforme apresentado por ANICHE (2013) e BACCHELLI (2013), realmente é elevada, porém esta pesquisa tem a intenção de mostrar se os profissionais acreditam que esta prática pode ser incorporada ao seu dia a dia sem gerar problemas no time.

O trabalho trará soluções sobre como realizar a revisão de código, quais as formas de realizá-la e quais contribuições podem ser obtidas quando adotada, analisando os resultados da pesquisa de campo que será realizada.

2. Revisão da Literatura

Conforme mencionado por COHEN et al. (2006), a revisão de código pode afetar o lado pessoal dos programadores, pois muitos não se sentem à vontade quando seu código é revisado. O autor propõe que, em cenários onde há mudanças constantes nos requisitos, os métodos ágeis são preferíveis aos tradicionais, como o modelo Cascata. Além disso, COHEN et al. (2006) destaca que a revisão de código é uma forma importante de manter a qualidade do código e que deve ser realizada antes que o código entre no ambiente do cliente, para minimizar impactos. Entre os benefícios diretos citados estão:

• Melhoria da qualidade do código;
• Redução de defeitos de código;
• Melhoria da comunicação sobre o conteúdo do código;
• Educação de programadores júnior.

Benefícios indiretos incluem:

• Ciclos mais curtos de desenvolvimento/teste;
• Impacto reduzido sobre o suporte técnico;
• Maior satisfação do cliente;
• Código mais sustentável.

COHEN et al. (2006) também apresenta os efeitos sociais da revisão de código, apontando duas formas que podem afetar negativamente o ambiente social da equipe de desenvolvimento:

• Ferir os sentimentos: Críticas podem ser mal recebidas e provocar reações negativas, especialmente se o assunto for complexo;
• Efeito "Big Brother": Quando softwares monitoram as atividades do desenvolvedor e medem automaticamente os comentários.

CZERWONKA (2015) afirma que a revisão de código:

• Muitas vezes não encontra problemas de funcionalidade que devem bloquear uma submissão de código;
• Deve ser realizada por pessoas com um conjunto específico de habilidades;
• O aspecto social das revisões de código não pode ser ignorado.

CZERWONKA (2015), com base em dados obtidos na Microsoft, constatou que 15% dos comentários fornecidos pelos revisores indicam um possível defeito, e menos de 15% representam defeitos impeditivos. 50% dos comentários são feedbacks gerais sobre o código, e 33% são considerados úteis pelos revisados. O estudo também revelou que desenvolvedores gastam, em média, seis horas por semana revisando o código dos colegas, o que pode ser caro e complexo. O autor conclui que talvez a revisão de código não esteja sendo realizada de maneira eficiente, o que está aumentando os custos. A pesquisa destaca que a revisão de código, para a Microsoft, é mais eficaz no treinamento da equipe do que na detecção de problemas de software.

No trabalho realizado por ANICHE (2013), foi feito um comparativo entre dois projetos da empresa Caelum para avaliar se a prática da revisão de código realmente auxilia na detecção de problemas. A pesquisa mostrou que, embora os números de defeitos não tenham mudado significativamente após a revisão, a disseminação de conhecimento e a percepção de aumento de qualidade foram notáveis. Este estudo destacou a importância do aspecto humano na percepção da qualidade, mesmo quando as métricas não comprovam um aumento significativo.

BACCHELLI (2013) discute que, nas décadas de 70 e 80, as revisões de código eram mais formais e demoradas. Atualmente, o processo é mais leve e menos formal, com maior foco na detecção de defeitos. A revisão de código moderna, com o uso de ferramentas como CodeFlow, permite anotações diretamente no código e interação com o desenvolvedor. A pesquisa indicou que os desenvolvedores esperam encontrar defeitos, manter a consistência da equipe, melhorar a qualidade do código e avaliar o design. A revisão também é vista como uma oportunidade de aprendizagem e transferência de conhecimento.

MANTYLA (2009) encontrou que 75% dos defeitos detectados na revisão de código não afetam visivelmente a funcionalidade do software, mas são importantes para a evolução do software. Defeitos que impedem a evolução do código também foram identificados, sendo mais valiosos em softwares com ciclos de vida mais longos.

BOEHM (2001) estima que 60% dos defeitos podem ser capturados durante a revisão de código e que identificar defeitos nas fases iniciais do desenvolvimento é mais econômico do que encontrá-los mais tarde. Fatores que influenciam a captura de defeitos incluem os tipos de revisão, o tamanho e a complexidade do sistema e a concorrência nos algoritmos.

SIY (2001) propõe que 75% dos defeitos encontrados durante as revisões de código são problemas de evolução que afetam o desenvolvimento futuro, em vez de erros em produção.

De acordo com TERVONEN (1997) inspeções são utilizados como técnicas de garantia de qualidade do software no início do processo de desenvolvimento do software, ou seja, bem antes de codificá – lo. O processo de desenvolvimento segue o seguinte processo:

Figura 1 Core de produção de software

TERVONEN (1997) descreve as fases principais de inspeção no início do desenvolvimento de software:

• Reunião inicial: Informar as expectativas e distribuir documentos, atribuir funções, e treinar em procedimentos de inspeção;
• Inspeção individual: Levantar o maior número de questões possível e registrar melhorias;
• Edição: Avaliar e classificar questões como defeitos ou não defeitos;
• Follow-up: O líder de inspeção analisa e solicita as alterações necessárias.

KEMERER (2009) investigou o impacto do design e revisão de código na qualidade do software e encontrou que defeitos identificados em fases iniciais são mais baratos de reparar. A inspeção é considerada a técnica mais eficaz, com regras como:

• Número ideal de inspetores: quatro;
• Taxa de preparação: 100 linhas por texto/hora;
• Taxa de avaliação: cerca de 125 linhas de código por hora;
• Reuniões de inspeção não devem durar mais de duas horas.

GILB (1994) sugere uma taxa de preparação de 0,5 a 1,5 páginas por hora e, para documentos críticos, 0,1 página por hora.

3. Resumo da Pesquisa e Resultados

O objetivo desta pesquisa foi avaliar a percepção dos profissionais de TI sobre a revisão de código e seu impacto no ambiente de trabalho. Para isso, um questionário com 15 perguntas foi elaborado e respondido por 16 profissionais de diferentes setores de TI. A pesquisa utilizou o Google Forms para facilitar a coleta e análise dos dados.

Os resultados foram apresentados em gráficos e incluíram informações sobre o tempo de experiência dos participantes, tipos de revisão de código que utilizaram, e sua percepção sobre os benefícios e desafios dessa prática. Os dados revelaram, por exemplo, que a maioria dos participantes considera a revisão de código valiosa para a qualidade do software e o aprendizado, e que a revisão frequentemente ajuda a evitar defeitos em produção.

Para detalhes completos e o questionário, acesse o trabalho original disponível no LinkedIn. Para mais informações ou esclarecimentos, entre em contato.

4. Conclusão e Trabalhos Futuros

Os resultados obtidos no questionário corroboram as pesquisas apresentadas na revisão bibliográfica, demonstrando a relevância da revisão de código em diversos ramos de atividade dos entrevistados. A análise sugere que a revisão de código é um aspecto essencial que deve ser continuamente avaliado e aplicado nas empresas.

A pesquisa envolveu 16 profissionais, dos quais 12 (75%) são experientes, com mais de cinco anos de experiência em TI, e 4 (25%) possuem menos de cinco anos de experiência. Esta composição enriquece a pesquisa, proporcionando uma visão equilibrada, ao avaliar tanto profissionais experientes quanto aqueles com menor tempo de prática na área.

Entre as práticas de revisão de código, a programação em pares foi a mais citada, com 75% dos entrevistados relatando que a utilizaram em suas carreiras. Esta prática é amplamente conhecida e adotada em empresas de TI. Em seguida, a prática de revisão "sobre o ombro" foi mencionada por 62,5% dos participantes, possivelmente por ser mais simples, já que o revisor é acionado no momento do commit para revisar o código, sem a necessidade de um processo em tempo real como na programação em pares.

Em relação aos valores associados à revisão de código, 93,8% dos entrevistados destacaram a importância do aumento da qualidade, corroborando o que a literatura aponta. O aumento da aprendizagem também foi mencionado, uma vez que o revisor entende a tecnologia para sugerir melhorias e, caso não compreenda, aprende com o revisado.

Quanto aos desafios diários, 62,5% dos entrevistados preferem tentar resolver problemas sozinhos antes de buscar ajuda, enquanto 37,5% solicitam ajuda para resolver problemas mais rapidamente. Considerando que 75% dos entrevistados possuem mais de cinco anos de experiência, podemos concluir que a maioria desses profissionais mais experientes tende a resolver problemas por conta própria.

Ao iniciar um novo projeto de software, 87,5% dos entrevistados preferem a revisão de código a ler documentos de especificação, indicando que o código é visto como uma forma mais direta e prática de entender o sistema e suas regras de negócios. Apenas 12,5% preferem a documentação formal.

No papel de revisor, 68,8% dos entrevistados sentem-se confortáveis em apontar problemas no código, embora 31,3% se sintam mais à vontade com pessoas próximas ou tenham dificuldades em comunicar problemas. Essa questão sugere que a revisão de código pode ser mais eficaz quando realizada em um ambiente confortável e conhecido. Alternativamente, o uso de e-mails para revisão pode ser uma solução para casos onde o contato pessoal não é ideal.

Como revisados, 68,8% estão dispostos a aprender com os problemas encontrados, e 31,3% dependem da forma como o revisor expõe os problemas. Nenhum dos entrevistados demonstrou resistência às críticas ou sugestões durante a revisão, o que é um sinal positivo para a aceitação do processo de revisão.

Quando questionados sobre recomendar a revisão de código em uma empresa que não a possui, 93,8% dos entrevistados responderam afirmativamente, enquanto 6,3% não recomendariam devido a experiências passadas negativas. Este dado indica uma forte aceitação da revisão de código como uma prática benéfica.

Sobre o aprendizado de novas técnicas ou tecnologias, 50% dos entrevistados afirmaram que o aprendizado ocorre principalmente quando novas tecnologias são usadas em projetos, enquanto a familiaridade com tecnologias existentes leva apenas a aprimoramentos.

Referente à prevenção de defeitos em produção, 93,8% dos entrevistados acreditam que a revisão de código contribuiu para evitar defeitos, enquanto 6,3% afirmaram que tomam cuidado extra durante o commit. Esses números destacam a eficácia da revisão de código na prevenção de problemas em produção.

No que diz respeito à motivação para realizar revisões de código, 75% dos entrevistados abordam o processo de forma neutra, apenas cumprindo um requisito, enquanto 25% demonstram empolgação. Isso sugere que, embora a maioria reconheça a importância da revisão de código, ela pode ser vista como um processo burocrático por alguns.

Sobre ferramentas automatizadas de revisão de código, 75% dos entrevistados não as utilizam, 18,8% usam e 6,3% desconhecem essas ferramentas. A falta de uso de ferramentas pode indicar uma oportunidade para otimizar o processo de revisão de código, reduzindo o tempo necessário para a análise preliminar.

A análise dos segmentos dos profissionais e suas experiências de revisão de código revela a variedade de práticas e opiniões, o que ajuda a entender como a revisão se encaixa em diferentes contextos de TI. Comentários dos participantes destacam a utilidade de técnicas como o e-mail para revisão, a importância de não alterar funcionalidades drasticamente durante a revisão, e a relevância da revisão para a aprendizagem e melhoria contínua.

Trabalhos futuros:

Os próximos passos para esta pesquisa incluem realizar testes práticos além dos questionários, como acompanhar o andamento das revisões de código de forma empírica. É importante manter a diversidade dos profissionais envolvidos e avaliar não apenas um projeto, mas vários projetos de diferentes empresas. Isso permitirá uma compreensão mais ampla dos efeitos práticos da revisão de código em diferentes contextos e com uma variedade maior de tecnologias e metodologias de desenvolvimento.

Referências

ANICHE, Maurício F.; SOKOL, Francisco Z. Efeitos da Prática de Revisão de Código na Caelum: Um Estudo Preliminar em Duas Equipes. 2014. Disponível em: http://www.aniche.com.br/wp-content/uploads/2013/04/wbma-final3.pdf. Acesso em: 23 jun. 2016.

BACCHELLI, Alberto; BIRD, Christian. Expectations, Outcomes, and Challenges of Modern Code Review. 2013. Acesso em: 20 jun. 2016. DOI: 978-1-4673-3076-3/13.

BOEHM, Barry; BASILI, Victor R. Top 10 List [Software Development]. 2001. Acesso em: jun. 2016. DOI: 10.1109/2.962984.

COHEN, Jason; BROWN, Eric; DURETTE, Brandon; TELEKI, Steven. Best Kept Secrets of Peer Code Review. Austin, TX: Smart Bear, 2006. Disponível em: http://smartbear.com/SmartBear/media/pdfs/best-kept-secrets-of-peer-code-review.pdf. Acesso em: 20 jun. 2016.

CZERWONKA, Jacek; GREILER, Michaela; TILFORD, Jack. Code Reviews Do Not Find Bugs: How the Current Code Review Best Practice Slows Us Down. 2015. Acesso em: 20 jun. 2016. DOI: 10.1109/ICSE.2015.131.

FAGAN, M. E. Design and Code Inspections to Reduce Errors in Program Development. Journal IBM Systems Journal, Riverton, NJ, USA, v. 38, n. 2-3, 1976. DOI: 10.1147/sj.382.0258.

FAN, C-F.; YIH, S. Prescriptive Metrics for Software Quality Assurance. 1994. Acesso em: jun. 2016. DOI: 10.1109/APSEC.1994.465237.

GILB, Tom; GRAHAM, Dorothy. Software Inspection. 1. ed. Wokingham, England: Addison-Wesley Professional, 1994.

KEMERER, Chris F.; PAULK, Mark C. The Impact of Design and Code Reviews on Software Quality: An Empirical Study Based on PSP Data. 2009. Acesso em: jun. 2016. DOI: 0098-5589/09/$25.00.

MANTYLA, Mika V.; LASSENIUS, Casper. What Types of Defects Are Really Discovered in Code Reviews?. 2009. Acesso em: jun. 2016. DOI: 0098-5589/09/$25.00.

TELES, Vinícius Manhães. Programação em Par. 2006. Disponível em: http://www.desenvolvimentoagil.com.br/xp/praticas/programacao_par. Acesso em: 23 maio 2016.

TERVONEN, Ilkka; IISAKKA, Juha. Monitoring Software Inspections with Prescriptive Metrics. 1997. Department of Information Processing Science, University of Oulu, Oulu, Finland.

SIY, Harvey; VOTTA, Lawrence. Does The Modern Code Inspection Have Value?. 2001. Acesso em: 20 jun. 2016. DOI: 10.1109/ICSM.2001.972741.