Como SER APROVADO na CODE REVIEW Sendo Dev Júnior (MÉTODO INFALÍVEL)

eu tenho certeza que se você trabalha ou já trabalhou em alguma empresa você já subiu seu código para code review e ele voltou mais rasurado que o teu caderno depois que tu ia no banheiro e voltava no ensino fundamental Só faltou o Senior desenhar um pinto no seu código de tanta coisa que ele rasurou lá a verdade é que os programadores que entram nesse mercado não fazem ideia de como funciona a dinâmica de trabalho em uma empresa e eles acham que assim que conseguirem a primeira vaga já vão conseguir financiar um HB20 rebaixar e sair

com a novinha aí depois do des pedinho mas você chega na sua primeira vaga todo juvenil e sobe seu código pro primeiro code review E aí o Senor quando olha o código te estoma te humilha acaba contigo mas o que isso que está aparecendo aqui no meu computador eu não acredito nisso e tu fala cara eu quero deixar essa vida não quero mais ser programador eu quero sair dessa empresa eu não sei o que fazer eu vou trabalhar no caixa do mercado do meu tio mas graças a Deus vocês têm esse canal aqui e hoje

eu vou te ensinar tudo que você precisa saber sobre cod viu sobre como subir um bom código sobre como não ser humilhado o que fazer antes de subir o teu código e tudo mais vou te ensinar tudo que tu precisa fazer para não sentir humilhado no seu primeiro code review Então chega de enrolação e bora pro vídeo e obviamente o que eu tô brincando sobre a parte de ser humilhado tá porque a maioria dos seniors que estão fazendo ali o Code review não tem intenção de te humilhar basicamente eles só não sabem como falar né

E como escrever e tudo mais só só se ler só as figuras Inclusive eu vou fazer uma live lá lá no curso sobre como fazer um code review realmente né ler o código colocar os comentários e não fazer o outro programador se sentir humilhado Mas tudo começa quando um Júnior ou um Sênior aí pode ser até um PL sei lá um programador né que entra numa empresa e tá de cara com Framework novo ou com um padrão de código novo um jeito de escrita que ele nunca tinha visto então assim a forma que ele programa

não vai est de acordo com a empresa né então muitas vezes a empresa os outros programadores vão estranhar isso E demora um certo tempo até o programador conseguir pegar o jeito né Desse código né da forma que os outros programadores entregam o código da empresa e aí assim na maioria dos code reviews sempre vai ter comentário né no começo sempre vai ter comentário dos outros programadores indo lá mas não é porque tu é ruim é porque tu ainda não conhece o estilo da empresa Enfim então é na maioria dos casos como eu falei não é

porque tu é ruim mas às vezes é porque tu é ruim aí tu vai precisar melhorar mas na maioria dos casos é por questão de padrão de projeto mesmo tu não tá acostumado com aquele padrão E aí eles vão começar a te corrigir para que tu comece a aprender e o grande O problema é que todo Júnior que começa numa empresa vai começar sempre inseguro então ele tem medo de ser demitido amanhã ele tem medo de não passar nos TRS meses de teste ele tem medo até porque demorou muito para ele conseguir a primeira vaga

dele e quando ele consegue ele não quer perder então ele dá tudo que ele tem ele fica ansioso e tudo mais com medo e achando que cada entrega que ele for fazer vai ser uma opinião vai gerar uma opinião negativa nos outros programadores e que pode ser que ele perca a oportunidade que ele conseguiu com tanto custo né Porque hoje a gente sabe que não tá fácil de conseguir V E aí assim quando ocorre uma reprovação no code review ou seja o código que ele subiu foi reprovado né não pode passar não pode ir pra

produção o que que acontece né a pessoa na hora se sente reprovado né torna isso pessoal e acha que quem foi reprovado foi ele e não O código dele então o ego muitas vezes vai um pouco em cima o medo também e tem aquele desespero todo e muitas vezes o Senior tá lá um monte de tarefa para entregar com piou enchendo o saco e tudo mais a tem que ir lá revisar o teu código muitas vezes por falta de tempo ele vai jogar um monte de comentário lá às vezes nem vai falar contigo só vai

receber a notificação vai entrar e vai ver aquele tanto de pinto desenhado aquele tanto de comentário desejado no teu código né e o resultado disso na maioria dos casos é que o júnior vai sentir um bosta né vai ter síndrome do impostor muitas vezes não vai mais querer falar com os outros programadores ou vai querer ficar mais quieto não vai querer procurar tanta ajuda com medo de denotar mostrar né algum tipo de desconhecimento e tal ignorância no assunto de código ou do padrão de projeto da empresa e algun sen eu chegar e falar assim não

sabe o que tá fazendo demite ele e acha outra pessoa mas então qual é a solução para você que é Júnior ou Senior ou pleno né parar de chorar no banho aí depois de um covid review revisado né assistindo lá o edit do barco chorando Então qual é a solução tá existem alguns passos que eu vou passar para vocês são Passos bem simples Passos bem rápidos que vão garantir tá que tu tenha a menor chance possível de e revisão no teu code review de de reprovação como comentários pintos e tudo mais tá bom então vamos

lá pro nosso primeiro passo então assim o primeiro passo é garantir que todas as regras de negócio que foram escritas pelo Poo lá na tarefa que você pegou lá na board né lá na no menu de tarefas a tarefa que tu pegou para si que tudo que está de regra de negócio lá ou seja o que teu código vai fazer o que deve ser feito na aplicação o que a aplicação deve mudar né se o teu código tá cobrindo esses essas regras de negócio porque não adianta o código ser limpo não adianta o código ser

bonitinho não adianta o código ter seus comentario zinhos fofinhos e tudo bonitinho tudo com os tabs tudo certinho tudo com indentação não adianta se não traduzir a regra de negócio se não fazer aquilo que o po quer que esse teu código faça né Para que o sistema fique melhor pro cliente final ou seja vou dar um exemplo né se é para te corrigir tá um envio de e-mail por exemplo onde não tá carregando a logo da empresa naquele envio de e-mail mas adant fazer um código limpo e não funcionar no fim das contas né então

basicamente o teu código tem que ser para funcionar a regra de negócio em segundo lugar vem ele ser limpo ele ser bonitinho ele ter a identação certa Ele tá nos conformes da empresa em segundo lugar vem isso né então mas em primeiro lugar vem traduzir a regra de negócio exatamente como ela tem que ser como estava na cabeça do Poo e como ele traduziu pra tarefa que tu pegou o segundo passo é pegar o teu código e passar no chat GPT antes que tu suba o teu code review tá antes que tu suba a tua

P request né antes que tu faça um p request por quê Porque tu vai conseguir Agora sim né Depois que tu Já verificou as regras de negócio entender se o código está bem escrito se não tinha formas mais otimizadas né de tu fazer esse teu código eu vou deixar aqui na descrição um PDF onde eu tenho um comando que eu uso para enviar os códigos antes de eu subir uma code review para o GPT E aí eu recomendo que usem o GPT de quatro para C de quatro f o GPT 4 para cima tá então

o 4 o o 4 o mini o o One preview ou o One mini vocês podem usar esses daí também Eles são um pouco mais demorados eu gosto bastante tá do do Chave GPT 4 o mini ou preview eu não lembro qual deles é mas é muito bom tá eu vou colocar lá também descrito Qual o modelo que eu uso então basicamente esse prompt tu vai colocar o prompt embaixo tu vai colar o código subir lá no chat PT e pedir para ele corrigir então basicamente o promp vai pedir para ele melhorar deixar mais otimizado

deixar mais limpo o código e explicar linha a linha o que que ele melhorou e por ele melhorou e como poderia inclusive assim se adequar Ao estilo da empresa então tu vai poder colocar lá no prompt inclusive Qual é o Framework que a empresa usa para que o próprio chat IPT tente adequar um pouco o teu código ao padrão da empresa porque ele vai saber olha ele usa o nextjs versão 14 Ok nextjs versão 14 usa o roteamento desse jeito Usa o server Side rendering desse jeito usa a parte de client desse jeito então eu

