Code Reviews são a nova Dívida Técnica?

Olá pessoal sejam bem-vindos a mais um vídeo aqui no canal e hoje eu vou reagir a um post que eu encontrei lá no Linkedin falando sobre code review ser a nova dívida técnica e esse vídeo aqui é bem sem roteiro a gente vai reagir mesmo e eu queria só trazer atenção a gente tomar cuidado com esses tipos de posts alarmistas é que são trazidos no Linkedin para gerar engajamento então quero trazer alguns pontos sobre isso vamos dar uma olhadinha nesse post vamos lá então Começando aqui muito importante deixei anônimo quem é a pessoa Onde ela

trabalha tudo mais porque o objetivo aqui não é falar da pessoa não é atacar pessoa nem nada de gênero é falar sobre o conteúdo e da minha opinião sobre isso então começa aqui por que que code reviews são o novo Tech Death né o technical de ali o dívida técnica e começa aqui baseado em dados reais de 50 mais times o primeiro ponto é esse né a gente não sabe realmente se são Dados reais ou isso foi colocado apenas para engajamento né ou para dar um senso de autoridade Mas vamos seguir eh descobrir algo controverso

reviews tradicionais estão matando produtividade né E aí ele coloca alguns números aqui os números 4 horas por dia em reviews ó bastante tempo eh eu não sei como foi calculado isso aqui isso é baseado numa média dos 50 times ou o qu né não tem muitos detalhes Mas enfim 28% do tempo dos seniors fazendo review 40% dos atrasos atrasos de quê né não sei zero melhoria real muitas vezes eh primeiro ponto assim antes de gente começar aqui eh muito importante sempre que você lê um post no no Linkedin vá com um olhar de Ok é

mais uma fonte de informação e não necessariamente a fonte da verdade de uma informação tá é porque muitas pessoas por ver um Post no Linkedin acham que e tudo que tá ali é verdade ou tudo que tá ali é uma dica boa é de trabalho enfim né seja crítico sempre mesmo sendo uma dica boa mesmo sendo uma dica ruim uma dica mediana enfim e tenha seu senso crítico consulte várias Fontes beba de várias Fontes aí para para formar tua opinião e aqui continuando Por que que isso acontece ele traz né porque desses atrasos zero melhoria

enfim primeiro reviews focam em estilo de código best practices né boas práticas padrões detalhes técnicos e ignoram context sharing knowledge transfer team learning Impacto real né Eh primeiro de tudo aqui né Eh acredito que é difícil às vezes para o se level né a pessoa que é um CTO no caso um se level é entender que o review no processo de review É sim importante a gente dar uma atenção para essas coisas as boas práticas se os padrões estão sendo seguidos eh estilo de código detalhe técnico por quê eh porque não é Perfumaria Pode ser

que seja em algum caso pode ser mas via de regra e a gente vê que esses pequenos detalhes e se traduzem lá na frente em dívida técnica que é exatamente o que ele traz aqui que por que que code review são a nova dívida técnica enquanto tá criticando uma coisa aqui que é exatamente que ao longo do tempo a des ocupação vou fazer de qualquer forma o estilo de código vou não vou me preocupar com boas práticas os padrões detalhes técnicos como que eu tô escrevendo a qualidade que eu escrevo uma query para ver se

ela tá performática ou não eh enfim eh vários desses pontos ao longo do tempo acumulados geram dívidas técnicas E se ninguém tá olhando para isso ninguém tá revisando principalmente os mais e experiente você começa a ter uma base de código toda bagunçada que depois para você voltar e corrigir refatorar vai dar muito mais trabalho do que é você olhar isso durante a o andamento da Sprint ali da da revisão ali da demanda né E aqui na parte de ignoram ele traz alguns pontos que realmente podem ser reais mas a gente tem que deixar bem claro

que não é culpa do Code review em si e sim do um mau cod review ou de um processo que não foi guiado Não foi bem explicado eh não foi bem implementado sobre o que você precisa fazer também quando você faz um code review que é eh ter o contexto ali de de negócio do do que tá sendo entregue não apenas da parte tecnológica né Eh utilizar aqui que ele colocou transferência de conhecimento utilizar o Code review como ferramenta eh para aprendizar mesmo para transmitir conhecimento em algum comentário que você fez no review Ah tá

