Info+News+Tech

Muitas empresas têm um departamento de engenharia de software dedicado, seja para manter um site ou desenvolver aplicativos. A maioria desses departamentos realizará revisões de código como parte de sua rotina diária. Mas qual é a diferença entre uma experiência negativa e uma revisão construtiva?

O que é uma revisão de código?

A revisão de código é uma prática comum na engenharia de software que visa garantir que a qualidade de uma implementação seja mantida, tendo o trabalho do autor examinado por um ou mais revisores.

Por onde você deve começar uma revisão de código?

As revisões de código produtivas devem sempre começar com dois elementos:

– o ticket para a tarefa
– disponibilização de quaisquer arquivos de teste na solicitação

O tíquete incluirá uma visão geral do cenário e quaisquer informações adicionais necessárias para a revisão, como designs ou considerações não técnicas. Isso ajuda a entender o contexto por trás do trabalho.

Os arquivos de teste detalham os vários cenários e resultados que as mudanças funcionais esperam resolver e alcançar, dando ao revisor uma melhor compreensão do problema e da solução proposta.

Ao revisar os arquivos de teste (e posteriormente o próprio código funcional), é essencial considerar quaisquer casos extremos que possam ter sido negligenciados. Esses casos extremos podem parecer insignificantes, mas podem resultar na interrupção do serviço devido a um comportamento inesperado.

Em seguida, o revisor deve voltar sua atenção para os arquivos com mais alterações. Esses arquivos provavelmente são o núcleo da implementação e, portanto, economizam tempo durante a revisão.

Como você deve conduzir a revisão do código?

Uma revisão de código construtiva costuma ser difícil de conseguir. As equipes e os indivíduos geralmente identificam apenas os problemas com a solicitação de mudança. Alguns até resolverão depois de identificar um problema potencial. A armadilha que muitos esquecem é que uma revisão é uma avaliação dos pontos fortes e fracos. Poucos revisores elogiam os aspectos positivos de uma implementação, mesmo quando uma solução é elegante ou quando casos extremos são resolvidos.

Conforme mencionado acima, alguns revisores identificarão um problema e procederão à solução. A solução é responsabilidade do autor da mudança e não do revisor.

Revisores que solucionam desperdiçam tempo quando ele poderia ser gasto em outros problemas, ao mesmo tempo em que desmotivam o autor.


Muitos engenheiros de software investem na resolução de problemas de seu trabalho e preferem fazer isso sozinhos.

E as coisas mais delicadas?

O revisor também deve evitar exigir que mudanças triviais sejam feitas antes de aprovar o trabalho.

Identificar problemas como erros de ortografia, nomenclatura inadequada e micro-otimizações são úteis, pois afetam a qualidade do código.

No entanto, preocupações como essas devem ser observadas e corrigidas em uma alteração de acompanhamento – o objetivo de uma solicitação de alteração é melhorar o produto geral e a base de código , portanto, não precisa necessariamente ser perfeito na primeira iteração.

Ao revisar uma solicitação de mudança, preste atenção aos detalhes mais sutis, como caminhos de arquivo e nomes referenciados no código. Eles são facilmente esquecidos, especialmente durante a refatoração, mas irão interromper o recurso se não estiverem corretos. Da mesma forma, com quaisquer recursos ou arquivos referenciados, confirme se eles estão na alteração.

Quando você deve fazer a revisão?

Muitos engenheiros relutam em realizar revisões de código devido à necessidade de alternar o contexto.

Para evitar a troca desnecessária de contexto, conduza revisões de código antes ou depois de outra troca de contexto inevitável, como um intervalo ou reunião. Isso fornece ao revisor uma escolha de horários regulares, mas flexíveis, para conduzir as revisões. Apesar do foco na flexibilidade, as revisões de código não devem ficar estagnadas por mais de um dia. É fácil que várias revisões se acumulem e comecem a bloquear outros engenheiros ou tíquetes.

A velocidade da equipe é mais importante do que a velocidade do indivíduo.

*Artigo escrito pelo Engenheiro de Software Kyle Jones.

Encontre aqui vagas em tecnologia.

Deixe uma resposta

Info.CEVIU