vou modificar um pouco O código dele para que se atenda a esse Framework então passem no chat GPT só que não basta só passar no chat GPT e vazar subir lá e falar [ __ ] tchau não precisa entender o que que o chat GPT fez por isso que no comando tá pedindo lá né o porque ele alterou as coisas para que tu aprenda e da próxima vez tu faça daquele jeito tá não seja um programador de chat GPT que só depende do chat GPT então tu vai se lascar Porque daí vai acontecer de tu

sair dessa empresa tu ir PR outra empresa fazer um um teste técnico e basicamente vai fazer o teste técnico tu vai precisar do chat GPT porque tu vai entregar um código merda porque tu sempre dependeu do chat GPT para melhorar teu código Então aprende com ele e melhora o teu código para aos próximos por requests inclusive tu não precisa usar só o chat hpt tu pode também chamar um outro programador mais experiente e pedir para ele fazer algumas alterações para ti revisar teu código contigo antes de tu subir para o github o terceiro passo ele

parece ser muito Óbvio mas o Óbvio precisa ser dito né como eu já falei várias vezes aqui é testar o teu có cóigo em um ambiente externo não testa só na tua máquina na tua máquina sempre vai funcionar porque tu desenvolveu na tua máquina enquanto tu ia desenvolvendo tu ia resolvendo problemas que tinham no teu ambiente que talvez tu não tenha resolvido nos ambientes externos no ambiente de desenvolvimento ambiente de homologação inclusive até no ambiente de produção sempre testa em ambiente externo toda empresa que seja séria né A empresa que já tem uma certe experiência

ela tem ambientes de teste ambiente de desenvolvimento que é um servidor de desenvolvimento uma p Line tudo certinho tu sobe lá naquela Branch do github E aí lá dentro dessa Branch do github ele vai carregar lá uma pipeline vai rodar lá no servidor vai instalar no servidor alteração que tu fez tu vai poder testar então sempre testa no ambiente externo no ambiente de desenvolvimento depois do ambiente de desenvolvimento tem alguns casos inclusive que tem um q na empresa tu testou no ambiente de desenvolvimento funcionou tu passa para o ambiente de homologação chama o q pede

pro q testar junto contigo testou aí sim tu pode subir esse code review mas sempre testa em um ambiente externo tá porque muitas vezes tu vai criar o teu código e talvez tenha uma variável nova de ambiente né tu tá des tá integrando com uma API externa tem uma chave de api essa chave de api às vezes tá só no teu ambiente local tu precisa subir no ambiente de débito precisa subir no ambiente uma logação ambiente de produção para que elas funcionem então precisa cuidar disso testar nestes ambientes externos antes de subir sério eu já

fiz isso muitas vezes confiando na minha habilidade tendo aquela confiança que o programador Senor tenho ó já subi tanto código aqui Tonin aí vou subir aqui direto e [ __ ] não vou testar em ambiente de produção em ambiente de Dev né ambiente de produção é [ __ ] não testem em ambiente de produção porque ambiente de produção é um ambiente do cliente testa em ambiente de desenvolvimento eu eu entendi a referência mas muitas vezes eu subia tudo e [ __ ] né E aí muitas vezes quebrava sempre teste ambiente de Dev não Confie na

sua confiança e o quarto passo é também simples mas talvez não seja simples de implementar é simples de explicar que é basicamente tu não levar pro lado pessoal então tu vai subir tu vai olhar lá vai seguir todos os passos anteriores se deu tudo certo tu vai subir esse code review inclusive existe um momento para subir o Code review Então antes de tu abrir uma PR e quando eu falo code review é mais a PR mesmo tu vai abrir uma PR e vai ter uma revisão daquele código daquele por request que tu abriu então assim

sempre antes de subir uma PR primeiro conversa com o poo e vê se não tem outro item na fila então às vezes ele quer subir outra outro código primeiro para depois o teu às vezes outra tarefa tem mais prioridade Então antes não é só tá pronto tá pronto vou subir não pergunta pro pior posso subir posso subir pra produção disso aqui posso abrir um por request lá para eles revisarem meu código finalizei testei tudo nos ambientes tal tá tudo certo ela vai dizer pode ou não Aguarda um pouco pode então Enfim no começo sempre pede

