A Síndrome do MR Grande

Quem nunca, ao abrir um merge request já teve esses tipos pensamentos:

“Acho que já vou lançar junto a correção do bug X…”
“Vou aproveitar a carona e já adicionar o recurso Y…”
“É melhor já refatorar esse código Z…”

São exatamente esses tipos de pensamentos e comportamentos que nos sabotam, pois o que pensamos que será uma vantagem :), pode se tornar a nossa própria armadilha :(. Vamos entender alguns sinais que a síndrome de um MR grande pode causar:

Tempo de revisão

Possivelmente merge requests grandes levarão mais tempo para serem revisados, isso quando eles de fato são revisados efetivamente. Alguns efeitos colaterais poderão surgir, como a demora na entrega de uma feature, o bloqueio de outros desenvolvedores que dependem do código a ser revisado e até mesmo expectativas frustradas para determinada entrega.

Bugs no codebase

O alto volume de files changed podem aumentar a introdução de bugs no codebase. Quanto maior o MR, maior o nível de complexidade durante a revisão do código, por não carregar um contexto único e trazer muitas alterações ao mesmo tempo. Além dos rebases cansativos, que carregam um risco enorme de sobreposição de códigos na branch principal (master/main) da aplicação.

Falsa aprovação

A solicitação mais perigosa entre desenvolvedores: “Aprova lá pra mim?” (Devs, não façam isso). Code review vai além de aprovar (approve) e mesclar (merge) código, é um processo de análise detalhada, que carrega sugestões de melhorias e boas práticas, garantindo a qualidade e saúde do código de uma determinada aplicação.

Além desses sinais apresentados acima, com certeza existem outros casos, mas simplesmente sinalizar o problema sem apresentar uma solução para o mesmo, não é produtivo e eficiente em seu tratamento.

Portanto, gostaria de apresentar alguns conceitos, padrões e abordagens em desenvolvimento de software, que servirão como impulso para um processo saudável de code review, com merge requests fáceis de serem revisados, separados por contexto e que acelerarão o desenvolvimento do produto.

Princípio da Responsabilidade Única

Se você já ouviu falar de SOLID, provavelmente deve estar familiarizado com a sigla SRP (Single Responsibility Principle). Esse primeiro princípio declara que cada classe ou módulo deve ter apenas uma única responsabilidade, e não ser uma God Class (uma classe que sabe ou faz tudo). Aplicar esse princípio em nossos merge requests pode ser uma chave incrível para nosso processo de desenvolvimento e entrega de produto.

Alguns exemplos de MRs com apenas uma responsabilidade:

• Criar componente Lorem
• Instalar plugin Ipsum
• Corrigir o erro Foo
• Atualizar a classe Bar

Além desses pontos, temos toda uma estrutura de anatomia de um merge request a ser revisada, padronizada e aplicada, mas deixa esse assunto para um outro artigo.

Curtas iterações

O Clean Code (Código Limpo) carrega alguns princípios excelentes para o desenvolvimento de software, e na prática essa mentalidade de iterações mais curtas no código, pode trazer muito benefícios:

• Velocidade na revisão do código;
• Simplicidade em testar e identificar más práticas;
• Entradas mais rápidas de features menores / parciais em produção;
• Liberar recursos que não estarão ainda visíveis para o usuário, mas irá agregar ao sistema;

Praticar pequenas adições podem ajudar e anteceder o processo de desenvolvimento, como por exemplo, ser inserido até mesmo em cerimônias de planejamento / refinamento com o time, durante as quebras das tarefas.

"It is not the language that makes programs appear simple. It is the programmer that make the language appear simple! "
- Robert C. Martin (Uncle Bob)

Desenvolvimento de software é um universo de possibilidades. O objetivo desse texto não é trazer um discurso triunfalista com fórmulas mágicas, mas sim encorajá-lo a sair da zona de conforto, dar pequenos passos para um processo de desenvolvimento saudável, disciplinado e produtivo.

Hoje essa cultura poderá começar a partir de você e amanhã multiplicar para toda a engenharia da Fretebras 🚀.

”Insanidade é continuar fazendo sempre a mesma coisa e esperar resultados diferentes.”
- Albert Einstein

Obrigado por ler! Se você gostou do artigo, dê um clap 👏.