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!