autorização sempre Pergunta antes em tudo que tu for fazer para que tu não tenha problema então perguntar demais não é problema agora fazer cagada né no ambiente subir alguma coisa sem autorização Aí sim é problema então sempre Pergunta antes então assim subiu o PR vai ter aod de review se chegar a comentário se tiver uma reprovação e tudo mais não leva pro lado pessoal o Senior na maioria dos casos Tec Lead o gerente seja o que for que for revisar o teu código ele não tem a intenção de te tirar da empresa el não tem

intenção de te desfazer na maioria dos casos tá não maioria mesmo 99,9 não tem intenção de te tirar da empresa até porque eles nem te conhecem ainda e eles querem só que o teu código suba sem quebrar produção ou que tu faça de uma forma melhor então então não leva pro lado pessoal eles estão criticando o teu código e não você como programador como desenvolvedor O Brendo como então você é um programador Eles não estão te criticando eles estão criticando o teu código então tu vai ter que melhorar o teu código e aí tu já

sabe tu vai ter que melhorar também nos próximos aqueles pontos que eles falaram então eu recomendo que vocês ten uma listinha vocês anotem qua quis foram as alterações que eles pediram pra gente fazer naela code review e na próxima vocês olhem essa listinha e falam olha ele tinha pedido para mim alterar esse ponto Será que no código Eu ainda tô errando nesse ponto não então ok então vou subir seão vou corrigir então sempre tenham essa essa coisa de não levar pro lado pessoal olhar a alteração e enxergar isso como uma possibilidade de tu melhorar na

maioria dos casos o programador não quer te ferrar nos casos que o programador Senor não foi com a tua cara né o Tech Lead não foi com a tua cara alguém não foi com a tua cara e quiser ficar te zoando desendo pinto no te dejo na boca e me dá tesão aí sem que chora meu amigo porque daí enfim não vai ter jeito o grosso vai entrar e o que passo é testar isso em produção então o teu código foi aprovado subiu pra produção rodou a pipeline agora Tá em produção O que que é

o ambiente de produção é o servidor que o cliente tem acesso então o cliente final tá o cliente final não o teu cliente enfim o cliente final da empresa que tu tá trabalhando aquele cliente final ele Tá acessando a plataforma usando o ambiente de produção quando sobe um código para ambiente de produção quer dizer que lá vai rodar esse código que tu subiu e o cliente vai começar a ter acesso às novas funcionalidades e tudo aquilo que tu fez vai começar a funcionar para o cliente final Antes de tu dar com uma tarefa concluída Nossa

tá concluída minha tarefa vai lá e testa Pede uma conta de produção para alguém é uma conta fechada dos desenvolvedores lá em produção e testa se tu for por exemplo aquele ajuste do e-mail que eu tinha comentado antes né da logo testa esse envio de e-mail vê se vai chegar vê como é que tá no celular quanto AB pelo celular vê como é que tá no computador se tu tiver um tablet vê como é que tá no tablet ou tu usa lá o próprio mecanismo do Chrome para abrir né mesmo que talvez não funcione bem

né dessa forma mas enfim se tu tiver test se não tiver quem tiver tablet que se lasque mas testa testa tudo isso daí em produção antes de estudar isso como concluído sabe por quê eu eu entendo que muitas vezes pessoas vão diz mas já testei em Dev eu já testei na minha máquina já testei em Dev já testei homologação homologação funcionou a Tiazinha lá do k testou e funcionou também o código foi aprovado subir é muita chance de que é funciona em produção é mas não é 100% então para que tu vá dormir bem tranquilo

tá que tá tudo certo vai lá e olha tá testa e se tu encontrar bug é muito bom tá e eu eu sei que assim nunca é bom que tu encontre bug Mas é muito bom que tu seja cara que foi e olhou do começo ao fim da tua tarefa e se tu encontrou um bug lá tu chega e fala PR para alguém de techlead ou pro techlead né ou o po fala assim ó olha eu encontrei um bug lá que que vocês acham eu dou um Roll back né a gente volta essa alteração e