ruim essa quer tá isso aqui pode melhorar não coloca só assim ou ó mude para isso isso não gera conhecimento você tem que escrever o porquê daquilo né os Porquê sempre são muito importantes e se encaixa aqui no Team learning também que é você desenvolver eh a pessoa através do Code review e eu já recebi vários relatos de pessoas que antes trabalhavam um time pequeno ou trabalhavam solo com programação e entraram num time maior e o processo de code review o processo de trabalhar nesse time maior de ter todos esses Eh esses processos fazem com

que ela aprenda muito mais desde que o processo seja bem implementado né que ele realmente passa esse conhecimento então sim tem muitos eh processos de de review que ignoram aqui esses pontos eh mas eh ele colocar aqui no post que reviews que focam em estilo de código boas práticas eh ficou subentendido que são ruins que são besteiras eu acho extremamente desnecessário você sim tem que se preocupar com isso e se preocupar com isso não significa que você não vai se preocupar com outras coisas então é isso que mais eh me deixa é irritado nesses posts

né é o pessoal coloca é é 8 ou 80 mas vamos continuar aqui no post nas palavras dele a solução que implementei perir reviews review síncronos 15 minutos no máximo foco em contexto aprendizado real Impact first eh os dois primeiros aqui Pair reviews e reviews síncronos né perir reviews talvez em algumas demandas específicas ali você possa fazer um review para parado com alguém que para explicar alguma demanda muito complexa é que seja muito difícil de transmitir isso através de de algum outro método né mas via de regra Eh você tá alocando o tempo de duas

pessoas reviw síncronos também para eles estarem ã ali no mesmo tempo sendo que a as pessoas podem estar fazendo coisas diferentes né o cara que fez a demanda já tá fazendo outra coisa já tá e formando em outra atividade enquanto alguém tá fazendo o review dele só depois ele vai voltar nisso né não tem porque ser review síncrono quando que isso pode virar uma agenda assíncrona quando o review ou em vários reviews e que as pessoas têm pego eh tem muitos erros de um tipo específico e o time tá errando em algum aspecto tá se

despreocupando-se esses reviews e leva para uma agend da síncrona explicando pras pessoas eh como que elas podem melhorar para que nos próximos reviews eh isso não aconteça né esses tipos de erros não aconteçam eh mas ficar sempre fazendo um review cinco no com cada pessoa eu acho que é pouco produtivo né conta contra a a o próprio post aqui que é questão de produtividade de gerar mais Impacto né 15 minutos no máximo aqui tá falando 15 minutos no máximo eu entendo por ser os reviews síncronos né então também Cara depende muito cvar regra assim não

não faz menor sentido o review pode demorar mais que isso a demanda pode ser mais complexa eh Talvez a pessoa tenha que testar alguma coisa ali para para ver se realmente tá funcionando ou não tá funcionando enfim eh não tem muito o que comentar aqui foco em contexto que sim isso a importante né você não vai fazer só o review da questão tecnológica você tem que est eh bem alinhado com o que está sendo entregue com texto daquela demanda aprendizado real genérico aqui eh mas você pode gerar o aprendizado através de outras formas através de

review assíncrono fazendo agendas pontuais gerando guidelines baseados nos erros mais comuns ou eh criando uma lista né de boas práticas de guidelines também que guiem as pessoas de como fazer o código como escrever Quais são os padrões que elas devem seguir nas demandas no projeto específico ou no nos projetos como um todo da empresa eh Isso facilita essas ações facilitam para que você tenha reviews e com menos erros né se você tem guidelines bem Claras E aí continuando no post dele aqui ele traz sempre com essa mentalidade resultado maior que perfeição contexto maior que código

learn maior que nit picking valor maior que estilo eh guidelines Claras checklist objetivo sla definidos automação forte responsabilidades claras com o que que eu concordo e o que que eu mais ou menos não concordo aqui primeiro aqui resultado maior que perfeição eh concordo mais ou menos tá eh obviamente ninguém vai chegar na perfeição isso é nem precisava ser mencionado aqui mas ã e a gente quer ter um resultado mas esse tipo de comparação é é o que que eu penso que esses posts ficam trazendo alguns posts até eh das pessoas que não são tão técnicas

que é Ah eu quero focar 100% na produtividade quero entregar logo e eh que se exploda a qualidade dá essa essa percepção nesses tipos de post e eu vou fazer um vídeo mais paraa frente no canal falando de quando a a qualidade tem que ser mais priorizada quando você tem que agilizar um pouco mais ou priorizar a velocidade né vai ter um vídeo no canal sobre isso mas aqui do resultado perfeição é sim tem que ter resultado Mas você não vai fazer coisa de qualquer jeito perfeição ninguém nunca vai atingir o segundo aqui contexto maior

que código também não é é um ou outro é os dois juntos você tem que ter o contexto do que tá sendo feito da demanda mas o código também é importante para não gerar dívida técnica lá na frente eh não vou passar por todos aqui mas por exemplo valor e estilo eh a o que gera valor e o estilo de codificação tá beleza valor sempre quer atingir mas o estilo se você tem o próximo ponto que ele traz ali que é guidelines Claras o estilo de codificação também é importante já pensou se você tem um

time grande e cada um decide codificar num estilo diferente né colocar um padrão outro eh nomear variáveis num estilo outro no outro estilo então fica uma coxa de retalhos ali no código então estilo sim é importante assim como as guidelines claras que inclusive vão definir esse estilo para que todos os desenvolvedores eh Fiquem na mesma página Sigam o mesmo e roteiro digamos assim né o mesmo estilo ali inclusive checklists objetivos Ok slas definidos não sei o que ele quis dizer com isso e se é o tempo do review se é enfim não sei automação forte

Esse sim é um ponto muito importante que é que gera muito valor Ah se você tem uma ferramenta automatizada aí para rodar antes do Code review de uma pessoa então uma ferramenta aí eh automatizada com ia ou sem ia enfim análise estática de código eh para fazer um um uma eh nomes incompatíveis eh linhas em branco essas coisas assim que não precisa tirar do tempo do humano para fazer esse tipo de review então automação forte é um um belo ponto aqui e responsabilidades Claras aí algum item genérico aí eh essas listas muito ponto a ponto

não dá de entender muito contexto também do que as pessoas querem falar 100% e aqui ele fala né resultado aposta TR meses reviews três vezes mais rápidos quase zero de backlog time mais engajado código melhor código melhor Será mesmo é não olhou muito para código né Será que o código tá melhor time mais engajado Talvez né Não não vou desmerecer ninguém aqui quase zero backlog reviews três vezes mais rápidos Ok velocidade tem que ver a qualidade né e o Segredo segundo ele aqui no post review são ferramentas de grow e não de controle eu acho

que são de ambos tá não acho que é um ou outro eu acho que são de ambos ter controle sobre a base de código vê se tudo tá sendo seguido conforme as guidelines se o projeto tá andando nos trilhos e também de crescimento por causa que você vai desenvolver as pessoas nesses code reviews né vai vai estimular o conhecimento aprendizado Então vamos lá para um resumo no final para fechar o vídeo aqui muito bem pessoal Então esse foi o vídeo aí falando sobre esse post que traz o assunto que code reviews são a nova dívida

técnica é o principal ponto aqui é que code reviews também é sim para olhar para código para boas práticas para padrões sim mas não deixar de lado a parte de gerar um impacto gerar crescimento do time aprendizado e tudo mais então a principal coisa do post é é que ele traz tentando um sensacionalismo ali né tentando falar que uma coisa em detrimento da outra mas na verdade é um conjunto você tem que buscar o equilíbrio tá E é isso que irrita um pouco nesses posts aí é que talvez para gerar engajamento falam ah faça assim

eu faça assado Essa é a regra Essa é a a a bala de prata para resolver os teus problemas para revolucionar a tua empresa para gerar mais desempenho aí né e produtividade da dos seus colaboradores e a gente sabe que não é bem assim mas eu quero ver você aqui nos comentários O que você achou desse post se você concorda ou não concorda coloque aí suas impressões a sua opinião que eu vou querer ler se você gostou do vídeo deixa um like se inscreve no canal se você não é inscrito também e a gente se

vê no próximo vídeo valeu n