Revisão de código por meio de solicitações de mesclagem do GitLab

Neste artigo, nos concentramos em como melhorar o fluxo de trabalho com revisões de código por meio de solicitações de mesclagem do GitLab. Também falamos sobre as melhores práticas de revisão de código que seguimos na Codificar.
Antes de começarmos a fazer uma revisão de código, vamos descobrir o que pode acontecer se você ignorar essa etapa importante.

Desenvolvedores na equipe

Os projetos nos quais nossa empresa trabalha geralmente exigem de um a três desenvolvedores por plataforma. E quase qualquer equipe de desenvolvimento inclui pessoas com diferentes níveis de especialização (os desenvolvedores geralmente são classificados como júnior, médio e sênior).
No entanto, independentemente do seu nível, todos os programadores escrevem software de forma diferente. Especialmente desenvolvedores de aplicativos móveis, que tendem a ser criativos.
Portanto, às vezes pode ser difícil para os desenvolvedores descobrir o código escrito por seus colegas. Esse problema também pode ser decorrente de falta de conhecimento, sono, café ou excesso de criatividade.
Então, como podemos ter certeza de que os desenvolvedores podem ler o código uns dos outros? A revisão do código-fonte é um bom ponto de partida!

Por que revisar o código?

Muitos desenvolvedores escrevem código como se fossem os únicos que precisariam entendê-lo. Isso não é um problema se um desenvolvedor estiver construindo um produto por conta própria.
Mas esse mundo de solidão pacífica não existe. A realidade é que os desenvolvedores precisam pensar em quem vai assumir seu trabalho. Eles também precisam pensar nos clientes, que terão de gastar dinheiro e tempo desvendando os mistérios ocultos em linhas de código pouco claras. Aqui estão alguns motivos para fazer uma revisão de código:

Nenhum membro de uma equipe tem uma visão completa de todo o código que um projeto contém, visto que é escrito por pessoas diferentes.
Algumas partes do código em qualquer projeto só serão vistas pelo autor, não importa o quanto os outros tentem.
O código de má qualidade provavelmente permanecerá nessa condição por muito tempo, se não para sempre.
Ninguém é responsável pelo código dos outros – e às vezes nem mesmo pelo seu próprio.
Os membros da equipe acham difícil ganhar experiência e melhorar as habilidades de codificação.
O código ruim se torna uma dor no pescoço na fase de teste.
Acumula código inválido. Mais cedo ou mais tarde, isso levará a muitas dificuldades na tentativa de detectar problemas e corrigi-los.
Quando um novo desenvolvedor se junta a um projeto, seu código pode representar o maior perigo que seu software já enfrentou.
Pode ser muito complicado refatorar após três meses de produção de código fora de controle e que vive sua própria vida.

Como você pode ver, as perspectivas não são as mais agradáveis se você deixar de fazer uma revisão do código. Mas uma revisão de código sozinha não pode garantir a qualidade do código. Em primeiro lugar, o código deve passar pela fase de teste.

Teste para melhorar a qualidade do código

A revisão de código não pode substituir a cobertura de teste completa e melhorar completamente a qualidade do código. Antes de fazer uma revisão de código, o novo código deve ter cobertura de teste suficiente. A cada push, os pipelines do GitLab realizam testes e verificações de qualidade do código para que um desenvolvedor possa corrigir os problemas.
Embora as revisões de código possam, às vezes, ajudar na localização de bugs, elas não são a ferramenta principal para esse propósito. Uma coleção robusta de testes de unidade, funcionais e de integração, bem como ferramentas de qualidade de código, atenderá efetivamente a esse propósito.
Mas sempre há a possibilidade de um bug não ser detectado por nenhum teste, e é aí que as revisões de código são críticas. Testes insuficientes também podem produzir incerteza sobre a lógica de negócios do código (se ele atende aos requisitos iniciais). E é aqui que entrará um bom revisor de código.
À medida que o código está sendo escrito, a prioridade é garantir que todos os testes sejam automatizados e executados explicitamente quando o novo código for enviado. Um revisor de código vê quando o GitLab concluiu o teste de uma nova parte do código e quando o código está compilando.
Os resultados dos testes automatizados são claramente visíveis para os desenvolvedores. Passar no pipeline de teste é uma etapa obrigatória antes da mesclagem.

Princípios gerais de revisão de código

A revisão do código é parte integrante de qualquer processo de desenvolvimento.
A revisão do código é realizada em pequenos pedaços de código logicamente completos, como um recurso, tarefa, correção de bug ou melhoria.
Apenas o código que passou na revisão é enviado para teste.
Todos os desenvolvedores do projeto participam da revisão do código, independentemente de seu nível (os desenvolvedores juniores também devem revisar o código dos especialistas médios e sênior).
O código de todos os desenvolvedores deve ser revisado, independentemente do nível do desenvolvedor.

Agora estamos chegando às ferramentas que o GitLab oferece para revisão de código.

Solicitação de mesclagem do GitLab como ferramenta para revisão de código

