Aqui todo mundo revisa o código de todo mundo, desde um junior até pleno, assim todos aprendem, o importante é deixar bem claro os padrões a serem seguidos, assim evita um "troca troca" de formação de código e tudo o mais.
Mostra mais coisas de Git sim! Como Squash, Rebase, Merges, ... Mas fazendo um vídeo para cada comando, com explicação prática excelente que vocês sempre fazem!
Adotei para mim mesmo trabalhar com um único commit, assim evito problemas. Todavía existem pessoas que não trabalham dessa forma porém todos que utilizam Git deveriam saber utilizar squash, ammend e rebase. Por certo, excelente video!
oii gente! Esse ano eu termino o ensino médio e tenho interesse em fazer os cursos de ADS e Engenharia de Software... Se eu fizer ADS primeiro (por ter um retorno mais rápido financeiramente) e em seguida uma pós em Engenharia de Software, isso seria uma boa escolha?
Atualmente na empresa usamos o vídeo review e o SonarQube, vocês acham que poderíamos deixar todo o review para o SonarQube e liberar um programador dessa tarefa?
Só uma observação, code review é super importante, mas quando feito por profissionais, infelizmente tem muito zé (que até tem anos de profissão) mas os caras são complicadores e não revisores.. ai é um saco.
@@gregorifelicio6030 , exemplos em alguns cenários: 1. A lógica está toda certa e o "revisor" cisma com a forma como tu escreveu o fonte, claro se não for exagerandamente verboso ai cabe uma refatoração, mas como já vi em uma situação de um ex-colega, onde o revisor devolveu o código do cara só por que ele colocava abertura de chaves em if's de uma linha, desculpe, palhaçada, se a empresa não tem um documento de code style para os projetos, isso não faz sentido! 2. Já vi devolverem código, só por que o revisor não gostou como o dev estruturou as classes: "o cara complicou d+". Se criaram tantos padrões justamente para se poder ter opções para aplicar em determinada situação, e tu rejeitar esses padrões por que o revisor não gostou, bah, me desculpe, se não houve de fato um "over engineering" por parte do dev, que o revisor vá plantar batatas! 3. Outro cenário que presenciei é o revisor devolver um código por que ele entendeu errado a regra de negócio do cliente e criticou o fonte dizendo que estava errado! Ai te devolvo a pergunta: baseado nesses poucos cenários é ou não é complicar?
Eu já tenho feito alguns cursos de git, mas nunca tinha ouvido falar do Squash
Não conhecia esse Squash, gostaria de aprender. Ótimo vídeo!
Aqui todo mundo revisa o código de todo mundo, desde um junior até pleno, assim todos aprendem, o importante é deixar bem claro os padrões a serem seguidos, assim evita um "troca troca" de formação de código e tudo o mais.
Mostra mais coisas de Git sim! Como Squash, Rebase, Merges, ...
Mas fazendo um vídeo para cada comando, com explicação prática excelente que vocês sempre fazem!
Ótimo vídeo!
Voto num novo vídeo sobre git flow e/ou squash
Valeu!
Abraços!
Video sobre o squash por favor!!!!!!!!!!!!!
Adotei para mim mesmo trabalhar com um único commit, assim evito problemas.
Todavía existem pessoas que não trabalham dessa forma porém todos que utilizam Git deveriam saber utilizar squash, ammend e rebase.
Por certo, excelente video!
Sugestão: introduzir code review dentro de uma Sprint ágil, demonstrando a semana e etapas do ágil para desenvolvedores
Eba! Sugeri esse tema outro dia, mas tenho certeza de que já estão trabalhando nisso...kkkk Show pessoal!
Conteúdo muito bom! Fiquei muito interessado no Squash
Como sempre, excelente conteúdo. 👏👏
Muito obrigado Lucas! 🤓
Muito bom o vídeo. Será que posso chamar atenção para a pronúncia da palavra “commit” 😬!? Grata demais!
Ajudou muito essa explicação!!!
Gostaria de ver um vídeo sobre Squash. Não conheço.
Se puder, façam um video dentro do vscode falando sobre o css responsivo e o que e como fazer.
Fiquei curioso sobre o Squash.
Fala sobre o spring framework
Façam um vídeo sobre Ruby, ouvi dizer que está crescendo muito no mercado!! Ótimo vídeo!
Ótimo vídeo!
Adoraria aprender sobre o squash que mencionaram
Estava buscando isso faz tempo!
Muito bom ótimo video parabéns
Show!!!! Tentem fazer um vídeo sobre a plataforma da Cronapp, vale a pena.
Gostei do conteúdo que falaram no vídeo, code review é muito importante! Gostaria de saber sobre Squash :)
Genial! Parabéns pelo trabalho. ;)
acho uma boa o video de squash, não conhecia
Os Testes, ajuda Deverás!
Oi gente, no próximo 'Dicionário do programador' poderiam fazer sobre o PASCAL, acha uma linguagem muito legal de trabalhar!!
Bom pra caralho em.
Vídeo muito show!!! como sempre né...
Seria valido um vídeo sobre dicionário de dados? Ou talvez um mais abrangente como governança de dados?
=)
oii gente! Esse ano eu termino o ensino médio e tenho interesse em fazer os cursos de ADS e Engenharia de Software... Se eu fizer ADS primeiro (por ter um retorno mais rápido financeiramente) e em seguida uma pós em Engenharia de Software, isso seria uma boa escolha?
Adorei o vídeo! É recomendado um programador fazer o próprio code review? Abraços!
A ideia eh justamente que uma outra pessoa o faca, para que essa pessoa possa ter algo a agregar no seu codigo.
Eu diria que o próprio programador deve sim fazer o próprio code review, porém os outros devs também devem fazer, não somente você mesmo
UP para vídeo sobre git squash!
O desenvolvedor Python só precisa ler seu zen em tom de pergunta?
Atualmente na empresa usamos o vídeo review e o SonarQube, vocês acham que poderíamos deixar todo o review para o SonarQube e liberar um programador dessa tarefa?
Gostaria de um vídeo sobre testes em python com pytest, será que rola? Haha!
squash? flow?
Por favor, mostrem o vídeo do git squash
Só uma observação, code review é super importante, mas quando feito por profissionais, infelizmente tem muito zé (que até tem anos de profissão) mas os caras são complicadores e não revisores.. ai é um saco.
@@gregorifelicio6030 , exemplos em alguns cenários:
1. A lógica está toda certa e o "revisor" cisma com a forma como tu escreveu o fonte, claro se não for exagerandamente verboso ai cabe uma refatoração, mas como já vi em uma situação de um ex-colega, onde o revisor devolveu o código do cara só por que ele colocava abertura de chaves em if's de uma linha, desculpe, palhaçada, se a empresa não tem um documento de code style para os projetos, isso não faz sentido!
2. Já vi devolverem código, só por que o revisor não gostou como o dev estruturou as classes: "o cara complicou d+". Se criaram tantos padrões justamente para se poder ter opções para aplicar em determinada situação, e tu rejeitar esses padrões por que o revisor não gostou, bah, me desculpe, se não houve de fato um "over engineering" por parte do dev, que o revisor vá plantar batatas!
3. Outro cenário que presenciei é o revisor devolver um código por que ele entendeu errado a regra de negócio do cliente e criticou o fonte dizendo que estava errado!
Ai te devolvo a pergunta: baseado nesses poucos cenários é ou não é complicar?
"Mega blaster" hahahhahaha... cuidado Gabriel é capaz de vc lançar uma moda ai no mercado e frente aos RH's kkkkkkkkkkkkkkkk
Ele é carismático mas ela força a barra. Ele consegue ser natural.
6 "sobrinhos" não gostaram do vídeo... (entendedores entenderão rsrsrs)