eu arrumo e depois subo de novo ou a gente abre um bug para resolver esse bug que eu né que eu subi lá enfim como é que a gente faz o cara muitas vezes ele vai falar assim poxa passou pelo meu code review eu vi que tava tudo certo eu testei tava tudo certo mas mesmo assim mesmo que de depois de todos esses Passos o desenvolvedor ainda se preocupou em ir lá em produção e testar Então isso é muito bom tá é muito bom que tu não encontre bug mas se tu encontrar é muito bom

que tu reporte isso e eles vejam que tu se interessa Tu realmente se se interessa pela empresa se interessa pela tarefa que tu pegou em ir até o fim testar lá no fim na ponta final para depois fechar a tarefa Beleza então sempre testem em produção e aí depois disso lembrem-se sempre de arrastar a tarefa lá no board tu tem um board de tarefas arrasta para concluir eu sempre esquecia os caras sempre ficavam Vitor sobe esse negócio arruma lá na bo eu sempre esquecia sempre mas cria um checklist coloquem lá no checklist esses passos e

no último arrastar a board concluindo tudo fecha Vai lá brincar com teu cachorro brincar com o teu gato levar Teu gato na escolinha de de gatos ou teu cachorro na escolinha de cachorros e vai ser feliz porque tu realmente entregou tua tarefa 100% e só um detalhe tá antes da gente finalizar quando você receber o código lá de alteração nunca chega pro sor ou chega para qualquer pessoa de forma ofendida por isso que eu falei não leva pro lado pessoal falando ai não faz sentido Não faz sentido is não faz sentido aquilo Porque se o

cara alterou alguma coisa é porque faz sentido se ele pediu alteração é porque faz sentido na maioria dos casos tá então então escuta o que o cara tem a dizer para depois tu dá a tua opinião e eu acho que tu até pode fazer uma abstinência de opinião não dá tua opinião por seis meses enquanto esver trabalhando lá se bota no teu lugar Tu é um Júnior Tu é um plor Tu é um Senor tu entrou na empresa faz tua tarefa e não fica enchendo o saco querendo fazer mudar isso mudar aquilo mudar aquilo outro

só encha no saco dos caras e cara vou te falar uma coisa tá se tu começa a criar tarefa para te fazer que não era tua tarefa e dá errado a culpa é tua se D certo ninguém vai ligar vamos falar ai que maravilhoso tá tudo certo mas se der errado é tu que vai ó tomar então não cria tarefas onde tu não precisa criar onde ninguém pediu faz a tua tarefa ali entrega 100% vai até o fim nos testes e é isso tu já é um ótimo desenvolvedor então recapitulando tá todos os passos de

forma rápida sempre revisa o que o po passou na tarefa para ver se a tua tarefa está atendendo depois disso testa em ambientes externos tá testa lá em Dev teste homologação testa em produção e tudo mais né Depois que tu entregar lá a ferramenta pronta vai lá em produção e testa e depois disso não leva pro lado pessoal os comentários lá no code review não leva pro lado pessoal testa lá em produção também arrasta a tarefa pra board e tudo vai funcionar anota as alterações que o revisor do teu código colocou e nas próximas vezes

toma cuidado com isso então é isso o link do curso também tá aqui na descrição lá eu ensino a fazer um code review eu ensino Cada passo desse aqui Como olhar essas tarefas e tudo mais como revisar essas tarefas antes que subir como conversar com os outros programadores como é o primeiro dia de trabalho como tu criar teu currículo como entrar de vaga tudo isso a gente ensina tem duas lives por semana comigo umas 2 horas mais ou menos inclusive amanhã eu vou ter 4 horas de Live das 6 até às 10 da noite com

os alunos revisando o currículo de cada um deles Beleza então é isso deixem o like aqui embaixo se inscrevam no canal também se quer chegar a 30.000 inscritos comentem aqui embaixo o que que já aconteceu em algum dos C reviews que vocês já fizeram tá e nos vemos