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 UA-cam, 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!
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.
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.
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.
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.
Ó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.
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
"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 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.
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
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...
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.
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.
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.
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!
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.
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.
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".
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.
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
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.
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.
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.
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. 😢
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.
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.
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.
Mais uma coisa: Documentação do projeto é igual código: Fica em repo, tem que ser atualizada, usa pull/merge request e tem "bugs". Se for de qualidade, significa menos tempo no onboarding de um dev
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.
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 👏👏
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!
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.
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.
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
o grande problema que eu vejo é que as pessoas não sabem quantificar direito o quanto tem que ser pré documentado. Ou você tem que fazer um planejamento muito exagerado que provalmente não vai refletir o produto final por conta das mudanças nos requisitos, OU é uma frase dizendo "faça isso" que não fornece nenhuma base sem nenhum detalhamento do que tem que ser feito
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.
Já conheci programador que liderava equipe dentro da empresa que dizia sem nenhum pudor que teste era perda de tempo que era obrigação do programador fazer o código correto, e todo mês aparecia algum bug que dava dezenas de dólares de prejuízo, não adianta as pessoas não são perfeitas erros vão acontecer, hoje em dia eu não consigo colocar a cabeça no travesseiro tranquilo sem colocar testes no que eu entrego
Muitas vezes os testes não preveem todos os cenários, pq o pessoal de negócio deixa a desejar e não fica claro todos detalhes das regras de negócio. O famoso "não falei pq essa situação é muito raro de acontecer". Puta merda, mas se acontece tem q está nos requisitos.
É 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
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
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)!!!
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
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.
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é
Se tem vídeo do Akita tem like, e se tem RANT tem like duplo! Pena que o UA-cam não deixa dar like duplo, então tem mais views e share no grupo do zap!
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.
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!
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á !!!
A grande questão que fica é: Com o cenário atual, o que fazer? Lembro da época da Covid onde você informou que tinhámos mais dois anos para estudar e aprender mas, e agora? o que fazer?
Akita vi seu vídeo ontem, mas acabei de ver outro vídeo hoje que ressalta o que você falou e voltei aqui pra comentar. Não sei se sabe mas Masahiro Sakurai da Nintendo está com um canal do youtube sobre criação de jogos e no vídeo de hoje ele falou sobre encontrar problemas ou fazer mudanças em projetos, ressaltando principalmente a parte de ver um erro, reagir e seguir em frente com o projeto.
O Akita sugere realizar PoC de conceitos. Ele também sugere logo a seguir que toda funcionalidade deveria ser coberta por testes. No caso de uma PoC, acho que não compensa fazer testes, já que o objetivo do código não é ser integrado a um projeto, mas sim provar que algo atende as funcionalidades desejadas. Certo?
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!
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.
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
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!
meu primeiro job, Trabalhei em uma start up que não tinham testes, e eu entrei junto com uma equipe de devs que servia exclusivamente para apagar incêndios
"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.
![Esqueça Metodologias "Ágeis" | [Rated R]](http://i.ytimg.com/vi/xjjX3R2WuoM/mqdefault.jpg)
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.
"não sua múmia paralítica..."
Eu cuspi água com essa! 😅
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
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?
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 UA-cam, 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!
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.
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.
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
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.
Fala Fabio, Tente ir no Ciencia sem fim do Sergio Sacani, seria muito interessante !
.
Agreed
Meu sonho akita lá
Ó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.
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
"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" 👏🏼
Fazia anos que não ouvia alguém dizer "Múmia paralitica" huaehuaehuae...
ótimo vídeo!
Finalmente um vídeo do Akita pra fazer eu perder a preguiça de estudar mais sobre TDD kkkk
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.
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.
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...
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'
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.
Hahahahaha “pra vc que usa o VS pra fazer seus códigos porcaria” 😂 Akita é foda sempre lançando a braba
Ó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....
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.
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!
Curto muito esses RANTs, compactuo com várias coisas mesmo sendo júnior.
Eu ganho meu dia quando tem video de Rant do Akita, melhor relaçao de humor x tapas na cara
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
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.
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!!
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".
eiiiiiiiita porr@, já sei tudo o que vou dizer na próxima review/planning hahaha
Que aula! Verdades que todo profissional de desenvolvimento deve defender.
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.
Igual a musculação, as "pancadas" do Akita doem mas fazem você crescer e desenvolver.
Obrigado, mestre.
Se esse otaku, quer dize, Akita, vendesse curso de desenvolvimento web e outras loucuras do mundo de T.I com certeza compraria.
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
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.
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.
"Cresce e aja como profissional" 👏👏Tô num loop infinito nos vídeos do Akita
Já estava com saudade de ver um vídeo do Akita!!! Como sempre, conteúdo de qualidade.
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.
Arrebentou! Esse é de longe o seu vídeo menos polêmico. Impossível discordar de qualquer coisa. 😂 Está tudo 💯 porcento perfeito. 👏 👏 👏
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. 😢
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.
Este vídeo me fez lembrar do princípio de Pareto. 20% codificando, 80% ajustando bugs criados nos 20% de desenvolvimento. :)
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
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
Mais uma coisa:
Documentação do projeto é igual código:
Fica em repo, tem que ser atualizada, usa pull/merge request e tem "bugs".
Se for de qualidade, significa menos tempo no onboarding de um dev
Rapaz não tem ninguem que dá mais esporro (falar a verdade) que este cara. Muito bom. Parabéns. Agora vou para o Gentoo.
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.
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 👏👏
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 🔥
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!
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.
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.
Akita, faz um vídeo falando sobre a regulamentação da profissão de desenvolvedor. Pauta que um candidato aí levantou recentemente
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
23:06 "Sua múmia paralítica" hahahhahahah. Essa foi sensacional, faça mais vídeos nos esculachando por favor.
o grande problema que eu vejo é que as pessoas não sabem quantificar direito o quanto tem que ser pré documentado. Ou você tem que fazer um planejamento muito exagerado que provalmente não vai refletir o produto final por conta das mudanças nos requisitos, OU é uma frase dizendo "faça isso" que não fornece nenhuma base sem nenhum detalhamento do que tem que ser feito
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.
Fábio,. gosto muito do seu jeito de comunicar. Vc é muito bom nisso! Simples, claro e direto. Sem meias palavras.
Já conheci programador que liderava equipe dentro da empresa que dizia sem nenhum pudor que teste era perda de tempo que era obrigação do programador fazer o código correto, e todo mês aparecia algum bug que dava dezenas de dólares de prejuízo, não adianta as pessoas não são perfeitas erros vão acontecer, hoje em dia eu não consigo colocar a cabeça no travesseiro tranquilo sem colocar testes no que eu entrego
Muitas vezes os testes não preveem todos os cenários, pq o pessoal de negócio deixa a desejar e não fica claro todos detalhes das regras de negócio. O famoso "não falei pq essa situação é muito raro de acontecer".
Puta merda, mas se acontece tem q está nos requisitos.
Conheci um que ficou rico sem fazer testes, agora está trabalhando e um grande banco e virou staff.
Precisava desse vídeo, sempre bom esses puxões de orelha do mestre Akita pra rever minha mentalidade e evoluir
É 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
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
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)!!!
Desde o primeiro episódio que entrou, achei essa abertura animal.. hehee agora vamos pro video...
Excelente video. Sou da área de engenharia e da para aproveitar muito o conteúdo.
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
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.
As back scenes no final são top kkkkkkkkkkkkk
Vídeo muito bom. Obrigado.
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).
Irq preciso melhorar, obrigado pela sinceridade, com certeza irei correr atrás.
Compartilhando esse vídeo com a equipe. Muito bom!!!!
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é
Obrigado por compartilhar seus conhecimentos.
A opinião de programadores mais experientes é sempre valiosa pra quem é novo na área. Vlw pelo vídeo, akita
È muita coisa boa, omg!!!!!Muito para aprender!! woo woo
Se tem vídeo do Akita tem like, e se tem RANT tem like duplo! Pena que o UA-cam não deixa dar like duplo, então tem mais views e share no grupo do zap!
O cara tá com a camisa do capitão Levi, tem roupa mais BSDM que essa? Lá vem pancadaria...
😂
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.
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!
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á !!!
A grande questão que fica é: Com o cenário atual, o que fazer?
Lembro da época da Covid onde você informou que tinhámos mais dois anos para estudar e aprender mas, e agora? o que fazer?
Nem assisti... Mas lá vem um conteúdo excelente!
Amei a descrição do PHP em 20:29.
Akita vi seu vídeo ontem, mas acabei de ver outro vídeo hoje que ressalta o que você falou e voltei aqui pra comentar.
Não sei se sabe mas Masahiro Sakurai da Nintendo está com um canal do youtube sobre criação de jogos e no vídeo de hoje ele falou sobre encontrar problemas ou fazer mudanças em projetos, ressaltando principalmente a parte de ver um erro, reagir e seguir em frente com o projeto.
O Akita sugere realizar PoC de conceitos. Ele também sugere logo a seguir que toda funcionalidade deveria ser coberta por testes. No caso de uma PoC, acho que não compensa fazer testes, já que o objetivo do código não é ser integrado a um projeto, mas sim provar que algo atende as funcionalidades desejadas. Certo?
Sim. Teste somente no entregável, POC não é entregável.
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
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.
Sensacional. Akita parabéns por compartilhar essa experiência. Inspirador esse vídeo para muitas pessoas.
Que vídeo maravilhoso, meus senhores. Tem como melhorar mais meu dia ?
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
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!
Eu fico até o final só por causa dos bloopers kkk. Valeu Akita! conteúdo top
meu primeiro job, Trabalhei em uma start up que não tinham testes, e eu entrei junto com uma equipe de devs que servia exclusivamente para apagar incêndios
"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.
Mudando de assunto rapidamente, curti a camiseta!