DEV Community

Stefany Repetcki
Stefany Repetcki

Posted on • Edited on

3

O QUE NÃO FAZER EM UMA ANÁLISE DE PULL REQUEST

Todas as pessoas que precisam de uma análise para Pull Request já passaram por estas situações:

1° comentários desnecessários
2° opiniões sem fundamento
3° tempo gasto em situações que não levaram a lugar algum

Hoje ainda é comum ouvir um dev dizendo a seguinte frase

“Ah, mas eu faria deste jeito…”

Mas você deve se atentar pois nenhum dev programa da mesma forma.

Se o comentário não tiver FUNDAMENTO sobre o porquê aquela linha de código deve mudar você NÃO DEVE FAZER ESTA ALTERAÇÃO.

Vale frisar que padronização de código como clean code, arquitetura, warning do sonar, entre outras padronizações são fundamentos para um comentário do PR.

E para você que pratica este tipo de comentário/comportamento, sempre hà tempo de evoluir. Existe uma grande diferença entre o dev Sênior avaliando um PR e o dev Junior, ou seja o dev que ainda está aprendendo como se comportar em situações que exigem um esforço mais técnico, e são em situações como está (exemplos acima) que evoluímos como programadores, focando o esforço em códigos que tem essa possível melhoria com um fundamento.

Se você tem esta dificuldade de entender a diferença, você pode se fazer a seguinte pergunta "Esta mudança mudará o comportamento do sistema?" Se não, pode ser que seja irrelevante, pois travaria o dev de subir a sua tarefa apenas para deixar da forma como você achou melhor.

Reserve um tempo para revisar um PR corretamente. Revisar código não é apenas apontar dedos. É também uma oportunidade de aprender com os outros, e para aprender precisamos do FUNDAMENTO.

Indico que crie um checklist para sua empresa para alinhar o que realmente estão analisando em seus PR’s.

DICAS DE CHECKLIST
https://devchecklists.com/pull-requests-checklist/
https://sourcelevel.io/pull-requests-checklists-metrics-and-best-practices-a-definitive-guide

E tenham documentado uma lista de prioridades do que deve ser debatido em um Pull Request, como por exemplo:

  • Erros de código
  • Códigos com potenciais bugs
  • Padrões de desenvolvimento da empresa (CLEAN CODE, ARQUITETURA, ETC)
  • Boas práticas de programação fundamentadas em literatura

LEMBRE-SE

Se você é Junior, você pode analisar os PR’s tranquilamente de um Sênior, mas sempre tenha evidências(FUNDAMENTOS), como LINKS de apoio para apresentar no seu comentário.

Espero que tenha ajudado!:) Deixo aqui meu linkedin e github ❤️

Adicionais:

E complemento que analisar é sobre entender o real impacto e a motivação da mudança/funcionalidade. Analise estática e de estilo em sua grande maioria resolvesse com um CI bem configurado. @MarcosEllys

Sentry blog image

How I fixed 20 seconds of lag for every user in just 20 minutes.

Our AI agent was running 10-20 seconds slower than it should, impacting both our own developers and our early adopters. See how I used Sentry Profiling to fix it in record time.

Read more

Top comments (0)

Billboard image

The Next Generation Developer Platform

Coherence is the first Platform-as-a-Service you can control. Unlike "black-box" platforms that are opinionated about the infra you can deploy, Coherence is powered by CNC, the open-source IaC framework, which offers limitless customization.

Learn more

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay