DEV Community

Stefany Repetcki
Stefany Repetcki

Posted on • Updated on

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

Top comments (0)