Mergear um código sem revisão é uma boa ?

Hoje pela manhã vi um post no Linkedin que me fez questionar, realmente seria uma boa ideia mergear código sem revisão, e qual impacto isso causaria no software.

Se você é um desenvolvedor com certeza já passou por esse processo, de adicionar uma feature nova ou corrigir um bug e após a resolução enviar o código para Code Review, para poder ser revisado e se tudo estiver ok ser mergeado. Essa manhã antes de começar a trabalhar vi um post onde fala sobre a demora de alguns PR's serem meregeados, neste post o autor sugeriu um recurso que o Github poderia ter de mergear automaticamente caso não tenha uma interação em até 48 horas.

Pessoalmente não acho que é uma boa mergear códigos não revisados, nos reviews são apontados melhorias, boas praticas até refactoring garantindo a levibiliadde do código, mantendo o código bem escrito e sem duplicidades ou implementações desnecessárias.

Hoje atualmente os mesmo devs que revisão e fazem os merges, são os mesmos que atuam no desenvolvimento do software, assim não tendo o tempo hábil para focar nessa atividade, devido estar resolvendo um bug complexo que impede do usuário final de usar o softaware.

filipedeschamps há 2 anos

Excelente pergunta! Na minha visão, essa dinâmica funcionar vai depender da senioridade das pessoas envolvidas e, principalmente, da maturidade que as pessoas tem sobre o design/engenharia da aplicação. Por "design" eu não quero dizer a interface, quero dizer a engenharia por trás, a arquitetura, modelagem e a visão de longo prazo para onde o projeto possa ser levado.

Então se uma equipe é formada apenas por pessoas com uma alta senioridade em tecnologia, e uma alta maturidade no design da aplicação, eu faria sim o tradeoff de deixar o Code Review opcional por uma velocidade maior (e muito maior) de interações com a base de código.

Do contrário, eu não faria isso, pois o mecanismo de revisão é o que faz estes dois fatores serem construídos num time, principalmente o segundo fator (design).

felipsbreno há 2 anos

Bom ponto de vista, com o seu comentário você responde o segundo questionamento, do qual impacto isso pode ter no software. Talvez se tivesse como identificar se o PR é critical, major ou minor poderia aplicar para os minors, que geralmente é uma implementação não tão sensível como um critical ou major.

rafael há 2 anos

Filipe, você enxegar um cenário onde exista **uma equipe apenas com seniores**, ou então já participou/viu uma equipe assim? Minha pergunta é motivada por um vídeo do Akita. Busquei a parte específica que veio à minha mente, mas não achei. Se não me engano, ele comentou que toda equipe precisa ter juniores, porque nenhum sênior quer fazer as "tarefas simples" que são repetitivas para ele, mas que para um júnior seria bom fazer. De qualquer forma, na minha busca achei [este vídeo do Akita](https://www.youtube.com/watch?v=H84WD_xyj10) ([blog post](https://www.akitaonrails.com/2019/10/16/akitando-64-comecando-na-carreira-de-ti-faculdade-niveis-de-experiencia)), no qual ele comenta sobre revisão de código, juniores e seniores: > Dado tudo que eu falei, se tem uma recomendação que eu faria primeiro a qualquer empresa, de qualquer tamanho, é que nenhum código deve ser imune à revisão, não importa de quem seja. Todo código deve ser revisado por alguém da equipe, de preferência mais de uma. Todo júnior precisa que alguém aponte o que ele fez de errado, o mais rápido possível. Todo sênior precisa se acostumar a orientar os outros e revisar o código é o primeiro passo. E pra escalar não tem nada melhor que pressão peer to peer, todo mundo olhando todo mundo. Se isso for rotina, fica muito fácil pra equipe inteira notar muito rápido quem está entregando código, em qual qualidade e com que frequência, e não deixar os problemas graves se acumularem a níveis ingerenciáveis.

filipedeschamps há 2 anos

Rafael, **excelente questionamento**! Imagino que em uma equipe com muitos sêniors há uma grande chance de dar problema, mas mais pelo fato de cada um querer puxar o barco para um lado (por exemplo, nas decisões de arquitetura e modelagem). Agora, já trabalhei com equipes pequenas que deram muito certo, pois todos tinham uma maturidade muito alta sobre o design da aplicação... e a maturidade neste ponto vai além da parte técnica e entender que **qualquer tarefa importa, se ela for importante.** Então disso eu separo pessoas seniores em duas categorias: seniores **maduros** e seniores **imaturos**. Um senior imaturo vai de fato querer se escapar das tarefas chatas, simples, e não irá fazer nada para parar de ficar desmotivado com o próprio trabalho ou sobre a situação que se encontra. Já um sênior maduro topa fazer todas as tarefas, as legais, as chatas e as simples caso essas tarefas sejam **importantes**, como por exemplo, **impactem no usuário final**. Na cabeça de uma pessoa madura, não existe tarefa chata quando há impacto real (seja **direto** ou **indireto**). E se não há impacto algum, nem indireto, porque essa tarefa está sendo feita? **Até uma refatoração tem impacto**: direto em quem trabalha com o software e indireto no cliente que usa o software e vai conseguir receber atualizações e novas features mais frequentemente no futuro. Veja [nesse tweet](https://twitter.com/SergioRocks/status/1591861004404760576) um ângulo adicional sobre a postura madura que comentei: ![Tweet sobre postura madura em desenvolvimento de software](https://i.imgur.com/k0J7jCj.png) E sobre o quote do Fábio Akita, nada do que eu comentei exclui sobre a relação entre um Junior e Code Review, nesse caso acho algo extremamente saudável para transporte de conhecimento 🤝 mas por fim, é tudo uma questão de trade off 👍

KaioPiola há 2 anos

Vai virar uma chuva de bugs absurda, é melhor que demore mesmo e faça um serviço bem feito da primeira vez do que ter que voltar e perder o maior tempão corrigindo depois, por que é exatamente o que vai acontecer.

CarlosJunior há 2 anos

Eu vi uma postagem muito parecida (talvez a mesma). Entendo que esse não é o melhor remédio. Não seria melhor ter PRs menores? Ou talvez ter uma quantidade de horas por semana/sprint/etc para já contabilizar esse trabalho? Enfim, entendo que existem várias outras formas de resolver essa questão. Na minha visão, aprovar PR automaticamente é perder uma oportunidade preciosa.

jackson541 há 2 anos

A equipe da minha empresa passa por esse exato mesmo problema, mas acredito que a maioria também deve passar. Porém, damos mais prioridades de review as demandas dependendo do seu tipo: features ficam em code review até que alguém do time fique livre para revisar, já os as correções de bugs são revisadas o mais rápido possível para poder ser lançado para produção. E para isso simplesmente vamos no chat de alguém que pode revisar demandas e pedimos diretamente que ela valide a correção do bug. Dessa forma, garantimos que os ajustes críticos sejam lançados rapidamente.