Executando verificação de segurança...
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!

Carregando publicação patrocinada...
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