Uma solicitação de mesclagem serve para mesclar código de uma ramificação para outra. Os principais parâmetros de solicitação de mesclagem (especificados ao criar uma solicitação de mesclagem) são:

ramo de origem
ramo alvo
título
descrição
cessionário

Curso de ações ao trabalhar com solicitações de mesclagem

Escreva o código e envie-o para um branch separado.
Crie uma solicitação de mesclagem para o ramo principal de desenvolvimento. O cessionário e os mencionados no campo de descrição e nos comentários serão notificados por e-mail sobre a solicitação de mesclagem criada. Para mencionar um desenvolvedor, insira o símbolo @ no campo de descrição.
Aguarde até que sua solicitação seja aceita ou recusada com comentários sobre as correções necessárias.
Participe de discussões sobre correções. (GitLab permite que você responda aos comentários.)
Faça correções.
Envie alterações para o seu ramo.
Abra uma nova solicitação de mesclagem se a última foi fechada. Se a solicitação de mesclagem não foi fechada, ela será atualizada automaticamente até o último commit no push.
Relate as correções implementadas comentando sobre a solicitação de mesclagem ou de alguma outra forma (por messenger ou diretamente).

Erro 500. O que fazer quando uma solicitação de mesclagem GitLab não funciona

O GitLab pode retornar o erro 500 quando um desenvolvedor tenta criar uma solicitação de mesclagem. Isso significa que o servidor GitLab não está configurado corretamente. Para resolver esse problema, você precisará da ajuda do administrador do sistema ou de alguém que desempenhe a função de administrador do sistema em sua equipe de desenvolvimento.
Pode haver muitos motivos diferentes para o erro 500, e não há uma solução universal para esse problema. No entanto, na maioria dos casos, você pode resolver esse problema de uma das duas maneiras (ou tentando as duas):
1) Defina um valor maior do que o padrão para parâmetros como max_size e tempo limite. O parâmetro max_size define o tamanho máximo de um repositório GitLab. O tempo limite é o tempo de resposta. Se durante esse intervalo os dados não forem retornados, você obterá o Erro 500. O tempo limite também é o tempo máximo para concluir uma solicitação de mesclagem.
Como resolvemos esse problema:

grep cryptspirit config/* -r
config/gitlab.yml:    max_size: 104857600 # 100.megabytes cryptspirit
config/gitlab.yml:    timeout: 20 # cryptspirit

2) Exclua o repositório de satélites GitLab e inicie-os novamente.
Limpar ->

rm -rf /home/git/gitlab-satellites/{repo}

Gerar novamente ->
O último comando deve ser executado no diretório GitLab com o gemset configurado. Espero que isto ajude!

A quem uma solicitação de mesclagem deve ser atribuída

A atribuição de solicitações de mesclagem depende de vários fatores. Pode haver diferentes opções dependendo do número de pessoas no projeto e seu nível de especialização. Se você for o único desenvolvedor da equipe, atribua uma solicitação de mesclagem a si mesmo. Afinal, você pode encontrar bugs em seu próprio código se tentar. Quem busca sempre encontrará!
Caso contrário, converse com outro desenvolvedor que também esteja sozinho e ofereça-se para revisar o código um do outro. A revisão da documentação também é freqüentemente necessária para garantir que outros desenvolvedores possam trabalhar com o seu código.
Se houver dois desenvolvedores no projeto, atribua solicitações de mesclagem um ao outro. Se houver três ou mais desenvolvedores, você é livre para escolher:

Atribuir solicitações de mesclagem uma a outra
Encontre quaisquer dois desenvolvedores que adorem solicitações de mesclagem e atribua todas as solicitações a eles
Atribua todas as solicitações a um desenvolvedor e faça uma revisão de código uma vez por dia com todos os membros da equipe
Qualquer outra opção

Você pode fazer uma revisão do código no início e no final do dia de trabalho ou a qualquer momento mediante solicitação. A equipe pode decidir quando é um bom momento para fazer uma revisão do código. O mais importante é garantir uma colaboração contínua dentro da equipe. Como você faz uma revisão de código depende diretamente das práticas que sua empresa segue.

Se você fizer uma revisão contínua do código, certifique-se de que:

Problemas no código são detectados e corrigidos imediatamente
Cada membro da equipe, não apenas o autor do código, é responsável por sua qualidade
O compartilhamento de conhecimento acontece de forma rápida e eficaz
Desenvolvedores juniores aprendem rápido
Apenas um bom código vai para teste
Código ruim não se acumula
O código de um novo desenvolvedor não ameaça a qualidade geral do código
Os desenvolvedores conhecem bem não apenas seu próprio código, mas o código de todo o projeto
O produto final é de alta qualidade

Algumas empresas usam um aplicativo de revisão de código e ferramentas de revisão, mas observe que os aplicativos de revisão de código têm suas limitações.
Para mais conteúdos sobre programação e desenvolvimento de aplicativos, continue acompanhando o blog da Codificar.
Preencha o formulário e vamos falar sobre o seu projeto de aplicativo.

code review, programação