Em todas as minhas experiências profissionais até agora eu vi várias pessoas/times ignorando o significado por trás de um Pull Request (PR), tratando ele só como um tipo de burocracia para colocar o código em produção.

Algumas vezes escutei pessoas falando uma para outra: “Vou abrir um PR aqui, aceita ai que está tudo certo”. No final esse PR foi realmente aceito sem nenhum tipo de revisão e acabou quebrando todo o sistema, posso dizer que o revisor é tão culpado quanto o revisado porque nesse caso o revisor foi negligente!

Nós não conseguimos automatizar tudo, as pessoas pensam que por terem testes automatizados não precisam fazer mais nada para garantir a qualidade do código.

Está dentro de testes automatizados:

  • Testes unitários, testes de integração e etc.
  • Testes estáticos (linters)
  • Testes de Tipagem Estática (se você estiver usando uma linguagem com tipagem estática opcional, como Python)

Nos próximos tópicos, vou tentar explicar meu ponto de vista sobre código e sua qualidade no mundo profissional

O que é o código?

Todo projeto/codebase é um ativo da empresa.

O código que nós escrevemos não é nosso, ele pertence à empresa. Nós só estamos momentaneamente responsáveis por ele, talvez daqui algumas semanas o projeto vá para outro time, e outro projeto pode vir para nosso time também!

Pelo fato de que os projetos podem ser movimentados entre os times, é nosso dever manter a qualidade do código que escrevemos, nós precisamos nos preocupar não porque alguém quer mas porque devemos, é uma tarefa de todos que escrevem/produzem código.

Qualidade

Manter a qualidade é ter empatia com quem mantinha, mantém e irá manter o código.

Muitas pessoas acham que testes automatizados são suficiente para garantir a qualidade mas a equação deveria ser algo como:

qualidade = testes automatizados + legibilidade + manutenibilidade + uma boa arquitetura

Por que o processo de revisão existe no Pull Request se eu posso mergear o código depois que os testes rodaram com sucesso?

Porque nós não podemos garantir a legibilidate, manutenibilidade e a qualidade da arquitetura. As pessoas acham que rodando um linter e tendo 100% de cobertura de código é o suficiente, mas não é.

Lembre-se, cobertura de código não significa qualidade de teste!

Como um time, nós somos reponsáveis pelo código da branch main. Quando alguém cria outras branches para implementar uma nova feature ou arrumar algum bug, quem criou a branch e o revisor são resposáveis por garantir a qualidade do código que será mergeado na branch main.

Algumas pessoas falam que o código é só o meio para criar/chegar no produto, mas se esse código não tem qualidade e definição, o que será do produto?

Provavelmente um produto que ninguém vai querer dar manutenção porque será muito difícil de entender como ele funciona.

Pull Request

Um Pull Request é um pedido para adicionar/modificar um ativo da empresa, é algo que já pode estar em produção, então, nós precisamos garantir uma alta qualidade porque nossos consumidores/usuários serão afetados diretamente.

O Pull Request é onde nós podemos validar todo aspecto da qualidade do código que irá ser mergerado na branch main, tentando reduzir qualquer possível erro no código!

Uma das partes mais legais sobre Pull Requests é que todos aprendemos alguma coisa, tanto o revisor quanto o revisado.

Agradecimentos especiais para as pessoas que revisaram esse post: