Executando verificação de segurança...
8

Boas práticas de Code Review para bons programadores

O Code Review deve ser um processo natural dentro do fluxo de desenvolvimento. Esse processo ajuda a identificar bugs e má implementações antes da fase de teste e validação.

O resultado é uma base de código mais estável e de maior qualidade. Outro benefício de realizar code review de um parceiro é reforçar as relações pessoais e o senso de trabalho em equipe. O processo de revisão permite também uma distribuição do conhecimento técnico e compreensão dos processos entre o time.

Boas práticas na hora de revisar o código

O primeiro aspecto de um bom code review é se atentar ao lado humano antes do código. Abaixo segue uma lista de condutas para se atentar quando revisar o código de outra pessoa:

Revisor

  • Como revisor, você deve pensar como outra pessoa.
  • Ao apontar sugestões, tente formular frases a partir de um ponto de vista mais pessoal ex: "Eu sugiro que...", "Eu acho...", "Para mim, esse ponto..."
  • Sempre, SEMPRE a revisão é sobre o código, nunca sobre o autor. ex: ❌ "Você está fazendo uma implementação errada ..." ✅ " O código está fazendo uma implementação errada..."
  • Faça perguntas de pontos que não ficaram claros, ou ofereça sugestões através de perguntas. Por meio das respostas, podemos entender melhor a decisão para certo ponto do código.
Faça comentários através Observações, Impactos e Requisições
*ex:* **Observação** "Essa implementação é repetida em outro contexto, poderia ser reutilizada" **Impacto** "Essa implementação torna a compreensão do real objetivo do método não tão claro para mim" **Request** " Para esse cenário eu sugiro usar X padrão de projeto, por N motivos"
  • Entenda que existem diferentes soluções para o mesmo problema.
  • Distinguir entre boas práticas e gosto pessoal
  • Faça elogios ao código quando necessário, mesmo que precise de algum ajuste.
  • Se pergunte sempre se sua afirmação é verdadeira, se é necessária e se é gentil.
  • Valorize o esforço que o autor teve em escrever o código

Autor

  • Como autor, você deve ter humildade para ouvir sobre o seu trabalho
  • É normal acontecer falhas, ou ter implementações melhores, ou esquecermos de algum detalhe
  • Lembre-se que um código escrito em 10 horas é revisado em 10 minutos
  • Não leve as críticas para o lado pessoal, você não é o seu código
  • Você e o revisor estão no mesmo time
  • Somos sempre enviesados pelo nosso próprio código. Esteja aberto a opiniões externas

Código

Ao revisar um código é bom ter um checklist do que precisa ser avaliado. Conferir todos aspectos do código de uma vez pode ser exaustivo e propenso a falhas. É bom atentar-se a um tópico e validar todo conteúdo sob aquela ótica.

  • Eu entendo o que o código faz?
  • O código preenche todos os requisitos de implementação?
  • O código faz o que eu espero que ele faça?
  • Usando templates para Pull Requests, fica fácil analisar o que aquela PR deve resolver
  • A descrição da PR/commit está de acordo com o que o código executa?
  • Atenção a sintaxe, não tem nenhum code smells ?
  • Atenção se foi feito um tratamento de execeções
  • Ateção ao uso correto dos design patters e a over-engineer

Encontrei esse artigo no site dev.to, ele foi escrito pelo Christian Toledo.
Resolvi traze-lo para o TabNews para que possamos discutir sobre ele. Acredito que o processo de code review é de extrema importância dentro de um projeto e se for feito da forma certa, trás benefícios tanto para o código quanto para os devs, que podem aprender muito durante o processo!

Carregando publicação patrocinada...
8

Primeiramente, LeonardoSilva, muito legal o artigo, fico feliz de ver a galera escrevendo aqui.

Vamos lá:

Eu realmente discordo de muita coisa escrita aqui então gostaria de expor minha opinião.

Eu acho que quanto mais maduro for o time e quanto mais tempo o time trabalha em conjunto, menos importante é o Code Review.

Já trabalhei em times de maturidade altíssima, nesses times, o Code Review não era necessário.

Abríamos pull requests para a auto-revisão do autor, mas dificilmente um colega fazia um review maior do que "Uma simples passada".

Code Review pode ser bom quando estamos orientando desenvolvedores mais juniors. Realmente podemos apontar padrões de design e outras melhorias. Mas o ponto é que o Code Review é um gargalo.

Já trabalhei em empresas onde o time combinou que um Pull request deveria ser revisado em até 24 horas (com uma métrica interna do time apontando se isso estava sendo seguido).

Em 24 horas, dadas as liberdades corretas, eu consigo fazer deploy, testar, pegar bugs, dar rollback, corrigí-los e fazer um novo deploy umas 3-4 vezes se deixarem. Tudo isso sem impacto em produção.

O que se torna importante é a maturidade do engenheiro e das ferramentas que ele têm disponível.

Quando gastamos muito tempo em um Code Review, essencialmente estamos gastando horas de 2 engenheiros (ou mais) para desenvolver o mesmo código. Principalmente se o cara se aprofundar demais na análise e demorar muito entre revisões.

Se vou precisar de dois engenheiros, prefiro fazer **pair programming** então. Dessa forma eu vejo ganhos em qualidade, velocidade e tenhos duas pessoas como donas.

Ser dono, a famosa ownership, também é algo que eu valorizo muito. Se eu sou dono de um codebase, vou querer melhorá-lo constantemente. Ninguém melhor que o engenheiro que desenvolveu as funcionalidades para melhorá-lo. As vezes fiz um trade-off para entregar a funcionalidade e pretendo refatorar mais tarde. Isso significa um código que poderia ser barrado em um code review sendo que já estou ciente do problema e só fiz um gerenciamento do projeto para entregá-lo no prazo combinado.

Vai da qualidade do engenheiro e o contexto que ele está inserido de conseguir realizar o refactor que foi pos-posto.

O domínio do engenheiro é o código dele. Devemos tratá-lo como caixinha preta e garantir com testes e padrões automatizados eles sigam o padrão de qualidade da empresa. Um code review é subjetivo demais para eu gostar dele.

Posso falar mais sobre o assunto mas eu vivi a diferença em visões no passado. Sei que podemos automatizar muitos checks, ao ponto que o Code review se faz desnecessário e o engenheiro tem ownership completa de engenharia, funcionalidades, prazos, estilo, etc.

Jamais produzi código tão rápido e tão bem do que quando tinha essa liberdade.

Valeu!

5

Caramba, gostei muito da resposta estevaofay!

Inclusive, mesmo tendo defendido o code review no post original eu concordo em inúmeros ponto com você. Porém o problema que eu particularmente me deparo hoje, é de revisar PRs de devs muito juniors que não observam boas práticas e padrões estabelecidos pelo time... Então simplesmente deixar a resposabilidade da code base na mão de alguém tão iniciante é complicado.

Eu mesmo não me sinto ainda tão preparado para gerenciar tudo isso sozinho, e o fato de alguém mais senior revisar um PR pode ser interessante

3

Nesse caso eu acho válido. O junior vai estar muito preocupado em só "fazer acontecer". Ele não tem maturidade (normal do estágio de carreira) para ser dono do codebase.

Ai o Code Review vale a pena.

Mas perceba que meu argumento pressupõe que vc tem outras ferramentas para garantir a qualidade. Algumas delas são: Static Analysis, linters, Quality Gates, (basicamente tudo que se pode por numa pipe de CI)...

A gente acaba tratando o code review como ferramenta obrigatória. Toda empresa usa, mas quem só tem martelo só vê prego. Apoiado de outras ferramentas, o code review acaba sendo menos prioritário!

Eu já saquei que você entendeu tudo então só quis complementar aqui para estimular a conversa mas segue por esse caminho que vai dar bom ❤️

Valeu

6

Concordo, Leonardo! É muito interessante como o simples revisar do código (seja nosso ou de qualquer outra pessoa) pode mostrar tantas variáveis que não pensamos quando codamos.

E todo esse artigo que você trouxe é surreal, simples e direto ao ponto!
Mas também existe uma vertente super importante no quesito de code review que é escrever códigos legíveis, de fácil compreensão (isso pensando na parte do autor).

Essa vertente puxa a famosa prática de comentar os códigos (de forma literal e exatamente tudo), que ajuda demais quando se está iniciando na área e é uma prática milenar da área de programação.

Queria fazer aqui uma menção de um tópico do obrenoalvim que já puxa outro assunto que ajuda muito na compreensão do código quando revisado: Clean Code e a importância das boas práticas de programação

// Foi postado quase na mesma hora do seu tópico e agrega demais quando for a hora de revisar um código.