já trabalhei em uma empresa que faz software para hospitais, tinham uns 600 devs, uns 400 módulos e zero testes, tinha tanto bug que quem resolvia tinha que apontar quem criou (com provas) pra pessoa ser penalizada e até impactar o PLR, ambiente bem saudável
Eu sofri com essa. Trabalhei uns tempos numa empresa onde comecei a questionar meus conhecimentos e no fim achei que minha participação foi um fracasso. O código dos caras que eram considerados senior era muito ruim. Era Java e tinha uns malditos códigos naquela maldita interface funcional cuja as funções viajavam por 4, 5 instâncias para produzir um resultado, conseguiram trazer o callback hell pro Java. No fim, eu acabei indo para um time muito mais evoluído onde tudo aquilo que aprendi sobre unit, e2e e integration tests, além de toda a parte de qualidade de código e code review, estavam corretas. E no fim, agora trabalho para uma empresa na califórnia.
kkkk, contou a história da empresa que atualmente estou empregado. Não sou um dos mais velhos na empresa, mas estou longe de ser um dos mais novos, e tive a proeza de conhecer e viver a evolução da empresa, do Kanban sem Testes para Scrum, onde cada equipe tem um QA. Era um desastre, não existia estimativas na época do Kanban, pois sempre voltava bugs e isso atrapalhava as entregas. Hoje em dia, como QA sou responsável dos testes manuais, testes de regressão manual e os testes automatizados e os Devs são responsáveis pelos testes unitários. Hoje, os POs chegam até ao pessoal de divulgação e falam uma estimativa e é entregue no dia ou até mesmo antes do dia estimado e tudo isso foi devido, simplesmente, por colocar TESTES!!
Analista QA a 4 anos aqui. Comecei em equipe de sustentação por 1 ano e meio, depois disso só peguei projetos de migração - a primeira do Delphi 7 pro 10.4 e a segunda um projeto web completo "renovando" (parafraseando o Sr. Akita) as tecnologias. A falta de Testes por parte de Dev foi e está sendo uma dor de cabeça. A parte boa? Nenhuma 😅 Como QA que estuda e assiste Fabio Akita (DEV) e Julio de Lima (QA) me deparei na obrigação de começar a trabalhar a qualidade do software dentro da equipe de desenvolvimento e por ser "junior" (pra carteira salarial) dificilmente fui escutado, mas aos poucos estamos melhorando. Resumo da opera: 1 - Eu vivi o gráfico apresentado no CAP 4 pelo Akita ou seja não é só teoria. (Não que eu duvide de você Sr. Akita kkkk) 2 - Metodologias Ágeis e Gestores "atrasados ou não-ágeis" é a mesma coisa que entregar um bom vinho na mão de quem só bebe TANG. 3 - Sim. Comece hoje. Com a task que você está fazendo agora. Isso fará diferença (no projeto, na sua carreira e no seu bolso) daqui um tempo. Não me venha com meu Gestor acha melhor não fazer... Fica a dia: 🤔Para algumas situações é mais fácil pedir desculpa que pedir pra fazer.
@@linusspiegel7470 Meu caro... É a pergunta de um milhão da maior cifra de dinheiro do momento kkkkk Não vou dizer que detenho o conhecimento nessa área de conhecimento, mas oque indico de começo para todos que querem saber sobre é o livro "Base de conhecimento em teste de software", não é o livro mais atualizado nos dias de hoje, porém lhe apresenta uma incrível panorâmica da área de forma sucinta e direta. Indico até mesmo para Devs, gerentes de projetos dentre outros. Digo que a partir do conhecimento recebido por esse livro você já começa a ter uma noção diferente ao olhar para um projeto e já pode começar como um bom "testador" sabendo de técnicas de testes que você pode ter em mente frente a cada tipo de aplicação. Daqui em diante é: - Lógica de Programação - Mínimo de HTML - Minimo de BD - Minimo de APIs - Estudar uma linguagem de programação robusta. Pra ser um Quality Assurance (QA) ao meu ver já vai ser experiencia com os projetos e equipes que você passar, sempre acompanhar pessoas como o Julio de Lima e outros no RUclips, Telegram, Instagram, Reedit e Medium. Ter uma vivencia e escutar palavras de um QA cria uma boa noção e uma intuição ao ver um pedaço de código/aplicação que precisa ser testado. Mas não há fuga: se lascar de ler e estudar, por em prática e procurar uma vaga e começar a trabalhar com isso já vai fazer a diferença e te obrigar a ir pra frente com os estudos pra alcançar maiores patamares. Não siga oque eu escrevi como uma formula, se aparecer algo que você precisa estudar pra entrar pra uma vaga ou até mesmo pro seu trabalho atual estude, mas estude de verdade, procurando entender o básico de tudo oque você estuda. Eu tenho o costume de chamar de a filosofia das coisas, a partir do momento que a base de algo está bem concretizada fica fácil de compreender várias outras coisas. Espero ter ajudado a dar um norte... Bons Estudos e um Ótimo Ano Novo!
Se puder dar dicas dos outros tipos de teste: integração, e2e, etc. Já estou confortável com testes unitários, mas não entendo muito bem os outros. Coisas como: - Como o conceito de cobertura se aplica; - qual métrica usar para saber se tem testes o suficiente; - erros comuns; - testes manuais ainda são usados?; - características exclusivas a back ou frontend.
Ótimo vídeo Akita, dois pontos importantes, faltou o 1 minuto de silêncio pela versão gratuita do heroku rsrsrs e eu tenho uma dica pros juniors ou iniciantes na área, peguem qualquer curso que aborda os algoritmos básicos, e tentem escrever testes pra eles, é um exercício bem simples, fácil de fazer, e ótimo pra entender como se deve pensar em um teste de unidade.
Amigos, sempre façam a auto crítica para não serem o mau elemento que o Akita mencionou. Muita responsabilidade com humildade para estar disposto a aprender a ser útil para a equipe/empresa.
"desenvolvedores são como arquitetos", perfeito isso, eu costumava comparar a artistas mas acho que fica bem próximo, adoro ver que você consegue colocar em vídeos o que eu sempre pensei, muito bom mesmo.
Eu passei por esse problema de estimativa, comecei como front-end mobile e fiquei full-stack no projeto que estou alocado, tenho apenas 6 meses de experiência como JR. Fui encubido de integrar o sistema de comprar no aplicativo da Apple e me pediram para prever o tempo que ia precisar, eu, ingenuamente, dei 1 sprint de 15 dias, já estamos na 5° sprint e só agora estou tendo progresso, todo o resto do tempo foi lendo documentação da Apple e pensando como eu iria abordar esse problema, várias tentativas e erros.
Akita, trabalhei por 4 anos em uma empresa aqui no interior de SP, Atibaia, simplesmente não existiam testes, pra nada literalmente, inclusive quase todo o código era em PHP estruturado, na mão. A empresa tinha mais de 20 anos de vida, os lideres não faziam ideia nem o que era teste de software, estavam parados na TI de 15, 20 anos atrás, inclusive mal conheciam a linguagem que era usada na empresa. O resumo da situação era que no melhor dos dias, 80% do tempo era corrigindo bugs causado por falta de teste e atendendo suporte por mais bugs pelo mesmo problema, as vezes sobrava um tempinho pra começar a programar algo novo, que era pra demorar dias pra ficar prontos mas como o tempo quase todo era destinado a corrigir bugs, uma funcionalidade ficava semanas pendente, algumas até eram esquecidas, de tão pouco tempo que tínhamos para programar, era literalmente um Go Horse. A pior parte era que pra gestão era isso mesmo, estava perfeito do jeito que estava e não queriam mudar, mesmo que isso gerasse hora extra toda semana pros Devs e pior, ainda queriam hora extra sem pagar por elas... Realmente, era o extremo do absurdo, nem sei como consegui ficar esse tempo todo.
A ideia de inexperiência e errar cedo é abordada no livro "Startup Enxuta", que é sobre negócios, mas escrito por um programador. Achei muito interessante a leitura, se aplica muito à nossa rotina de desenvolvimento.
Uma experiência massa que eu estou tendo é a de contribuir com projetos OSS, o padrão de qualidade é geralmente bem alto. Tudo bem documentado e testado, senão o maintainer nunca faz o Merge. Além disso, tem bastante espaço pra experimentar, eu crio umas branch nova com alguma ideia boba, trabalho nela por um tempinho, se eu achar que pode ser bom eu dou uma melhorada e compartilho com outros contribuidores, caso contrário, só deixo a branch lá, não faz diferença...
Bons tapas na cara na sociedade dev, obrigado. Eu queria um dia trabalhar contigo um período de tempo, só pra ser criticado por vc, aceitaria até ganhar bem menos que ganho hoje, só pra "crescer" mais junto do lado de vc e da sua equipe, na boa. Eu vivo cansado de trampar quase sempre sozinho, de trabalhar pra empresa e não em equipe ágil de verdade.
Meu projeto pro curso foi somente em tests units com Pytest (projeto individual), pegamos o projeto anterior que é uma API e fizemos disso só tests (proposta do projeto), o que acreditavamos estar funcionando, no fim, não passava de um monte de ilusão, bug atrás de bug, falha atrás de falha, mais de 60 tests eu realizei e apanhei até conseguir fazer funcionar e acredito que falta melhorar ainda, impossível acreditar que pensam que TDD é apenas "perca de tempo", pensamento lerdo! Perfeito vídeo Akita! Abraços
Quando eu era júnior me colocaram em um projeto onde tive q desenvolver boa parte de uma aplicação para compor um produto novo na empresa. Na época eu escrevia teste pra tudo no receio de fazer coisa errada e me mandarem embora na minha primeira experiência de trabalho. Aprendi bastante, acabei pegando vários erros cedo, mas não tinha noção q iria facilitar a minha vida e a de outros desenvolvedores quando precisamos adicionar novas funcionalidades na aplicação.
Fico feliz que depois de muito tempo comecei a entender um pouco melhor sobre a os vídeos do Akita, isso me motiva mais a estudar. Semana passada precisei apresentar um projeto de programação na faculdade, o engraçado é que a funcionalidade que eu havia implementado na última apresentação deixou de funcionar depois de adicionar as novas. A pior parte é que eu já sabia que existiam testes automatizados, mas decidi ignorar o trabalho extra e deu no que deu. A partir de hoje vou começar a implementar testes até em meus projetos pessoais para ganhar o hábito, também é chato testar as funcionalidades manualmente uma por uma, é comum eu pular as funcionalidades que eu acho que funcionam. Esse vídeo veio mesmo a calhar.
Como que alguém nao curte fazer testes? Comecei um estágio em Ruby on Rails e a primeira coisa que me falaram pra fazer: TESTES! To curtindo muito e acredito que seja a melhor forma de aprender toda a regra de negócio da empresa que estou.
Eu trabalho na aprte de banco de dados, ETL, Data Engineering. Quem souber de ferramentas de testes como essas que o Akita mostra para Front End, eu aceito recomendações. Pode ser português ou inglês. É importante garantir que nada vai impactar negativamente o trabalho do cliente. Muito bom vídeo.
41:50 isso se chama assertividade na comunicação: ser sincero e objetivo na informação a ser passada. Eu precisei fazer um curso para entender melhor esse ponto, mas desde que fiz estou colocando em prática diariamente e aprendendo sempre.
Acertou de novo, eu odiava fazer teste, não tinha paciência pra entender, na correria de produzir achava perda de tempo e a maioria do pessoal que trampava comigo tbm pensavam assim, então eu me sentia confortável com esse pensamento, depois de tanto fazer teste comecei a ver a quantidade de problemas que eu pegava nos códigos que eu escrevia e isso me ensinou a melhorar bastante a forma como eu escrevo código, no fim das contas hoje eu adoro fazer testes pq acho muito divertido ficar testando as possibilidades, ainda não sigo TDD (por falta de experiência), mas estou praticando esse formato conforme eu posso pra ganhar mais agilidade no processo.
27:43 exatamente!!! As pessoas tendem a negar e criticar aquilo que desconhecem, principalmente na nossa área. Já vi inúmeros casos disso e até hoje de vez em quando acontece.
A comparação de programadores com engenheiros/pedreiros/arquitetos é excelente! Sempre tive essa linha de pensamento, mas nunca consegui colocar em palavras claras de forma que os outros conseguissem entender essa ideia.
Eu entendo muito pouco de pc e seus trâmites, sei q esse canal foca mais nessa área de informática, mas graças a Deus encontrei esse canal pra fórmula minhas ideias ao redor desse assunto, e de quebra fórmula minhas ideias sobre gestão empresarial e tb gestão de pessoas, ideias diretas e objetivas, na minha humildade opinião seus melhores vídeos são esses sobre esses assuntos, pq, liga um assunto ao outro, e tipo uma ponte de uma coisa pra outra, faz gera interesse de um assunto pra outro, mesmo q vc não entenda nada do foco principal do canal
2 года назад
Na empresa que trabalho hoje o pessoal se preocupa muito com testes, justamente por isso, garantir minimamente que o que foi feito está funcionando, inclusive a pipeline barra códigos que tem menos de 80% de cobertura, recentemente tivemos uma reunião com o pessoal da equipe para discutir sobre a qualidade dos testes, para melhorar eles cada vez mais, muito esclarecedor esse vídeo, algumas das minhas dúvidas sobre gerenciamento de projetos foram sanadas, parabéns 👏👏
Muito legalAkita! Hoje o Masahiro Sakurai (Desenvolvedor de jogos) postou um vídeo em que ele diz praticamente a mesma coisa que você sobre a importância de fazer as coisas e documentar com equilíbrio, além de ter uma equipe que mantém um ritmo de trabalho que permite a evolução do projeto! Achei interessante como os vídeos se complementam!
Sem 'puxação' de saco mas foi um dos melhores conteúdos de fluxo de projetos de um software que eu já vi. Que conteúdo de valor cara! Impressionante. Você saí do vídeo se sentindo uma anta, mas ao mesmo tempo motivado a aprender e aplicar essas filosofias citadas. Muito bom mesmo! Parabéns e valeu pelo valor compartilhado aqui.
Nossa, foram vários tapas na cara e várias risadas. Obrigado por compartilhar um pouco desse conhecimento imenso que você possui mestre Akita. Forte abraço!
Queria ter esse vídeo há mais de uma década atrás pra mostrar pros professores de "engenharia de software" na faculdade! Como dizia um outro professor: "que faz engenharia de software é quem não sabe programar".
Excelente vídeo mais uma vez , parabéns. A única parte ruim do teste é quando ele não é contabilizado no tempo total da demanda , não aparece como parte essencial do projeto para o pessoal de negócio e executivos. As vezes dá trabalho e leva tempo fazer os cenários de testes e passar nas verificações. Combinando com todos , fica tudo certo.
Mas o pessoal do negócio sabe em quanto tempo uma funcionalidade leva sem testes? Eles precisam saber dos testes? Eles precisam saber a linguagem de programação que você está utilizando? Então. Faça a tua estimativa de quanto tempo vai levar para fazer a funcionalidade, incluindo tudo que for necessário, inclusive os testes. E repasse. Lá na frente quando o que você fez estiver dando pau porque não teve testes, ninguém de negócio vai querer saber não.
Mano, entrei na empresa, o onboarding levou 3 semanas por conta de gente entrando e saindo de férias e projetos começando praticamente do zero, vou te falar, a primeira tarefa que me passaram foi fazer testes, eu curti pra crlh aprender e meu pair programming foi super paciente em me explicar como funciona. Eu sei que vc falou pra fazer códigos gambiarrentos e sem testes nos projetos pessoais, mas estou começando a pensar em fazer neles pra justamente treinar a técnica e chegar mais preparado da próxima vez que rolar os testes.
Alguém traz um prêmio pra esse cara pf.... Fala as verdades diretas que muitos não querem enxergar ou tentam empurrar pra debaixo do tapete só pra enfeitar o projeto com confete.
Cara, eu fiz uma prova de conceito esses tempos. Twilio voice API e async queues. O Twilio trabalha sync e o cliente queria uma musiquinha enquanto a máquina de estados doida dele trabalhava (fazendo trilhões de queries no postgresql, nem vou entrar no detalhe de que faltava visão para uma maquina de estados com storage in memory e cache in memory). Foi uma baita POC, no fim ficou top e o cliente ficou impressionado com a estrutura: twilio -> webhook -> twilio (on hold) -> sqs -> twilio rest API -> twilio -> webhook E tá em produção agora. E eu e minha teimosia, nesse caso eu que teimei com os americanos que tinha que sair essa poc antes de dizer, e ainda lutei com o tech lead (acabaram me colocando no lugar dele depois disso), porque ele teimava que dava pra fazer pelo fluxo sync do twilio, mas os TWML commands são sequencias e sync.
Amei esse video ,e vi nele todos os erros que já cometi e possivelmente vou cometer, serei uma eterna aprendiz kkk esses vídeos me ajudam tanto a aprender e a cair na realidade 👏🏽a estrada é longa ,mas eu chego lá !!!
Sempre lembro das empresas que trabalhei e como todas elas sempre usam metodologias mágicas focado apenas em entregas, mas nunca leva em consideração a melhora do fluxo e da entrega. E toda vez que a merda acontece o programador é o culpado e quando você tenta explicar a necessidade de testes ou de melhorias o GP ou cliente começa a chorar a questão de entregas menores ou que isso não agrega valor. Queria que um cara desses estivesse assistindo esse tipo de vídeo. Lógico que irão dizer que não tem tempo pq eles nunca tem.
Vou falar antes de assistir o vídeo (tenho quase certeza q o akita vai abordar isso no video): Testes: Fazendo antes (com o TDD) ou depois, não interessa, só faça e garanta a cobertura mínima !
Concordo parcialmente. Claro que a qualidade vem com o tempo, mas, testes mal feitos não garantem nada e só olhar cobertura não garante qualidade. "Faça testes antes ou depois, garanta que o que você escreveu esteja corretamente testado e coberto" seria o correto na minha visão
É impressionante como o mestre Akita é assertivo, absolutamente tudo que o senhor falou é exatamente como falou, desde os merda que não querem testar e passam mais de 50% da sprint correndo atrás do próprio rabo, até os outros merdas que ficam com bullshit motivacional de statup sem nunca na vida ter entregado um projeto de sucesso, a parte dos POC foi linda também, mais uma vez vou usar um video seu para dar paulada nos bosta aqui dos projetos KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
Excelente vídeo, mais uma vez. Quero a oportunidade trabalhar com você algum dia. Senti um alívio quando vi que eu já praticava a maioria dessas coisas, as vezes bate um desânimo por questionamentos de gerentes, mas o processo continua e o foco é no longo prazo. Obrigado
Eu não tenho como descrever o quanto os seus vídeos agregam valor e são únicos, Akita. Muitas vezes nas aulas do meu curso de CC fico discutindo com os professores sobre temas que aprendi e/ou revisei vendo os conteúdos que você posta. Hoje em dia eu tenho muito mais confiança e sinto muito mais orgulho de ser programador e (futuro) cientista da computação graças a você. Domo arigatou Akita-san!
O que eu acho mais triste é a quantidade de pessoas querendo burlar o Sonar, teste e outras ferramentas que tentam ajudar a manter a qualidade porque vão gastar tempo, mas gastam meses para reinventar a roda, porque querem utilizar uma "solução única" que vai performar pior do que um conjunto de soluções. Ótimo video.
Akita, você é cirurgico em tudo o que fala. Em 10 minutos iniciais vc descreveu o que estou vivendo em na empresa em que trabalho. Spoiler: esta dando tudo errado.
Muito bom o vídeo. Eu trabalho na parte de suporte e sofro bastante quando tem atualização do sistema, olha que isso de seguir procedimentos burocrático na mairia das vezes é tipo dar água com açúcar para quem está resfriado.
Trabalhei em um projeto que tinha sido criado por estagiários / júniors em Flutter, que na época ainda estava nas fraldas e não tinha padrão de codificação algum (ainda não tem), e a pessoa mais sênior desse projeto mexia com iOS nativo (que por sua vez tem uma forma única de se trabalhar, que não se aplica ao Flutter). Então, um dia os stakeholders decidiram que queriam ter 100% de cobertura de testes no projeto. Entretanto, o projeto parecia o Morgott do Elden Ring, caindo aos pedaços. Onde mexia, quebrava todo o resto. Quando entrei e vi aquela situação, minha primeira opção foi fazer uma versão mais profissional do projeto, usando uma arquitetura bem definida e TDD, afinal, o projeto não era tão complexo assim, não passava de algumas requisições a algumas APIs e navegação entre telas. O time não quis dar o braço a torcer e aceitar a minha sugestão, preferiram tentar fazer testes unitários em um projeto acoplado, mesmo sem ter noção de como se faz testes unitários. Um curso ou livro realmente não ensina como fazer testes, apenas a própria prática. E foi exatamente isso que eu vi, os testes estavam lá somente para alcançar a "cobertura" de 100%, mas eles eram tão simples que nem faziam sentido existir. Só existiam testes que faziam o caminho feliz, e os erros continuavam a acontecer
Esses vídeos rated são de lavar a alma. É exatamente como o akita disse quando você vê que ninguém tá ligando para o projeto as pessoas que entram depois sentem-se forçadas a ligar o foda-se também, ou isso ou você mete o pé
Fiz uma pergunta sobre BDD num outro vídeo, mas acho que aqui responde um pouco. Mas vou assistir assistir mais uma vez e ver se entendi direito. Obrigado!
Quando ouço algo como nos exemplos, me recordo do meme do Pica-Pau: "Essa gente inventa cada coisa"!!! Excelente Rant (fiquei confuso se um rant bom é um bom rant ou ao contrário... kkkkkkk)!!!
Precisamos de 8-11 pessoas para um projeto, 12 mil de salário fora benefícios. 154 entrevistas e onde estão bons programadores é um mistério. Teve gente que não conseguiu gerar uma função (o candidato poderia escolher a linguagem) para bloquear IPs já listados como spammers ou de países que não interessa ao público alvo. Se enrolam com GIT e aí já pode desistir. 😢
em "return to space" da netflix fica muito claro que desenvolvimento by tests é o que fez a SpaceX ser o que é, os caras tudo e depois corrigiam as arestas
Gostei do comentário quanto à estimativas. Onde mais penei foi mantendo um BAITA plugin de Blender, e já cheguei a dizer que não sabia quanto tempo iria demorar pra entregar a functionalidade, que em duas semanas teria alguma coisa, levou um mês. Mas diga-se de passagem essa nova funcionalidade fez toda a diferença no software.
"Toda burocracia em excesso é defendida por aqueles que não sabem o que estão fazendo." Esse é um dos maiores problemas que vejo hoje - pessoas que não entendem nada de desenvolvimento de software criando processos que mais atrasam do que trazem benefício.
Se tem vídeo do Akita tem like, e se tem RANT tem like duplo! Pena que o RUclips não deixa dar like duplo, então tem mais views e share no grupo do zap!
Parabéns por esse vídeo Fábio A. tá mais "humano" e menos hardcore rrrsss, essa parte de gestão de pessoas e procedimentos é o que anda faltando nas empresas como um todo, não há inovação apenas mais do mesmo, esse vídeo foi um choque de realidade para todos esses mesmos da cultura do tudo igual! Valeeuu
Uma sugestão para complementar o video seria algo sobre os flaky tests: testes de integração frágeis (por cagada de mal implementação) que rodam de forma paralela e sujam os ambientes entre si
"Se compila não precisa de testes" kkkkkkkkkkk. Nunca tinha ouvido essa desculpa antes. Para alguém que fala isso realmente não precisa de testes porque ele nem sabe pra que testes devem ser feitos. Como sempre, ótimo vídeo!
PQP, vou ter que comentar novamente. O Akita ta puto nesse video como nunca antes em video algum hahhahahaha... Adoro, sempre nos ajudando a nos tornarmos melhores!
Antes desse vídeo já tinha começado a estudar Jest pra fazer testes com React Native, mas tava muito na dúvida do QUE exatamente testar dentro do código. Agora depois de assistir vou simplesmente testar qualquer coisa. Depois eu apago essas merda e faço melhor já sabendo no que errei. 😹
já trabalhei em uma empresa que faz software para hospitais, tinham uns 600 devs, uns 400 módulos e zero testes, tinha tanto bug que quem resolvia tinha que apontar quem criou (com provas) pra pessoa ser penalizada e até impactar o PLR, ambiente bem saudável
Que lindo🥰
Eu sei qual empresa que é kkkkk... Comando e controle fortíssimo lá...
@@andregarciagp Também sei 🤣🤣🤣🤣
Eu tbm sei, mas fala aí o nome haha
Também sei pow, fala aí qual é que eu falo se é mesmo a que tou pensando.
Eu sofri com essa. Trabalhei uns tempos numa empresa onde comecei a questionar meus conhecimentos e no fim achei que minha participação foi um fracasso. O código dos caras que eram considerados senior era muito ruim. Era Java e tinha uns malditos códigos naquela maldita interface funcional cuja as funções viajavam por 4, 5 instâncias para produzir um resultado, conseguiram trazer o callback hell pro Java. No fim, eu acabei indo para um time muito mais evoluído onde tudo aquilo que aprendi sobre unit, e2e e integration tests, além de toda a parte de qualidade de código e code review, estavam corretas. E no fim, agora trabalho para uma empresa na califórnia.
kkkk, contou a história da empresa que atualmente estou empregado. Não sou um dos mais velhos na empresa, mas estou longe de ser um dos mais novos, e tive a proeza de conhecer e viver a evolução da empresa, do Kanban sem Testes para Scrum, onde cada equipe tem um QA. Era um desastre, não existia estimativas na época do Kanban, pois sempre voltava bugs e isso atrapalhava as entregas. Hoje em dia, como QA sou responsável dos testes manuais, testes de regressão manual e os testes automatizados e os Devs são responsáveis pelos testes unitários. Hoje, os POs chegam até ao pessoal de divulgação e falam uma estimativa e é entregue no dia ou até mesmo antes do dia estimado e tudo isso foi devido, simplesmente, por colocar TESTES!!
Onde manda currículo? hahahhaahhahah
Analista QA a 4 anos aqui.
Comecei em equipe de sustentação por 1 ano e meio, depois disso só peguei projetos de migração - a primeira do Delphi 7 pro 10.4 e a segunda um projeto web completo "renovando" (parafraseando o Sr. Akita) as tecnologias. A falta de Testes por parte de Dev foi e está sendo uma dor de cabeça. A parte boa? Nenhuma 😅 Como QA que estuda e assiste Fabio Akita (DEV) e Julio de Lima (QA) me deparei na obrigação de começar a trabalhar a qualidade do software dentro da equipe de desenvolvimento e por ser "junior" (pra carteira salarial) dificilmente fui escutado, mas aos poucos estamos melhorando.
Resumo da opera:
1 - Eu vivi o gráfico apresentado no CAP 4 pelo Akita ou seja não é só teoria. (Não que eu duvide de você Sr. Akita kkkk)
2 - Metodologias Ágeis e Gestores "atrasados ou não-ágeis" é a mesma coisa que entregar um bom vinho na mão de quem só bebe TANG.
3 - Sim. Comece hoje. Com a task que você está fazendo agora. Isso fará diferença (no projeto, na sua carreira e no seu bolso) daqui um tempo.
Não me venha com meu Gestor acha melhor não fazer... Fica a dia:
🤔Para algumas situações é mais fácil pedir desculpa que pedir pra fazer.
@@linusspiegel7470 Meu caro... É a pergunta de um milhão da maior cifra de dinheiro do momento kkkkk Não vou dizer que detenho o conhecimento nessa área de conhecimento, mas oque indico de começo para todos que querem saber sobre é o livro "Base de conhecimento em teste de software", não é o livro mais atualizado nos dias de hoje, porém lhe apresenta uma incrível panorâmica da área de forma sucinta e direta. Indico até mesmo para Devs, gerentes de projetos dentre outros.
Digo que a partir do conhecimento recebido por esse livro você já começa a ter uma noção diferente ao olhar para um projeto e já pode começar como um bom "testador" sabendo de técnicas de testes que você pode ter em mente frente a cada tipo de aplicação.
Daqui em diante é:
- Lógica de Programação
- Mínimo de HTML
- Minimo de BD
- Minimo de APIs
- Estudar uma linguagem de programação robusta.
Pra ser um Quality Assurance (QA) ao meu ver já vai ser experiencia com os projetos e equipes que você passar, sempre acompanhar pessoas como o Julio de Lima e outros no RUclips, Telegram, Instagram, Reedit e Medium. Ter uma vivencia e escutar palavras de um QA cria uma boa noção e uma intuição ao ver um pedaço de código/aplicação que precisa ser testado.
Mas não há fuga: se lascar de ler e estudar, por em prática e procurar uma vaga e começar a trabalhar com isso já vai fazer a diferença e te obrigar a ir pra frente com os estudos pra alcançar maiores patamares.
Não siga oque eu escrevi como uma formula, se aparecer algo que você precisa estudar pra entrar pra uma vaga ou até mesmo pro seu trabalho atual estude, mas estude de verdade, procurando entender o básico de tudo oque você estuda. Eu tenho o costume de chamar de a filosofia das coisas, a partir do momento que a base de algo está bem concretizada fica fácil de compreender várias outras coisas.
Espero ter ajudado a dar um norte... Bons Estudos e um Ótimo Ano Novo!
"não sua múmia paralítica..."
Eu cuspi água com essa! 😅
Se puder dar dicas dos outros tipos de teste: integração, e2e, etc.
Já estou confortável com testes unitários, mas não entendo muito bem os outros. Coisas como:
- Como o conceito de cobertura se aplica;
- qual métrica usar para saber se tem testes o suficiente;
- erros comuns;
- testes manuais ainda são usados?;
- características exclusivas a back ou frontend.
Ótimo vídeo Akita, dois pontos importantes, faltou o 1 minuto de silêncio pela versão gratuita do heroku rsrsrs e eu tenho uma dica pros juniors ou iniciantes na área, peguem qualquer curso que aborda os algoritmos básicos, e tentem escrever testes pra eles, é um exercício bem simples, fácil de fazer, e ótimo pra entender como se deve pensar em um teste de unidade.
Qualquer algoritmo vc diz de estrutura de dado? Tipo um fila qualquer da vida? Achei interessante a ideia
@@soul6858 Acredito que ele quis dizer qualquer algoritmo mesmo, não necessariamente estrutura de dados, por exemplo Bubble sort, factorial, etc
@@soul6858Algorítimos sobre estruturas de dados.
Ordenar uma lista, atravessar uma árvore binária, inserir e remover de uma heap etc.
Amigos, sempre façam a auto crítica para não serem o mau elemento que o Akita mencionou. Muita responsabilidade com humildade para estar disposto a aprender a ser útil para a equipe/empresa.
Melhor canal de TI do Brasil ♥
Poderia me indicar alguns canais de T.I gringos? Sobre coisas Técnicas e Carreiras. Obrigado
Canal do Mano Deyvim é muito melhor. Pronto falei.
@@Bitnator Foi esse cara que falou que gitflow é muito?
"desenvolvedores são como arquitetos", perfeito isso, eu costumava comparar a artistas mas acho que fica bem próximo, adoro ver que você consegue colocar em vídeos o que eu sempre pensei, muito bom mesmo.
"A plata baixa é o código fonte" 👏🏼
Eu passei por esse problema de estimativa, comecei como front-end mobile e fiquei full-stack no projeto que estou alocado, tenho apenas 6 meses de experiência como JR. Fui encubido de integrar o sistema de comprar no aplicativo da Apple e me pediram para prever o tempo que ia precisar, eu, ingenuamente, dei 1 sprint de 15 dias, já estamos na 5° sprint e só agora estou tendo progresso, todo o resto do tempo foi lendo documentação da Apple e pensando como eu iria abordar esse problema, várias tentativas e erros.
Akita, trabalhei por 4 anos em uma empresa aqui no interior de SP, Atibaia, simplesmente não existiam testes, pra nada literalmente, inclusive quase todo o código era em PHP estruturado, na mão. A empresa tinha mais de 20 anos de vida, os lideres não faziam ideia nem o que era teste de software, estavam parados na TI de 15, 20 anos atrás, inclusive mal conheciam a linguagem que era usada na empresa. O resumo da situação era que no melhor dos dias, 80% do tempo era corrigindo bugs causado por falta de teste e atendendo suporte por mais bugs pelo mesmo problema, as vezes sobrava um tempinho pra começar a programar algo novo, que era pra demorar dias pra ficar prontos mas como o tempo quase todo era destinado a corrigir bugs, uma funcionalidade ficava semanas pendente, algumas até eram esquecidas, de tão pouco tempo que tínhamos para programar, era literalmente um Go Horse.
A pior parte era que pra gestão era isso mesmo, estava perfeito do jeito que estava e não queriam mudar, mesmo que isso gerasse hora extra toda semana pros Devs e pior, ainda queriam hora extra sem pagar por elas... Realmente, era o extremo do absurdo, nem sei como consegui ficar esse tempo todo.
Atibaia? Putz eu nasci em Piracaia kkkkk
A ideia de inexperiência e errar cedo é abordada no livro "Startup Enxuta", que é sobre negócios, mas escrito por um programador. Achei muito interessante a leitura, se aplica muito à nossa rotina de desenvolvimento.
Uma experiência massa que eu estou tendo é a de contribuir com projetos OSS, o padrão de qualidade é geralmente bem alto. Tudo bem documentado e testado, senão o maintainer nunca faz o Merge.
Além disso, tem bastante espaço pra experimentar, eu crio umas branch nova com alguma ideia boba, trabalho nela por um tempinho, se eu achar que pode ser bom eu dou uma melhorada e compartilho com outros contribuidores, caso contrário, só deixo a branch lá, não faz diferença...
Bons tapas na cara na sociedade dev, obrigado.
Eu queria um dia trabalhar contigo um período de tempo, só pra ser criticado por vc, aceitaria até ganhar bem menos que ganho hoje, só pra "crescer" mais junto do lado de vc e da sua equipe, na boa. Eu vivo cansado de trampar quase sempre sozinho, de trabalhar pra empresa e não em equipe ágil de verdade.
Meu projeto pro curso foi somente em tests units com Pytest (projeto individual), pegamos o projeto anterior que é uma API e fizemos disso só tests (proposta do projeto), o que acreditavamos estar funcionando, no fim, não passava de um monte de ilusão, bug atrás de bug, falha atrás de falha, mais de 60 tests eu realizei e apanhei até conseguir fazer funcionar e acredito que falta melhorar ainda, impossível acreditar que pensam que TDD é apenas "perca de tempo", pensamento lerdo!
Perfeito vídeo Akita! Abraços
Ótimo vídeo! Qualidade NÃO se negocia, tem que ter testes e VAI demorar mais para fazer. Depois de muita hora extra que se aprende essas coisas....
Fazia anos que não ouvia alguém dizer "Múmia paralitica" huaehuaehuae...
ótimo vídeo!
Curto muito esses RANTs, compactuo com várias coisas mesmo sendo júnior.
Quando eu era júnior me colocaram em um projeto onde tive q desenvolver boa parte de uma aplicação para compor um produto novo na empresa. Na época eu escrevia teste pra tudo no receio de fazer coisa errada e me mandarem embora na minha primeira experiência de trabalho. Aprendi bastante, acabei pegando vários erros cedo, mas não tinha noção q iria facilitar a minha vida e a de outros desenvolvedores quando precisamos adicionar novas funcionalidades na aplicação.
Esses vídeos Rated-R do Akita são uma obra prima. Você simplesmente fala todas as verdades sem ligar em ser 'politicamente correto'
Que aula! Verdades que todo profissional de desenvolvimento deve defender.
Fala Fabio, Tente ir no Ciencia sem fim do Sergio Sacani, seria muito interessante !
.
Agreed
Meu sonho akita lá
Fico feliz que depois de muito tempo comecei a entender um pouco melhor sobre a os vídeos do Akita, isso me motiva mais a estudar.
Semana passada precisei apresentar um projeto de programação na faculdade, o engraçado é que a funcionalidade que eu havia implementado na última apresentação deixou de funcionar depois de adicionar as novas. A pior parte é que eu já sabia que existiam testes automatizados, mas decidi ignorar o trabalho extra e deu no que deu.
A partir de hoje vou começar a implementar testes até em meus projetos pessoais para ganhar o hábito, também é chato testar as funcionalidades manualmente uma por uma, é comum eu pular as funcionalidades que eu acho que funcionam. Esse vídeo veio mesmo a calhar.
Igual a musculação, as "pancadas" do Akita doem mas fazem você crescer e desenvolver.
Obrigado, mestre.
Reassistindo aqui depois de passar por alguns desses problemas na prática. Mais um ótimo vídeo pra nos ajudar nos nossos perrengues. Valeu Akita!!
Como que alguém nao curte fazer testes? Comecei um estágio em Ruby on Rails e a primeira coisa que me falaram pra fazer: TESTES! To curtindo muito e acredito que seja a melhor forma de aprender toda a regra de negócio da empresa que estou.
Este vídeo me fez lembrar do princípio de Pareto. 20% codificando, 80% ajustando bugs criados nos 20% de desenvolvimento. :)
Eu trabalho na aprte de banco de dados, ETL, Data Engineering.
Quem souber de ferramentas de testes como essas que o Akita mostra para Front End, eu aceito recomendações. Pode ser português ou inglês.
É importante garantir que nada vai impactar negativamente o trabalho do cliente. Muito bom vídeo.
41:50 isso se chama assertividade na comunicação: ser sincero e objetivo na informação a ser passada. Eu precisei fazer um curso para entender melhor esse ponto, mas desde que fiz estou colocando em prática diariamente e aprendendo sempre.
Rapaz não tem ninguem que dá mais esporro (falar a verdade) que este cara. Muito bom. Parabéns. Agora vou para o Gentoo.
Acertou de novo, eu odiava fazer teste, não tinha paciência pra entender, na correria de produzir achava perda de tempo e a maioria do pessoal que trampava comigo tbm pensavam assim, então eu me sentia confortável com esse pensamento, depois de tanto fazer teste comecei a ver a quantidade de problemas que eu pegava nos códigos que eu escrevia e isso me ensinou a melhorar bastante a forma como eu escrevo código, no fim das contas hoje eu adoro fazer testes pq acho muito divertido ficar testando as possibilidades, ainda não sigo TDD (por falta de experiência), mas estou praticando esse formato conforme eu posso pra ganhar mais agilidade no processo.
27:43 exatamente!!! As pessoas tendem a negar e criticar aquilo que desconhecem, principalmente na nossa área. Já vi inúmeros casos disso e até hoje de vez em quando acontece.
Fábio,. gosto muito do seu jeito de comunicar. Vc é muito bom nisso! Simples, claro e direto. Sem meias palavras.
Já estava com saudade de ver um vídeo do Akita!!! Como sempre, conteúdo de qualidade.
A comparação de programadores com engenheiros/pedreiros/arquitetos é excelente!
Sempre tive essa linha de pensamento, mas nunca consegui colocar em palavras claras de forma que os outros conseguissem entender essa ideia.
Eu entendo muito pouco de pc e seus trâmites, sei q esse canal foca mais nessa área de informática, mas graças a Deus encontrei esse canal pra fórmula minhas ideias ao redor desse assunto, e de quebra fórmula minhas ideias sobre gestão empresarial e tb gestão de pessoas, ideias diretas e objetivas, na minha humildade opinião seus melhores vídeos são esses sobre esses assuntos, pq, liga um assunto ao outro, e tipo uma ponte de uma coisa pra outra, faz gera interesse de um assunto pra outro, mesmo q vc não entenda nada do foco principal do canal
Na empresa que trabalho hoje o pessoal se preocupa muito com testes, justamente por isso, garantir minimamente que o que foi feito está funcionando, inclusive a pipeline barra códigos que tem menos de 80% de cobertura, recentemente tivemos uma reunião com o pessoal da equipe para discutir sobre a qualidade dos testes, para melhorar eles cada vez mais, muito esclarecedor esse vídeo, algumas das minhas dúvidas sobre gerenciamento de projetos foram sanadas, parabéns 👏👏
Muito legalAkita! Hoje o Masahiro Sakurai (Desenvolvedor de jogos) postou um vídeo em que ele diz praticamente a mesma coisa que você sobre a importância de fazer as coisas e documentar com equilíbrio, além de ter uma equipe que mantém um ritmo de trabalho que permite a evolução do projeto! Achei interessante como os vídeos se complementam!
Sem 'puxação' de saco mas foi um dos melhores conteúdos de fluxo de projetos de um software que eu já vi. Que conteúdo de valor cara! Impressionante. Você saí do vídeo se sentindo uma anta, mas ao mesmo tempo motivado a aprender e aplicar essas filosofias citadas. Muito bom mesmo! Parabéns e valeu pelo valor compartilhado aqui.
Eu ganho meu dia quando tem video de Rant do Akita, melhor relaçao de humor x tapas na cara
Nossa, foram vários tapas na cara e várias risadas. Obrigado por compartilhar um pouco desse conhecimento imenso que você possui mestre Akita. Forte abraço!
Queria ter esse vídeo há mais de uma década atrás pra mostrar pros professores de "engenharia de software" na faculdade!
Como dizia um outro professor: "que faz engenharia de software é quem não sabe programar".
Excelente vídeo mais uma vez , parabéns. A única parte ruim do teste é quando ele não é contabilizado no tempo total da demanda , não aparece como parte essencial do projeto para o pessoal de negócio e executivos. As vezes dá trabalho e leva tempo fazer os cenários de testes e passar nas verificações. Combinando com todos , fica tudo certo.
Mas o pessoal do negócio sabe em quanto tempo uma funcionalidade leva sem testes? Eles precisam saber dos testes? Eles precisam saber a linguagem de programação que você está utilizando? Então. Faça a tua estimativa de quanto tempo vai levar para fazer a funcionalidade, incluindo tudo que for necessário, inclusive os testes. E repasse.
Lá na frente quando o que você fez estiver dando pau porque não teve testes, ninguém de negócio vai querer saber não.
Mano, entrei na empresa, o onboarding levou 3 semanas por conta de gente entrando e saindo de férias e projetos começando praticamente do zero, vou te falar, a primeira tarefa que me passaram foi fazer testes, eu curti pra crlh aprender e meu pair programming foi super paciente em me explicar como funciona. Eu sei que vc falou pra fazer códigos gambiarrentos e sem testes nos projetos pessoais, mas estou começando a pensar em fazer neles pra justamente treinar a técnica e chegar mais preparado da próxima vez que rolar os testes.
Ele falou brincando cara🙃. Mas, se você tiver que fazer, faça nos seus. 🙂
@@JosueBarbosadosSantos mas eu deixei bem claro que é nós projetos pessoais kkkk
Finalmente um vídeo do Akita pra fazer eu perder a preguiça de estudar mais sobre TDD kkkk
Alguém traz um prêmio pra esse cara pf.... Fala as verdades diretas que muitos não querem enxergar ou tentam empurrar pra debaixo do tapete só pra enfeitar o projeto com confete.
Cara, eu fiz uma prova de conceito esses tempos. Twilio voice API e async queues. O Twilio trabalha sync e o cliente queria uma musiquinha enquanto a máquina de estados doida dele trabalhava (fazendo trilhões de queries no postgresql, nem vou entrar no detalhe de que faltava visão para uma maquina de estados com storage in memory e cache in memory). Foi uma baita POC, no fim ficou top e o cliente ficou impressionado com a estrutura:
twilio -> webhook -> twilio (on hold)
-> sqs -> twilio rest API -> twilio -> webhook
E tá em produção agora.
E eu e minha teimosia, nesse caso eu que teimei com os americanos que tinha que sair essa poc antes de dizer, e ainda lutei com o tech lead (acabaram me colocando no lugar dele depois disso), porque ele teimava que dava pra fazer pelo fluxo sync do twilio, mas os TWML commands são sequencias e sync.
Amei esse video ,e vi nele todos os erros que já cometi e possivelmente vou cometer, serei uma eterna aprendiz kkk
esses vídeos me ajudam tanto a aprender e a cair na realidade 👏🏽a estrada é longa ,mas eu chego lá !!!
Sempre lembro das empresas que trabalhei e como todas elas sempre usam metodologias mágicas focado apenas em entregas, mas nunca leva em consideração a melhora do fluxo e da entrega. E toda vez que a merda acontece o programador é o culpado e quando você tenta explicar a necessidade de testes ou de melhorias o GP ou cliente começa a chorar a questão de entregas menores ou que isso não agrega valor. Queria que um cara desses estivesse assistindo esse tipo de vídeo. Lógico que irão dizer que não tem tempo pq eles nunca tem.
não tem tempo pq eles ficam "consertando" as cagadas que eles mesmos fazer. clássico
"Cresce e aja como profissional" 👏👏Tô num loop infinito nos vídeos do Akita
Eu tava um tempão sem assistir aos vídeos do Akita... No título eu já sabia que vinha tiro , porrada e bomba, tudo normal! The Best 🔥
Precisava desse vídeo, sempre bom esses puxões de orelha do mestre Akita pra rever minha mentalidade e evoluir
Muito bom o vídeo. Lembrando para o pessoal que testes andam junto com refatoração, ainda mais em código legado (sem testes ou com pouco testes).
Vou falar antes de assistir o vídeo (tenho quase certeza q o akita vai abordar isso no video):
Testes: Fazendo antes (com o TDD) ou depois, não interessa, só faça e garanta a cobertura mínima !
Concordo parcialmente. Claro que a qualidade vem com o tempo, mas, testes mal feitos não garantem nada e só olhar cobertura não garante qualidade.
"Faça testes antes ou depois, garanta que o que você escreveu esteja corretamente testado e coberto" seria o correto na minha visão
@@innervision4484 verdade. Já vi muitos testes que cobrem 90% do código, mas só para passar na esteira, pq são testes de bosta. Não testam de verdade.
É impressionante como o mestre Akita é assertivo, absolutamente tudo que o senhor falou é exatamente como falou, desde os merda que não querem testar e passam mais de 50% da sprint correndo atrás do próprio rabo, até os outros merdas que ficam com bullshit motivacional de statup sem nunca na vida ter entregado um projeto de sucesso, a parte dos POC foi linda também, mais uma vez vou usar um video seu para dar paulada nos bosta aqui dos projetos KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
Arrebentou! Esse é de longe o seu vídeo menos polêmico. Impossível discordar de qualquer coisa. 😂 Está tudo 💯 porcento perfeito. 👏 👏 👏
Sensacional. Akita parabéns por compartilhar essa experiência. Inspirador esse vídeo para muitas pessoas.
Compartilhando esse vídeo com a equipe. Muito bom!!!!
Irq preciso melhorar, obrigado pela sinceridade, com certeza irei correr atrás.
Excelente vídeo, mais uma vez.
Quero a oportunidade trabalhar com você algum dia.
Senti um alívio quando vi que eu já praticava a maioria dessas coisas, as vezes bate um desânimo por questionamentos de gerentes, mas o processo continua e o foco é no longo prazo.
Obrigado
Eu não tenho como descrever o quanto os seus vídeos agregam valor e são únicos, Akita. Muitas vezes nas aulas do meu curso de CC fico discutindo com os professores sobre temas que aprendi e/ou revisei vendo os conteúdos que você posta. Hoje em dia eu tenho muito mais confiança e sinto muito mais orgulho de ser programador e (futuro) cientista da computação graças a você. Domo arigatou Akita-san!
O que eu acho mais triste é a quantidade de pessoas querendo burlar o Sonar, teste e outras ferramentas que tentam ajudar a manter a qualidade porque vão gastar tempo, mas gastam meses para reinventar a roda, porque querem utilizar uma "solução única" que vai performar pior do que um conjunto de soluções.
Ótimo video.
Akita, você é cirurgico em tudo o que fala. Em 10 minutos iniciais vc descreveu o que estou vivendo em na empresa em que trabalho. Spoiler: esta dando tudo errado.
Não se sinta só, 90% das empresas de T.I do Brasil são assim
Muito bom o vídeo. Eu trabalho na parte de suporte e sofro bastante quando tem atualização do sistema, olha que isso de seguir procedimentos burocrático na mairia das vezes é tipo dar água com açúcar para quem está resfriado.
vai para area de QA, vai ganhar 3x mais, os melhores QAs vieram do suporte.
eiiiiiiiita porr@, já sei tudo o que vou dizer na próxima review/planning hahaha
Excelente video. Sou da área de engenharia e da para aproveitar muito o conteúdo.
Hahahahaha “pra vc que usa o VS pra fazer seus códigos porcaria” 😂 Akita é foda sempre lançando a braba
Akita, faz um vídeo falando sobre a regulamentação da profissão de desenvolvedor. Pauta que um candidato aí levantou recentemente
Trabalhei em um projeto que tinha sido criado por estagiários / júniors em Flutter, que na época ainda estava nas fraldas e não tinha padrão de codificação algum (ainda não tem), e a pessoa mais sênior desse projeto mexia com iOS nativo (que por sua vez tem uma forma única de se trabalhar, que não se aplica ao Flutter). Então, um dia os stakeholders decidiram que queriam ter 100% de cobertura de testes no projeto. Entretanto, o projeto parecia o Morgott do Elden Ring, caindo aos pedaços. Onde mexia, quebrava todo o resto. Quando entrei e vi aquela situação, minha primeira opção foi fazer uma versão mais profissional do projeto, usando uma arquitetura bem definida e TDD, afinal, o projeto não era tão complexo assim, não passava de algumas requisições a algumas APIs e navegação entre telas. O time não quis dar o braço a torcer e aceitar a minha sugestão, preferiram tentar fazer testes unitários em um projeto acoplado, mesmo sem ter noção de como se faz testes unitários. Um curso ou livro realmente não ensina como fazer testes, apenas a própria prática. E foi exatamente isso que eu vi, os testes estavam lá somente para alcançar a "cobertura" de 100%, mas eles eram tão simples que nem faziam sentido existir. Só existiam testes que faziam o caminho feliz, e os erros continuavam a acontecer
Esses vídeos rated são de lavar a alma. É exatamente como o akita disse quando você vê que ninguém tá ligando para o projeto as pessoas que entram depois sentem-se forçadas a ligar o foda-se também, ou isso ou você mete o pé
Excelente conteúdo, verdades e mais verdades, eu como QA percebo diariamente que os DEVS não dão o devido valor aos testes.
Fiz uma pergunta sobre BDD num outro vídeo, mas acho que aqui responde um pouco. Mas vou assistir assistir mais uma vez e ver se entendi direito. Obrigado!
Quando ouço algo como nos exemplos, me recordo do meme do Pica-Pau: "Essa gente inventa cada coisa"!!! Excelente Rant (fiquei confuso se um rant bom é um bom rant ou ao contrário... kkkkkkk)!!!
Simplesmente genial! Sempre entregando conteúdo de altíssima qualidade!
Obrigado por compartilhar seus conhecimentos.
Precisamos de 8-11 pessoas para um projeto, 12 mil de salário fora benefícios. 154 entrevistas e onde estão bons programadores é um mistério. Teve gente que não conseguiu gerar uma função (o candidato poderia escolher a linguagem) para bloquear IPs já listados como spammers ou de países que não interessa ao público alvo. Se enrolam com GIT e aí já pode desistir. 😢
Desde o primeiro episódio que entrou, achei essa abertura animal.. hehee agora vamos pro video...
em "return to space" da netflix fica muito claro que desenvolvimento by tests é o que fez a SpaceX ser o que é, os caras tudo e depois corrigiam as arestas
Gostei do comentário quanto à estimativas. Onde mais penei foi mantendo um BAITA plugin de Blender, e já cheguei a dizer que não sabia quanto tempo iria demorar pra entregar a functionalidade, que em duas semanas teria alguma coisa, levou um mês. Mas diga-se de passagem essa nova funcionalidade fez toda a diferença no software.
"Toda burocracia em excesso é defendida por aqueles que não sabem o que estão fazendo."
Esse é um dos maiores problemas que vejo hoje - pessoas que não entendem nada de desenvolvimento de software criando processos que mais atrasam do que trazem benefício.
Se tem vídeo do Akita tem like, e se tem RANT tem like duplo! Pena que o RUclips não deixa dar like duplo, então tem mais views e share no grupo do zap!
A opinião de programadores mais experientes é sempre valiosa pra quem é novo na área. Vlw pelo vídeo, akita
Parabéns por esse vídeo Fábio A. tá mais "humano" e menos hardcore rrrsss, essa parte de gestão de pessoas e procedimentos é o que anda faltando nas empresas como um todo, não há inovação apenas mais do mesmo, esse vídeo foi um choque de realidade para todos esses mesmos da cultura do tudo igual! Valeeuu
Nem assisti... Mas lá vem um conteúdo excelente!
Obrigado pelo vídeo akita. Como sempre, conteúdo de extrema qualidade.
È muita coisa boa, omg!!!!!Muito para aprender!! woo woo
Que vídeo maravilhoso, meus senhores. Tem como melhorar mais meu dia ?
Akita, seria legal um vídeo falando o que se espera dos desenvolvedores junior, e o que eles devem estudar pra se destacarem no mercado.
viu a playlista de programação pra iniciantes e o 1o que é conhecimentos básicos?
Eu sou o único que já curti o vídeo do Akita antes mesmo de assistir? Parabéns Akita top d+
Uma sugestão para complementar o video seria algo sobre os flaky tests: testes de integração frágeis (por cagada de mal implementação) que rodam de forma paralela e sujam os ambientes entre si
Como vai seu mentor Leandro?
Excelente! Concordo plenamente.
Que aula Akita, simplesmente genial, meus parabéns!
Vejo vídeo novo do Akita e já dou o like antes mesmo de iniciar
"Se compila não precisa de testes" kkkkkkkkkkk. Nunca tinha ouvido essa desculpa antes. Para alguém que fala isso realmente não precisa de testes porque ele nem sabe pra que testes devem ser feitos. Como sempre, ótimo vídeo!
Amei a descrição do PHP em 20:29.
PQP, vou ter que comentar novamente. O Akita ta puto nesse video como nunca antes em video algum hahhahahaha... Adoro, sempre nos ajudando a nos tornarmos melhores!
O mais massa é o Akita apontando o dedo pra nossa cara kkkkkkk
Eu amo os conteúdos do Akita, é sempre uma qualidade absurda.
Antes desse vídeo já tinha começado a estudar Jest pra fazer testes com React Native, mas tava muito na dúvida do QUE exatamente testar dentro do código.
Agora depois de assistir vou simplesmente testar qualquer coisa. Depois eu apago essas merda e faço melhor já sabendo no que errei. 😹
As back scenes no final são top kkkkkkkkkkkkk
Vídeo muito bom. Obrigado.