por mim o maior golpe é "Seja fullstack em 6 meses e ganhe 10k"... ai nas lives perguntam.. "Só com HTML/JS/CSS vou conseguir emprego?".. Resp: "Sim, mercado está faltando profissionais, empresas estão desesperadas em contratar"... kkkk e ai o curso q o cidadão tá pagando eh de 3k pra cima.
O problema não é a literatura em si, mas sim, a rapaziada que tá começando/chegando agora, não leu nem estudou porra nenhuma, não entende os conceitos, não entende onde usar, viu meia dúzia de video em UA-cam e sai falando que não funciona. Código é expressão, saber ser expressivo, de forma não ambígua, é o que faz TODA a diferença. Código é interpretação, conseguir interpretar um código escrito por alguém, abstrair com o que era esperado, e pontuar cenários de excessão é que te darão destaque sobre os demais. E isso, por exemplo, facilita muito aplicando as práticas do Clean Code. Não se trata de cagar regra, mas sim, de expressão.
O vídeo é um tapa na cara, simples assim. O que mais tem é Dev que caga design patterns mas não aguenta a pressão de entregar uma feature em uma deadline apertada. Esse mesmo Dev que vem com um monte de firulagem no código, é o Dev que se acha superior aos demais, principalmente ao cliente, quem de fato tem a necessidade e sabe do problema! Vi muito Dev assim e por pouco não me tornei um desses, até um dia eu ter um gestor e falar para mim "o que eu quero é entregas!". Aquilo foi um divisor de águas em minha vida profissional, e eu entendi que: Quando tem dinheiro do cliente, valor alto, uma dor que precisa ser sanada, o cliente não quer saber de TDD, Cleane Code ou qualquer outra coisa, o cliente quer entrega, quer feature para poder honrar o dinheiro dele investido. Deixo bem claro aqui, não estou menosprezando as boas práticas, Clean Code, testes ou qualquer outra coisa assim, mas precisamos entender que, entregas são cruciais, com gambiarra, com código extenso ou não, mas precisam ser entregues e gerar valor(sim, me refiro a dinheiro, pois é isso que comanda o mundo, goste você ou não). É isso, esse vídeo foi um tapa na minha cara, e deve ser para geral mesmo. Quem sabe se a "boooollhhaa deeevvv" entender isso, o número de layoffs diminua.
Deixo mais uma vez bem claro aqui: Não estou menosprezando Clean Code ou demais outras práticas que impactam positivamente a entrega de um trabalho. Mas apenas esse chacoalhão e um desabafo.
Maior problema que vejo em quem está entrando na área é a atitude do: ninguém me falou, ninguém me ensinou, não tinha no curso que eu fiz. A pessoa faz um curso de Node e React e acha que está pronta para o mercado. Não pratica lógica de programação, não se aprofunda em deployment, não busca entender como as coisas funcionam mais a fundo. Um curso não faz um dev.
Meu, tenho olhado vagas de programadores... o cara tem que ser da Nasa para "preencher os requisitos", muito louco isso. Dai a gente faz tudo num builder c++ e o pessoal fica louco em ver que um programa de poucos kbytes e uma interface gráfica amigável faz rapidamente o que aquele ""framework" leva 3x o tempo.
Sobre o clean code, não é sobre a função fazer literalmente só uma coisa, mas ter um único propósito. Ele explica bem detalhado isso, dividindo até em níveis de abstração.
@@MatheusSouza-ty9zk cara existe uma birra com o tio bob devido a visão politica que ele tem, tem gente que critica ele mais por esse motivo do que um real motivo nos livros dele, ai ele tentam implacar a ideia que o livro dele é inútil.
Só o ponto de enfatizar o quanto nomes são importantes e como nomear pedaços de código ajuda no entendimento do código como um todo (que é só o primeiro capitulo do livro) já Faz clean code valer a pena...
Cara, eu lembro que em 2014 o pessoal falava um pouco sobre essas tendências, mas dev fazia tanto a parte do front como back. De fato, alguns eram melhores com design, mas todos sabiam o básico. Hoje com este monte de cerimônias que mais parecem um culto que um trabalho (afinal, todo dia você precisa confessar o que fez em uma maldita daily) parece que o pessoal abraçou muito mais a tecnologia e esqueceu do negócio. Cara, em 2016 eu ainda via vagas de vb6! Será que o problema é a tecnologia que mudou ou são os programadores novos que querem usar tudo e não fazem nada? Digo isto, pois se programas em cobol, vb6, asp classic, perduraram por muitos anos funcionando e hoje em dia o sistema muda constantemente de tecnologia, algo não me parece certo.
Eu ODEIO daily com todas as minhas forças. Isso é culpa da galerinha de humanas que fica inventando problema pra vender solução é conseguiram uma brecha no meio de exatas com essa e outras bullshit
No Ceará em 2013 quando comecei a desenvolver software tínhamos uma única função o Anapropégua. Ana-pro-pégua. Analista, programador e fí duma égu4. Fazíamos tudo, reunião com o cliente, arquitetura, backend, frontend, gestão. Enfim tudo e mais um pouco.
EXATO. Logo me lembrei do Akira. Ele bate bastante em pessoas que pegam assuntos que chamam atenção para vender coisas E isso todos fazem, pois é a "gourmetização" das coisas que vendem. Colocam uma capa de "super conhecimento" e vendem por aí...
Quem nunca trampou em um projeto que em sua essencia é basicamente um crud.. não tem nada além de cadastrar, alterar e excluir registro... a parte mais complexa do código é calcular um percentual... E ai vem o dev José SOLID, José CLEAN CODE e começa enfiar 1 milhão de interface, começa abstrair a abstração, a parada que podia ser sómente uma validação e gravar no banco de dados, vira uma puta salada de código desnecessário e se vc OUSAR a criticar a "ARQUITETURA", vc não sabe nada kkkkkkk
quando o cara já bem com essas palavrinhas, já sei que é um péssimo programador e que ele não entende de fato do que ele mesmo está falando e nem sabe como e quando aplicar.
A real é que pessoas inseguras querem mostrar um monte de habilidades e técnicas, apenas e tão somente para tentar mascarar os resultados medíocres. “Keep it simple, stupid.”
Sempre o conhecimento fez com que ajude a gente a diferenciar o que funciona e nao funciona. Eu adoro os conceitos do Clean Code, TDD, Design Patterns, Agile Methods. Sao perfeitos GUIAS. Cada caso é um caso e se vc tem o conhecimento pra diferenciar do que vai ser bom ou nao, ai é outra coisa. Ser cego e seguir a risca tudo tambem nao vai. Vc vai gastar mais tempo tentando se encaixar nos padroes porque te vai restringir do que criar o codigo que vc precisa. Esse dos metodos terem 1 funcionalidade eu gosto por semantica, fica mais facil de dar manutençao porque se vc pode 2 coisas e vai reutilizar a funçao, pode ser que pra outra isso nao era o esperado. Lá pra 2008 (comecei em 2006), o arquiteto leu o livro e meteu checkstyle no Java pra metodo nao ter mais de 3 linhas, tinha que fazer 1 coisa só, e por ai vai. Foi mais dificil arrumar o codigo pra que compilasse do que desenvolver. Isso ja foi um extremo, bem dificil. Eu era Junior e sofri bastante. Anos depois eu notei a diferença de produzir um codigo com um grupo que tinha lido o livro e entendiam como guia. Era muito mais facil de entender e dar manutençao nos codigos. Design Patterns exagerado é ruim, ser extremo com clean code atrasada projeto. Methodologia Agil mal entendido nao é agil. Saber que em algum ponto que o projeto esta, XP pode ser melhor que Scrum e ter menos problemas. Muita coisa discutivel nesse assunto.
Na empresa em que eu trabalho se usa desenvolvimento ágil. Mas tendo vindo de outra área, engenharia mecânica, onde eu era projetista, e aplicava várias técnicas de desenvolvimento de projetos. Percebo que o ágil só funciona se você tem, logicamente, um time ágil. Você precisa de toda uma estrutura de planejamento e know how antes de implementar uma metodologia ágil. Não é simplesmente colocar um quadro de tarefas para monitorar quem faz mais. Os desenvolvedores deixaram de resolver problemas para resolver "tasks" não importa o quanto de gambiarra e o quanto isso vai quebrar o projeto depois e o quanto isso vai atrasar o conjunto da obra. No meu ponto de vista e experiência de engenharia e relatos dos colegas de outras empresas, são muito raros os casos que realmente sabem usar a metodologia ágil.
Sou desenvolvedor BackEnd(na maioria do tempo), e fazer front pra mim é extremamente complexo e massante, acho que os dois são difícil, mas o costume e a apitidão tornam um ou outro mais fácil, resumindo, é completamente pessoal.
Valeu mais uma vez Montano estou a uns bom longos 9 meses estudando front end e ja tava pensando que eu que não levava jeito ate pq "FRONT END É FACIL" mais uma vez obrigado este videos falando sobre o ego que tem na tecnologia e o que esta me mantendo firme nao entrei nessa de cursinho ate pq fiz medio tecnico mais uma vez valeu agora estou ciente que o tempo que estou levando consolidando os conhecimentos em Front nao é porque nao levo jeito ou algo assim Front end ou back é ... desculpa se fico meio confuso meu comentário mas apenas saiba que este video veio no momento certo !! VLW!!!!
Recomendo ler a respeito do "efeito dunning-kruger", em seguida pensar na relação sobre como maioria dos técnicos/analistas/engenheiros trabalham. Isso pode até refletir no como observar o temido "layoff". Entendo ser necessário ter agilidade e entregas a curto prazo, mas se feito com qualidade duvidosa torna-se maioria das vezes uma "bomba-relógio" para o próximo. E com todos estes fatores, cada vez mais se torna difícil avaliar o equilíbrio no tempo dedicado entre legado e novo.
O problema é falta de experiencia na area, quem nunca programou ou programou pouco, dificilmente não vai conseguir assimilar as metodologias Agile. Porque com experiencia você pode tirar sua conclusão de cada metodo do mundo Agile. Tem projeto que não vai chegar ao fim se você seguir todas as metodologias ditas como Agile, mas existem boas praticas que que são apresentadas nas metodologias Agile que com alguma experiencia no mundo do desenvolvimento você vai adquirir automaticamento. Vejo como saudavel(mesmo com algum interesse no jaba) o surgimento de novas metodologias Agile. Do manifesto Agile o item que eu mais gosto é "Software em funcionamento mais que documentação abrangente".
Se eu preciso de uma função fetchAndSaveUser eu vou desenvolver ela em algum momento se isso é necessário para o meu negócio. Mesmo que internamente ela seja quebrada em fetchUser e saveUser, em algum momento eu vou precisar das duas funções uma após a outra e talvez com condições, por exemplo se fetchUser falha não chama saveUser.
Faltou citar teste unitário ( vou ser sacrificado agora pelos devs rocketseat), muitos devs endeusam testes unitários como se fosse a maior bala de prata do desenvolvimento
hahah pura verdade e olha que sou QA o teste unitário no mundo real "é o mais fraco"(caos se aproxima) e esse "golpes" que ele citou muitos deles cehgou até na área de QA. Eu sempre me perguntei quem criou esses desing pattern? Ele conhecia a minha empresa?sabe quanto tempo eu tenho pra entrega?Pq isso é uma lei? etc...
eu adorava quando o desenvolvedor fazia front e back , fazia o negocio com o cliente, agora tudo e AGIL e acaba sendo uma merda , a entrega do front e uma merda a entrega do back e uma merda , por que vc tem que fazer dentro de uma sprint de merda de 10 dias ou 15 dias , sendo que o trabalho e para 2 meses.
Programo desde 2010, me viro com o que tem: Sou designer, faço protótipo, desenvolvo o front, o backend, documento o backend, integro com o front, escrevo os testes, faço o deploy com CI/CD, numa boa; mas se a empresa quiser me pagar um misto e um refri de salário, eu vou entregar o equivalente
Não sou do time de jovens que acredita nos 6 meses, mas realmente estou pensando em voltar a estudar para concurso(PF), pelo menos a aprovação é 100% mérito meu. Estudar várias tecnologias , e arriscar ficar anos até conseguir a primeira vaga, ficando à mercê da subjetividade de recrutadores etc.. Sinceramente, isso é desanimador.
Das* recrutdoras (feministas que odeiam trabalhar e se esforçam para diminuir qualquer pessoa que ela julgue superior por qualquer motivo idiota da cabeça vazia delas) Ou então um feministo desconstruídx
Pois é mano. Olha que eu já tenho certa experiência. Já trabalhei por 2 anos como dev somando estágios e emprego Full time e tô a 3 meses desempregado pq simplesmente parece que meu currículo não serve pra porra nenhuma mais. Também penso em ir para os concursos.
Caraca fiquei uns anos fora do YT e tu se tornou uma maquina de produzir conteúdo nesse tempo hein? hahaha bom te ver por aqui ainda mano! Tbm gostei muito da pegada desse tipo de video react/comentário, vou copiar 😂
Esse lance sobre Agile fez eu lembrar de um professor de engenharia de software que falava que o manifesro agile e os processos inspirados eram babaquice pois no fim o RUP tambem servia para os casos propandeados do Agile, bastando adaptar o RUP pegando o necessário dele 😂 . O RUP era para ele como um META processo.
@@PeX218 como um processo que permite criar processos . Ele afirmava que o RUP de permitia alta adaptação até para os casos que o agile era vendido , propagandeado.
Acho que quanto ao autodidata é que a pessoa iniciou pelo caminho se estudar sem nenhum curso. Este foi o meu caminho, só depois de ser desenvolvedor pleno fiz uma facul EAD. E nunca nem fui pegar o diploma...
Quem tá chegando agora acaba caindo nesses golpes. Aí fica complicafo, pois vão tirar dinheiri de alguém que pensa estar aprendendo o essencial, mas que na verdade o essencial mesmo depende da empresa, do projeto e do time onde estivermos...
Frontend é mais dificil. Os códigos são uma zona, com JS um novo framework e gambiarras com libs que já existiam mas não estão no novo framework. Admiro os FE por manterem a sanidade lidando com código, usuarios e designers/UX.
O final desse video. Eh um dos comentarios mais lucidos que vi um desenvolvedor que tem um alcance de influencer, falar abertamente, e com clareza. Achei que eu estava bugando. Saudades dos blogs a la Viva O Linux e muitos outros que era literalmente bases de conhecimento e nao rede social, como tudo hoje em dia. Ta ficando assustador
O conceito do SRP não é a função fazer uma única coisa! No Clean Architecture, pg. 62 explica isso com detalhes. "Um módulo deve ter apenas uma, e apenas uma, razão para mudar" / "Um módulo deve ser responsável por um, e apenas um, usuário ou stakeholder."
O que tá no clean code não é SRP, é exatamente isso da função fazer uma única coisa, tem até uma parte que ele fala que se a função tem "and" no nome ela possivelmente tá fazendo coisas demais. Clean Architecture é um outro livro
Uma das formas "Canônicas" o SRP diz que "A classe deve ter apenas uma razão para mudar!"; Mas cada um vai fazendo suas interpretações e adaptações, numa discussão teve um cara que falou que a Classe deveria ter apenas 1 metodo! KKK
Na real a galera não lê nada, não estuda nada, fica num superficial de quase tudo, não entendem nem se quer o Clean Code, o efeito desastroso para manutenção de um código "macorronico"... No fim não entendem pq os caras escreveram um livro sobre o assunto, não entendem o problema que a "ferramenta" tenta resolver... depois reclamam que não funciona "remover um parafuso com um martelo"... triste realidade...
Quando o elefante na sala é performance, meu querido, arranca orm, arranca as abstrações, arranca startup cheio de manhas até chegar na regra de negócio e vai direto ao ponto com um sistema robusto de cache que aguente paulada. O resto é bullshit. Ah e outra coisa, aprende sql caralho. Quer performance? Faz suas consultas porra. ORM quando começa a enfiar regra só faz merda.
Eu assistindo esse vídeo bem na época que decidi ler Clean Code do tio Bob e Head First Design Patterns 🥲 Mas ao mesmo tempo acho que foi bom, por que estou na metade de cada um dos livros citados e comecei a sentir que não vou conseguir aplicar aquilo ali em muita coisa, e estava começando a me sentir mal por isso. Então esse vídeo me deu um certo conforto. Design Patterns, apesar de acreditar que não vou conseguir aplicar em algum lugar, está sendo bom pra preencher vários GAPs de conhecimento em OOP que eu tenho. Além disso, é legal por que você acaba enxergando melhor de onde vem vários conceitos (Factories, Observables, Commands, Iterators, etc...) aplicados nos frameworks atualmente, como Laravel e Angular. E o Clean Code tem sido bom pra organizar um pouco o código que escrevo, que confesso que sempre foi uma bagunça. Mas me identifique com a parte do "Se o nome da função tá grande demais, tem alguma coisa errada..." por que assim que comecei a aplicar os conceitos, comecei a ter funções com nomes bem grandes, vou me atentar mais a isso.
Estudamos os Design Patterns para quando a real necessidade da aplicação deles aparecer sabermos aplicar. Design Patterns não se sai aplicando porque acha bonito ou coisas do gênero. Aplicar Design Patterns onde não necessita é o equivalente a instalar um Elevador numa casa térrea, não tem objetivo. Porém, num edifício de 20 andares o elevador é indispensável. Tem projetos ou partes de projetos onde o(s) Design Pattern caem como uma luva para solucionar problemas complexos.
@LucasMontano, tive que parar o vídeo aqui 2.35 depois eu assisto o resto. should não é must. "as funções deveriam fazer apenas uma coisa." não "as funções devem fazer..." o peso é menor. é uma sugestão. não uma regra. aliás o próprio tio Bob fala isso direto. ufa. ainda bem que eu continuei assistindo. kkk vc ta certo. agora entendi.
eu achava que esse tipo de coisa era piada, mas tem um analista senior que é exatamente igual no meu estágio, e ele literalmente me emprestou 3 desses livros comentados, quando vi o video do bigboxSWE dei uma acordada legal.
Goooooooooooooooool ate que enfim alguém falou por mim. E tem muito mais redpill, vocẽ vai passar anos estudando AI para ser usado por banc0s e big techs. Eu tava me organizando para falar tudo isso ai que ele disse, principalmente sobre vagas na area é uma fars4, tem que se levar mais como to com uma obra. Sensasional. Tentei falar isso pra essa boiada mais fui censurado e tive que ficar calado por depender ainda dessa renda.
Com SOA ocorreu a mesma coisa, empresas patrocinando toda uma mídia e vendendo pacotes de ferramentas, vi muitos desastres, empresas despejarem milhões e milhões e não conseguirem o sonho dourado de migrar tudo para SOA. Com EJB a ideia inicial era boa, porém furada, mas depois ocorreu a mesma coisa, empresas vendendo os pacotes caríssimos com a mídia forte por trás.
Do SRP, o S de Solid. Lá fala que um módulo deve fazer apenas uma coisa, na wikipédia ainda tbm fala Classe. É interessante que não fala que a "função" deve fazer uma coisa, que alias tem mais haver com "razão de mudança". E agora me vendendo um pouco... escrevi: "Junior need rules, Senior guidelines", meu ponto lá é que todo mundo sabe mais do que fala o Clean Code do que outros livros ainda mais importantes porque... é cagação de regra e juniors precisam de algo claro "isso é certo, aquilo é errado. não pensa, só faz" e depois vão crescendo.
Frontend é um inferno, não exatamente pq criar interfaces é difícil, mas se tornou difícil, principalmente na web. Essa combinação de html, css e javascript já deu o que tinha que dar, essa stack deveria dar espaço para abordagens menos complexas para o desenvolvedor. A web está sendo construída de gambiarra em gambiarra (na verdade boa parte da computação kk) mas no front isso chegou a um expoente inimaginável
A verdade sobre front web é que é uma grande gambiarra... O HTML foi pensado para se estático, ai incluíram, posteriormente uma linguagem desestruturada (javascript) interpretada, tenta deixar dinâmico isso ei nasce uma bando de framework sempre tentando arrumar os mesmo problemas e paradigmas. MVC, MVVM e etc... O node deveria ser o padrão e gerar um web assembly. Linguagem interpretada sem ter validação de compilação é coisa de burro. Olha o movimento de Rust, que vai além de ser fortemente, tipado evita problemas de memória e etc. Compra o consumo que os navegadores usam. A W3C nunca fez um trabalho descente. Que é macaco velho viu muito, cada navegador implementar diferente as coisas. É casa da mão Joana. Com a vinda do Web Assembly pensei que iria ter algo bom, mas ainda é a mesma bagunça. A grande dificuldade no front é por conta disso. Mas não subestime as pessoa. Não há nada difícil que um humano não posso complicar mais ainda.
2:43 eu tinha quebrado e nao sabia . iniciante . 6:13 Estou numa escola técnica integrada , e os veteranos nos contaram que basicamente tinhamos que ser autodidatas e eu ja estava apreendendo conceitos basicos , mas alguns chegaram de olhos fechados nao sabendo nada da area.
Gostei do vídeo, mas vou citar você mesmo Lucas Montano, antes de discordar com Clean Code, Design Patterns e etc., primeiro conheça e aplique. É muito perigoso a galera ignorar que existem boas práticas de programação e basear apenas na própria subjetividade quando estão começando a carreira, porque nem todo código que funciona hoje vai ser bem mantenido no futuro. Trabalho atualmente numa empresa do segmento de construção civil, onde arquitetos viraram desenvolvedores, e a falta de estudo específico em boas práticas de programação criou milhares de linhas de spaghetti code, e agora a galera está desesperada nas etapas de manutenção do código. Concordo que muita gente faz golpe com Clean Code e Design Pattern, mas ignorar completamente isso é um golpe maior ainda.
Falou mal do VIM?????? Tirou sarro do ARCH LINUX???? Espera aí, vou logar na minha conta com foto de anime girl e já volto, isso não vai ficar assim, me aguardem!!!
Frontend é para ser fácil mesmo. Nos últimos anos que estão dificultando mesmo, um monte de framework com 5 kg de javascript, é tenebroso o ponto que chegamos para fazer algo que nasceu para ser simples
@@wscldmas é mesmo. O lance é fazer funcionar e deixar o mais simples possível de manter (KISS keep it stupid simple). Se só crud simples resolve é pra ser só crud simples mesmo
Não acho inútil ler os livros, pois podemos absorver os conhecimentos contido neles , testar e ver se serve para cada um e usar e abstrair o que não gostar, e montar sua própria forma de customizada com o que acha ser melhor.
Função deve fazer apenas um única coisa, é uma excelente recomendação e deve ser usada na maior parte dos códigos na minha opinião (Recomendado, não obrigatório). Eu sempre prezo pela facilidade de leitura e manutenção de um código.
Design Pattern funciona bem só quando não tem um junior mexendo no código deixando tudo public e cagando na arquitetura. Claro, no mundo real, não existe design patterns, pois eles requerem planejamento e isso vai contra o primeiro axioma do GoHorse, prática seguida por grande maioria das empresas brasileiras.
Não vejo benefícios de separar font-end e back-end. Na verdade, só tem benefícios se tiver múltiplos front-ends (web, celular) ou se o back-end é usado com API por inúmeras aplicações. Fazer site tendo só um back-end e só um front-end é uma péssima ideia, porque os programadores tem que escrever mais código.
Esse livro Clean Code é um saco. É um livro que poderia ser um paper de 4 páginas. agile era legal até capitalizarem o "a". Aí virou cabide de emprego de coaches. TDD é legal, mas é igual a crente da Bléia. Sobre a falsa dicotomia facul vs autodidata, é coisa de quem não fez faculdade e tem ressentimento. Udemy é uma bosta.
Beleza, tem essa parada de querer cagar regra. Mas sem nenhuma regra vira zona. O clean code não é perfeito e nem tudo precisa ser levado a ferro e fogo, mas pelo menos traz uma noção mínima para fazer as coisas com o mínimo de elegância. No final do dia a entrega é o que fala mais alto, mas depois da entrega vem a manutenção que as vezes pode ter um custo alto. Então não é bem um golpe
Jovem, ou vc é autodidata ou vc tem professor, não existe os dois ao mesmo tempo. Mesmo que vc aprenda algo a mais que o ensino passado pelo professor isso não é ser autodidata, vc teve orientação.
@@kingoftime470 Boa colocação, mas não diria que vem do ensino formal, pq ensino formal nem existia quando o conceito foi criado, é literalmente se vc teve orientação com professor ou se não teve. O conceito de Mestre e aluno.
Sobre Clean Code e Design Patterns. Eu afirmo sem medo de errar que os maiores haters desses processos são pessoas que NÂO ENTENDERAM clean e design patterns. Infelizmente a galera precisa quebrar a cara de verdade, dando manutenção em sistema legado feito nas coxas e ser processado por cliente por entregar sistema cheio de bug. Só aí vão entender a necessidade de programar com qualidade e organização. E mesmo assim ainda vão quebrar a cabeça pra "inventar" uma engenharia no software que atenue os problemas enfrentados, quando poderiam simplesmente deixar de preguiça e estudar DE VERDADE alguma coisa na vida. Desculpa o desabafo, mas já to de saco cheio de gente que lê as coisas na pressa e na má vontade, implementa com a bunda e depois culpa o processo. Usando uma metáfora pra entender melhor: Você lê uma receita num livro e, na preguiça de ler todo a receita, dá só uma lida por cima no "modo de preparo" e nos "ingredientes", sem se atentar aos detalhes - fogo alto ou baixo; ingredientes mais ou menos maduros; marca recomendada; ingredientes que são "a gosto". Daí na hora de cozinhar, você ainda muda a receita porque você não tinha um dos ingredientes, ou simplesmente não gosta do cheiro. Se a sua receita ficar ruim, não adianta culpar o livro, tu que é preguiçoso e não entendeu bem a receita. Dessa forma tá cheio de gente na internet metendo bronca nos princípios e boas práticas de programação e, sem apresentar qualquer argumento razoável que justifique sua crítica, apelam para o argumento de que "o projeto está super corrido e não dá tempo de ficar implementando essas coisas". Na verdade, na maioria dos casos, um código bem organizado e implementado conforme os Princípios SOLID, te ajuda a ganhar tempo, pois tem mais facilidade para paralelizar atividades, já que todos na equipe teriam facilidade em dar manutenção nos mesmos projetos. Inclusive a mesma coisa vale para Agile.
Eu vejo isso muito na galera de software house, alguns só cospem trabalho para o cliente e pronto. Ai fica fácil desdenhar e não valorizar boas práticas. O difícil é sustentar um sistema feito no go horse, feito no lema “quero entregar logo”. Tem que existir o meio termo, quando o dev é mais malandro ele já vai prevendo o caos, ele já desacoplando módulos do sistema a medida que cresce pois já tem aquele faro de “isso aqui vai dar merda no futuro”
Mas veja, não quero criar intriga nem nada, mas a galera que faz isso na área, é porque não conseguiu ser empregada em áreas críticas. Explico: Imagine se essa mentalidade preguiçosa e afobada fosse na engenharia civil? Uma ponte iria cair e matar muita gente. Em desenvolvimento de software, é possível entregar algo para o cliente e ir fazendo upgrades até o projeto ter chegado ao fim (isso se tiver mesmo um projeto bem estabelecido, o que eu duvido bastante). Eu não sou da área de informática, mas vejo que está área está cada dia mais e mais cheia de gente preguiçosa chegando (e com isso os valores vão abaixando). Não tem jeito, é necessário fazer um expurgo dos incompetentes e eles que lutem para ter o que comer.
Agile estragou o mundo de desenvolvimento fez tudo ficar mais chato e desgastante. Já fiz muitos sistemas no passado sem usar qualquer coisa de agile e foi muito menos caótico e mais divertido. O agile só aumentou o burnout nos desenvolvedores.
Acho que o maior problema dos Design Patterns é achar que eles resolvem qualquer problema. Na realidade, o problema se encaixa ao Pattern, não o contrário.
meu pai trabalhou de 30 anos de mecânico em uma fábrica tu acha que ele aprendeu tudo em um curso? Faculdade? Todas as profissões têm que ser auto didata em certo nível
Eu gosto mais de backend, e conheço um pouco de front e digo que nenhum dos dois é fácil... Fácil é ficar sentado sem fazer nada... Na área de TI eu não considero nada fácil, porque em todas as atividades vc tem que ter algum nível de atenção.
O maior golpe da área inteira se chama Metodologia Ágil. O nome é lindo, que empresa que não quer usar uma metodologia que seja ágil? Mas na prática ela é a anti-engenharia. Por definição, ou você gosta de engenharia (documentar e realizar processos) ou você gosta de Agile. Queria saber tua opinião no que o Agile se tornou Montano, nem que seja pra me xingar e falar que tô totalmente errado.
Pessoal confunde ágil com rápido, mas eh vdd, essa metodologia virou um pesadelo hj em dia, pq o pessoal só sabe seguir receita de bolo e não quer mais pensar.
Fazer um bot pra contar quantas vezes o Lucas Montano do canal Lucas Montano troca o titulo do video, três hipoteses a testar: 1. eu sou maluco, 2. ele está a ver o que mais entrega, 3. Montano quer criar um efeito mandela nos inscritos. Mas estou bem enviezado a aceitar a primeira
A verdade é que qualquer coisa que você usa de maneira cega como se fosse a bala de prata é ruim. Pensando crítico faz parte em qualquer área e não existe receita de bolo para desenvolvimento de software
Sobre as boas práticas, o golpe não é buscar fazê-las, mas ser dogmático. Curto muito fazer TDD, mas é loucura fazer disso um dogma. Tem muitos casos que não vale a pena.
o que eu vejo são pessoas que não tem a maturidade suficiente ou trabalhem com algo que não precisa estruturar o codigo como se menciona nesses livros. Não vejo como golpe. o exemplo da função é clara... porém pode ter suas exceções, assim como a atomicidade de um banco de dados, pode haver algum momento em que é melhor não usar a atomicidade. O SOLID não faz sentido pra vc? não pratique. as vezes é o pessoal que quer usar "Padrões" onde não tem necessidade, mas nem por isso os ensinamento desses livros são golpes
Eu sai do vscode pra usar vim, foi uma merda aprender no início, mas o principal foi a "leveza" o vim é muito mais leve que o vscode e hoje eu gosto muito de desenvolver em vim.
@@messiasolimpio1992 rs.. mas vc nao pegou projetos enormes com um monte de arquivos.. eu trabalho em empresa grande eu sei vim de cabo a rabo, mas é o que o rapaz do topico ai falou... não tem como ter produtividade alta com vim e quem soltar essa pérola numa entrevista, com certeza não será contratado.
Concordo, e olha que uso desde 2014. Mas perder tempo configurando tudo… Ainda bem que no Brasil não existe muito essa tendência de punhetar ferramentas, lá na gringa muito dev que usa VIM nem trabalha na área.
@@gepetovovo2509bem isso. Um exemplo são projetos em .NET, não tem como, o sujeito vai perder horas ou dias tentando configurar, e para que? Só para chegar a fazer 50% do que o Visual studio ou Resharper faz? Kskskk
Vendo do ponto de vista do Brasil, há algumas considerações. Mas imagina um americano, que pagou 5mil dólares mês por 5 anos, pra se formar e quando sair ganhar 6k de dólar. Sem a vantagem cambial, tá muito ruim ser dev. O ruim disso tudo, que não está sendo vantagem ser nada, em nenhum país. Salários sêniors mundo a fora estão congelados desde 1971, mas esqueceram de congelar a inflação. É claramente um golpe...
o foda da TI é que o povo é fan boy.. aí tudo vira escrito na pedra. e aí que o golpe vem... pega todos os "golpes" como nortes/orientações e usa quando faz sentido (teu exemplo de function é bom nesse sentido). igual linguagem que é ferramenta, usa a que te atende e te faz entregar.. não te amarra em sopa de letrinhas.. (não seja mais um querendo "botar prego na parede usando um alicate" por religião)
Não acho que Clean code seja um golpe, acho que tem que saber USAR. O Fato é, se você é empregado ou presta serviço, O CÓDIGO NÃO É SEU !!!, Então deixe essa bagaça o minimo entendivel, reutilizável e "performático", pois outra pessoa irá gastar tempo para ler o que tu escreveu. Se voce tem o minimo de senioridade e não tem essa preocupação com teu próprio trampo, seria bom fundar um empresa e programar para vc mesmo.
Me inspirei no fireship e no big box tb. Puta conteúdo de qualidade, eu so abrasileirei kkk
Olha sóóóó quem apareceu, salve mano Fiasco, vai voltar? 😏
ta vivendo de renda
Seu puto , deixei meu discord no site que fiz pra ti , e tu so mandaste msg no Istagram , mas sen recentimentos , mas tu ta me devendo um cursso
@@matheustauan9113 Acho Dificil
vai voltar a fazer video quando?
por mim o maior golpe é "Seja fullstack em 6 meses e ganhe 10k"... ai nas lives perguntam.. "Só com HTML/JS/CSS vou conseguir emprego?".. Resp: "Sim, mercado está faltando profissionais, empresas estão desesperadas em contratar"... kkkk e ai o curso q o cidadão tá pagando eh de 3k pra cima.
ASDHJUASDHASUHD a resposta direta na lata que com HTML, CSS e JS a pessoa vai entrar no mercado é uma das coisas mais canalhas que fazem ultimamente
Mas aí o cara merece se ferrar.
mano, acabei de ver um anuncio falando isso aí Kkkkkkkkkkkkkkkkkkkkk
E a Ebac cobrando 5.500,00 em qualquer curso😂
Primo Rico e Joel Jota falando asneira 😂. Isso deveria ser crime
O problema não é a literatura em si, mas sim, a rapaziada que tá começando/chegando agora, não leu nem estudou porra nenhuma, não entende os conceitos, não entende onde usar, viu meia dúzia de video em UA-cam e sai falando que não funciona.
Código é expressão, saber ser expressivo, de forma não ambígua, é o que faz TODA a diferença.
Código é interpretação, conseguir interpretar um código escrito por alguém, abstrair com o que era esperado, e pontuar cenários de excessão é que te darão destaque sobre os demais.
E isso, por exemplo, facilita muito aplicando as práticas do Clean Code.
Não se trata de cagar regra, mas sim, de expressão.
Clean code é eficaz. Não entendi a queixa.
@@AlexXavier Eu também não.
O vídeo é um tapa na cara, simples assim. O que mais tem é Dev que caga design patterns mas não aguenta a pressão de entregar uma feature em uma deadline apertada. Esse mesmo Dev que vem com um monte de firulagem no código, é o Dev que se acha superior aos demais, principalmente ao cliente, quem de fato tem a necessidade e sabe do problema! Vi muito Dev assim e por pouco não me tornei um desses, até um dia eu ter um gestor e falar para mim "o que eu quero é entregas!". Aquilo foi um divisor de águas em minha vida profissional, e eu entendi que: Quando tem dinheiro do cliente, valor alto, uma dor que precisa ser sanada, o cliente não quer saber de TDD, Cleane Code ou qualquer outra coisa, o cliente quer entrega, quer feature para poder honrar o dinheiro dele investido.
Deixo bem claro aqui, não estou menosprezando as boas práticas, Clean Code, testes ou qualquer outra coisa assim, mas precisamos entender que, entregas são cruciais, com gambiarra, com código extenso ou não, mas precisam ser entregues e gerar valor(sim, me refiro a dinheiro, pois é isso que comanda o mundo, goste você ou não). É isso, esse vídeo foi um tapa na minha cara, e deve ser para geral mesmo. Quem sabe se a "boooollhhaa deeevvv" entender isso, o número de layoffs diminua.
Deixo mais uma vez bem claro aqui: Não estou menosprezando Clean Code ou demais outras práticas que impactam positivamente a entrega de um trabalho. Mas apenas esse chacoalhão e um desabafo.
Achei seu ponto de vista bem interessante, obg por compartilhar
o cara que acha que tem que aplicar design patterns e clean code em tudo, provavelmente não entendeu nada sobre design patterns e clean code
ai no futuro ele pede uma alteração no código e toda vez vai demorar 40% mais tempo pra entender o codigo
@@baltha_zar você ficaria surpreso em ver o quanto de Dev tem assim.
Maior problema que vejo em quem está entrando na área é a atitude do: ninguém me falou, ninguém me ensinou, não tinha no curso que eu fiz. A pessoa faz um curso de Node e React e acha que está pronta para o mercado. Não pratica lógica de programação, não se aprofunda em deployment, não busca entender como as coisas funcionam mais a fundo. Um curso não faz um dev.
Meu, tenho olhado vagas de programadores... o cara tem que ser da Nasa para "preencher os requisitos", muito louco isso. Dai a gente faz tudo num builder c++ e o pessoal fica louco em ver que um programa de poucos kbytes e uma interface gráfica amigável faz rapidamente o que aquele ""framework" leva 3x o tempo.
“Questione meus métodos, mas jamais meus resultados”
isso sem falar que vc tem reaprender o framework toda vez,
Sobre o clean code, não é sobre a função fazer literalmente só uma coisa, mas ter um único propósito. Ele explica bem detalhado isso, dividindo até em níveis de abstração.
Exatamente isso! Achei que ele interpretou essa parte de maneira bem errônea
o arquivo funcoes.php com 22 mil linhas de código vendo isso
@@MatheusSouza-ty9zk cara existe uma birra com o tio bob devido a visão politica que ele tem, tem gente que critica ele mais por esse motivo do que um real motivo nos livros dele, ai ele tentam implacar a ideia que o livro dele é inútil.
Só o ponto de enfatizar o quanto nomes são importantes e como nomear pedaços de código ajuda no entendimento do código como um todo (que é só o primeiro capitulo do livro) já Faz clean code valer a pena...
Cara, eu lembro que em 2014 o pessoal falava um pouco sobre essas tendências, mas dev fazia tanto a parte do front como back. De fato, alguns eram melhores com design, mas todos sabiam o básico. Hoje com este monte de cerimônias que mais parecem um culto que um trabalho (afinal, todo dia você precisa confessar o que fez em uma maldita daily) parece que o pessoal abraçou muito mais a tecnologia e esqueceu do negócio. Cara, em 2016 eu ainda via vagas de vb6! Será que o problema é a tecnologia que mudou ou são os programadores novos que querem usar tudo e não fazem nada? Digo isto, pois se programas em cobol, vb6, asp classic, perduraram por muitos anos funcionando e hoje em dia o sistema muda constantemente de tecnologia, algo não me parece certo.
Eu ODEIO daily com todas as minhas forças. Isso é culpa da galerinha de humanas que fica inventando problema pra vender solução é conseguiram uma brecha no meio de exatas com essa e outras bullshit
No Ceará em 2013 quando comecei a desenvolver software tínhamos uma única função o Anapropégua. Ana-pro-pégua. Analista, programador e fí duma égu4. Fazíamos tudo, reunião com o cliente, arquitetura, backend, frontend, gestão. Enfim tudo e mais um pouco.
esse termo era muito falado aqui no Piauí também, e nessa época ai, 2010 até 2014.
O que é chamado hoje de Tribes, Full Cycle, Squads
O famoso “de raça”
Ainda bem que eu fui vacinado com o Fábio Akita e não caí nesses golpes
EXATO. Logo me lembrei do Akira. Ele bate bastante em pessoas que pegam assuntos que chamam atenção para vender coisas
E isso todos fazem, pois é a "gourmetização" das coisas que vendem. Colocam uma capa de "super conhecimento" e vendem por aí...
Almoçando o Lucas Montano enquanto assisto meu almoço, mt bom
Quem nunca trampou em um projeto que em sua essencia é basicamente um crud.. não tem nada além de cadastrar, alterar e excluir registro... a parte mais complexa do código é calcular um percentual... E ai vem o dev José SOLID, José CLEAN CODE e começa enfiar 1 milhão de interface, começa abstrair a abstração, a parada que podia ser sómente uma validação e gravar no banco de dados, vira uma puta salada de código desnecessário e se vc OUSAR a criticar a "ARQUITETURA", vc não sabe nada kkkkkkk
quando o cara já bem com essas palavrinhas, já sei que é um péssimo programador e que ele não entende de fato do que ele mesmo está falando e nem sabe como e quando aplicar.
A real é que pessoas inseguras querem mostrar um monte de habilidades e técnicas, apenas e tão somente para tentar mascarar os resultados medíocres.
“Keep it simple, stupid.”
Pode ser que eu um projeto desse porte você não precise, mas quando começa a ficar mais complexo ajuda muito ter uma arquitetura limpa.
@@diegodevwebb concordo em gênero, número e grau!
Perdi meu emprego por causa de discordar de um josé Clean Arch que não era necessário para o projeto que era simples. true da true.
Ser autodidata vale pra tudo! Literalmente tudo!
Eu sou médico auto didata.
Uma pena que no cemitério aqui perto já estão notando a falta dos corpos...
Exceto homem-bomba 😅
@@psyab9375se te pegarem, fale que aprendeu com Leonardo da Vinci
auto didata = pessoa normal
na musica, Vale o mesmo
Sempre o conhecimento fez com que ajude a gente a diferenciar o que funciona e nao funciona.
Eu adoro os conceitos do Clean Code, TDD, Design Patterns, Agile Methods. Sao perfeitos GUIAS. Cada caso é um caso e se vc tem o conhecimento pra diferenciar do que vai ser bom ou nao, ai é outra coisa. Ser cego e seguir a risca tudo tambem nao vai. Vc vai gastar mais tempo tentando se encaixar nos padroes porque te vai restringir do que criar o codigo que vc precisa.
Esse dos metodos terem 1 funcionalidade eu gosto por semantica, fica mais facil de dar manutençao porque se vc pode 2 coisas e vai reutilizar a funçao, pode ser que pra outra isso nao era o esperado. Lá pra 2008 (comecei em 2006), o arquiteto leu o livro e meteu checkstyle no Java pra metodo nao ter mais de 3 linhas, tinha que fazer 1 coisa só, e por ai vai. Foi mais dificil arrumar o codigo pra que compilasse do que desenvolver. Isso ja foi um extremo, bem dificil. Eu era Junior e sofri bastante. Anos depois eu notei a diferença de produzir um codigo com um grupo que tinha lido o livro e entendiam como guia. Era muito mais facil de entender e dar manutençao nos codigos.
Design Patterns exagerado é ruim, ser extremo com clean code atrasada projeto.
Methodologia Agil mal entendido nao é agil. Saber que em algum ponto que o projeto esta, XP pode ser melhor que Scrum e ter menos problemas.
Muita coisa discutivel nesse assunto.
Na empresa em que eu trabalho se usa desenvolvimento ágil. Mas tendo vindo de outra área, engenharia mecânica, onde eu era projetista, e aplicava várias técnicas de desenvolvimento de projetos. Percebo que o ágil só funciona se você tem, logicamente, um time ágil. Você precisa de toda uma estrutura de planejamento e know how antes de implementar uma metodologia ágil. Não é simplesmente colocar um quadro de tarefas para monitorar quem faz mais. Os desenvolvedores deixaram de resolver problemas para resolver "tasks" não importa o quanto de gambiarra e o quanto isso vai quebrar o projeto depois e o quanto isso vai atrasar o conjunto da obra. No meu ponto de vista e experiência de engenharia e relatos dos colegas de outras empresas, são muito raros os casos que realmente sabem usar a metodologia ágil.
Sou desenvolvedor BackEnd(na maioria do tempo), e fazer front pra mim é extremamente complexo e massante, acho que os dois são difícil, mas o costume e a apitidão tornam um ou outro mais fácil, resumindo, é completamente pessoal.
Dev que usa estritamente os design patterns vira empregado do dev q construiu tudo com Wordpress e um monte de else if.
E o novato leva a culpa se não entender o código do dev anterior. Mesmo que seja go horse puro.
@@lucaslopes1260 o dev anterior subiu toda aplicação rodando em alguns meses, o novo dev demora 1 mês pra entregar uma feature
@@Niunzas os testes tão bonitos po Kkkkkkkk
Valeu mais uma vez Montano estou a uns bom longos 9 meses estudando front end e ja tava pensando que eu que não levava jeito ate pq "FRONT END É FACIL" mais uma vez obrigado este videos falando sobre o ego que tem na tecnologia e o que esta me mantendo firme nao entrei nessa de cursinho ate pq fiz medio tecnico mais uma vez valeu agora estou ciente que o tempo que estou levando consolidando os conhecimentos em Front nao é porque nao levo jeito ou algo assim Front end ou back é ... desculpa se fico meio confuso meu comentário mas apenas saiba que este video veio no momento certo !! VLW!!!!
Lembro que quando comecei na área quem fazia back e front na web (e até um pouco mais) era chamado de webmaster... rs.
Eu não era da área, mas lembro disso também, aqui no RJ chovia curso de web design na época, seria tipo cursos de programação hoje kkkkm
Nossa… lembrei da minha infância e adolescência agora kkk
Recomendo ler a respeito do "efeito dunning-kruger", em seguida pensar na relação sobre como maioria dos técnicos/analistas/engenheiros trabalham. Isso pode até refletir no como observar o temido "layoff".
Entendo ser necessário ter agilidade e entregas a curto prazo, mas se feito com qualidade duvidosa torna-se maioria das vezes uma "bomba-relógio" para o próximo. E com todos estes fatores, cada vez mais se torna difícil avaliar o equilíbrio no tempo dedicado entre legado e novo.
O problema é falta de experiencia na area, quem nunca programou ou programou pouco, dificilmente não vai conseguir assimilar as metodologias Agile. Porque com experiencia você pode tirar sua conclusão de cada metodo do mundo Agile. Tem projeto que não vai chegar ao fim se você seguir todas as metodologias ditas como Agile, mas existem boas praticas que que são apresentadas nas metodologias Agile que com alguma experiencia no mundo do desenvolvimento você vai adquirir automaticamento. Vejo como saudavel(mesmo com algum interesse no jaba) o surgimento de novas metodologias Agile. Do manifesto Agile o item que eu mais gosto é "Software em funcionamento mais que documentação abrangente".
Fiasco sumiu pq o chefe dele viu que ele tava com tempo livre e começou a dar mais demanda pra ele.
Se eu preciso de uma função fetchAndSaveUser eu vou desenvolver ela em algum momento se isso é necessário para o meu negócio.
Mesmo que internamente ela seja quebrada em fetchUser e saveUser, em algum momento eu vou precisar das duas funções uma após a outra e talvez com condições, por exemplo se fetchUser falha não chama saveUser.
Tranquilamente o melhor canal de yt do gênero. Parabéns !
Faltou falar da febre dos micro serviços pra qualquer tipo de projeto
Real, teve um amigo que pagou 3k em um curso
Microservices pra um projeto com 8 endpoints e 2 projetos kkkkkkkkkkkkkk
@@yuripires6806 kkkkkkkkkkk
A real é que a maioria das empresas não fazem nem testes.
Essa e a true da true kkkk
Cara nem tem um produto direito e quer meter microserviço kkk
Faltou citar teste unitário ( vou ser sacrificado agora pelos devs rocketseat), muitos devs endeusam testes unitários como se fosse a maior bala de prata do desenvolvimento
hahah pura verdade e olha que sou QA o teste unitário no mundo real "é o mais fraco"(caos se aproxima) e esse "golpes" que ele citou muitos deles cehgou até na área de QA. Eu sempre me perguntei quem criou esses desing pattern? Ele conhecia a minha empresa?sabe quanto tempo eu tenho pra entrega?Pq isso é uma lei? etc...
eu adorava quando o desenvolvedor fazia front e back , fazia o negocio com o cliente, agora tudo e AGIL e acaba sendo uma merda , a entrega do front e uma merda a entrega do back e uma merda , por que vc tem que fazer dentro de uma sprint de merda de 10 dias ou 15 dias , sendo que o trabalho e para 2 meses.
Programo desde 2010, me viro com o que tem: Sou designer, faço protótipo, desenvolvo o front, o backend, documento o backend, integro com o front, escrevo os testes, faço o deploy com CI/CD, numa boa; mas se a empresa quiser me pagar um misto e um refri de salário, eu vou entregar o equivalente
Não sou do time de jovens que acredita nos 6 meses, mas realmente estou pensando em voltar a estudar para concurso(PF), pelo menos a aprovação é 100% mérito meu. Estudar várias tecnologias , e arriscar ficar anos até conseguir a primeira vaga, ficando à mercê da subjetividade de recrutadores etc.. Sinceramente, isso é desanimador.
Das* recrutdoras (feministas que odeiam trabalhar e se esforçam para diminuir qualquer pessoa que ela julgue superior por qualquer motivo idiota da cabeça vazia delas)
Ou então um feministo desconstruídx
Pois é mano. Olha que eu já tenho certa experiência. Já trabalhei por 2 anos como dev somando estágios e emprego Full time e tô a 3 meses desempregado pq simplesmente parece que meu currículo não serve pra porra nenhuma mais. Também penso em ir para os concursos.
Para perito? Estou me preparando tbm... Área 3.
Caraca fiquei uns anos fora do YT e tu se tornou uma maquina de produzir conteúdo nesse tempo hein? hahaha bom te ver por aqui ainda mano! Tbm gostei muito da pegada desse tipo de video react/comentário, vou copiar 😂
Esse lance sobre Agile fez eu lembrar de um professor de engenharia de software que falava que o manifesro agile e os processos inspirados eram babaquice pois no fim o RUP tambem servia para os casos propandeados do Agile, bastando adaptar o RUP pegando o necessário dele 😂 . O RUP era para ele como um META processo.
Um meta processo seria um processo do processo?
@@PeX218 como um processo que permite criar processos . Ele afirmava que o RUP de permitia alta adaptação até para os casos que o agile era vendido , propagandeado.
Adorei o sotaque de Dr Rey da dublagem
Acho que quanto ao autodidata é que a pessoa iniciou pelo caminho se estudar sem nenhum curso. Este foi o meu caminho, só depois de ser desenvolvedor pleno fiz uma facul EAD. E nunca nem fui pegar o diploma...
Quem tá chegando agora acaba caindo nesses golpes. Aí fica complicafo, pois vão tirar dinheiri de alguém que pensa estar aprendendo o essencial, mas que na verdade o essencial mesmo depende da empresa, do projeto e do time onde estivermos...
Frontend é mais dificil. Os códigos são uma zona, com JS um novo framework e gambiarras com libs que já existiam mas não estão no novo framework. Admiro os FE por manterem a sanidade lidando com código, usuarios e designers/UX.
O final desse video. Eh um dos comentarios mais lucidos que vi um desenvolvedor que tem um alcance de influencer, falar abertamente, e com clareza. Achei que eu estava bugando. Saudades dos blogs a la Viva O Linux e muitos outros que era literalmente bases de conhecimento e nao rede social, como tudo hoje em dia. Ta ficando assustador
Tony é CLT ou PJ?
tony é um estagiário...pq estagiário nem é gente.
PJotinha na Startup super cool chamada Lucas Montano, aquela que tem o canal Lucas Montano que é apresentado pelo Lucas Montano.
É um escravo kkkk pagamento único e nem pra ele mesmo, foi comprado de seu dono anterior, e agora trabalha por comida e teto.
@@danigui8573estagiário é um escravo, e escravo nem é considerado gente
O conceito do SRP não é a função fazer uma única coisa! No Clean Architecture, pg. 62 explica isso com detalhes. "Um módulo deve ter apenas uma, e apenas uma, razão para mudar" / "Um módulo deve ser responsável por um, e apenas um, usuário ou stakeholder."
O que tá no clean code não é SRP, é exatamente isso da função fazer uma única coisa, tem até uma parte que ele fala que se a função tem "and" no nome ela possivelmente tá fazendo coisas demais. Clean Architecture é um outro livro
Uma das formas "Canônicas" o SRP diz que "A classe deve ter apenas uma razão para mudar!"; Mas cada um vai fazendo suas interpretações e adaptações, numa discussão teve um cara que falou que a Classe deveria ter apenas 1 metodo! KKK
Na real a galera não lê nada, não estuda nada, fica num superficial de quase tudo, não entendem nem se quer o Clean Code, o efeito desastroso para manutenção de um código "macorronico"... No fim não entendem pq os caras escreveram um livro sobre o assunto, não entendem o problema que a "ferramenta" tenta resolver... depois reclamam que não funciona "remover um parafuso com um martelo"... triste realidade...
Assim como vc nao entende o que está sendo criticado... triste realidade.
@@Adams456 argumente primata
Chegou o caga regra kkkkk
Quando o elefante na sala é performance, meu querido, arranca orm, arranca as abstrações, arranca startup cheio de manhas até chegar na regra de negócio e vai direto ao ponto com um sistema robusto de cache que aguente paulada. O resto é bullshit. Ah e outra coisa, aprende sql caralho. Quer performance? Faz suas consultas porra. ORM quando começa a enfiar regra só faz merda.
Eu assistindo esse vídeo bem na época que decidi ler Clean Code do tio Bob e Head First Design Patterns 🥲
Mas ao mesmo tempo acho que foi bom, por que estou na metade de cada um dos livros citados e comecei a sentir que não vou conseguir aplicar aquilo ali em muita coisa, e estava começando a me sentir mal por isso. Então esse vídeo me deu um certo conforto.
Design Patterns, apesar de acreditar que não vou conseguir aplicar em algum lugar, está sendo bom pra preencher vários GAPs de conhecimento em OOP que eu tenho. Além disso, é legal por que você acaba enxergando melhor de onde vem vários conceitos (Factories, Observables, Commands, Iterators, etc...) aplicados nos frameworks atualmente, como Laravel e Angular.
E o Clean Code tem sido bom pra organizar um pouco o código que escrevo, que confesso que sempre foi uma bagunça. Mas me identifique com a parte do "Se o nome da função tá grande demais, tem alguma coisa errada..." por que assim que comecei a aplicar os conceitos, comecei a ter funções com nomes bem grandes, vou me atentar mais a isso.
Estudamos os Design Patterns para quando a real necessidade da aplicação deles aparecer sabermos aplicar. Design Patterns não se sai aplicando porque acha bonito ou coisas do gênero. Aplicar Design Patterns onde não necessita é o equivalente a instalar um Elevador numa casa térrea, não tem objetivo. Porém, num edifício de 20 andares o elevador é indispensável. Tem projetos ou partes de projetos onde o(s) Design Pattern caem como uma luva para solucionar problemas complexos.
@LucasMontano, tive que parar o vídeo aqui 2.35 depois eu assisto o resto. should não é must. "as funções deveriam fazer apenas uma coisa." não "as funções devem fazer..." o peso é menor. é uma sugestão. não uma regra. aliás o próprio tio Bob fala isso direto. ufa. ainda bem que eu continuei assistindo. kkk vc ta certo. agora entendi.
eu achava que esse tipo de coisa era piada, mas tem um analista senior que é exatamente igual no meu estágio, e ele literalmente me emprestou 3 desses livros comentados, quando vi o video do bigboxSWE dei uma acordada legal.
Goooooooooooooooool ate que enfim alguém falou por mim. E tem muito mais redpill, vocẽ vai passar anos estudando AI para ser usado por banc0s e big techs. Eu tava me organizando para falar tudo isso ai que ele disse, principalmente sobre vagas na area é uma fars4, tem que se levar mais como to com uma obra.
Sensasional. Tentei falar isso pra essa boiada mais fui censurado e tive que ficar calado por depender ainda dessa renda.
Com SOA ocorreu a mesma coisa, empresas patrocinando toda uma mídia e vendendo pacotes de ferramentas, vi muitos desastres, empresas despejarem milhões e milhões e não conseguirem o sonho dourado de migrar tudo para SOA.
Com EJB a ideia inicial era boa, porém furada, mas depois ocorreu a mesma coisa, empresas vendendo os pacotes caríssimos com a mídia forte por trás.
7:31 “a gente sempre fez tudo”. Por isso que as UI de antigamente eram uma bosta né meu caro Montano? Hahaha 🫶🏼
Será?
Certeza
Do SRP, o S de Solid. Lá fala que um módulo deve fazer apenas uma coisa, na wikipédia ainda tbm fala Classe. É interessante que não fala que a "função" deve fazer uma coisa, que alias tem mais haver com "razão de mudança".
E agora me vendendo um pouco... escrevi: "Junior need rules, Senior guidelines", meu ponto lá é que todo mundo sabe mais do que fala o Clean Code do que outros livros ainda mais importantes porque... é cagação de regra e juniors precisam de algo claro "isso é certo, aquilo é errado. não pensa, só faz" e depois vão crescendo.
Frontend ficou muito complexo e atualmente o Frontend virou um universo por si só. Acho que o Frontend é complexo sim...
Freecodecamp que o diga eu tô fazendo aquilo e tô perdidasso
Bem vindo de volta Tony, sempre se empenhando em nao perdendo o angulo
Qual caminho devo traçar se eu quiser entrar na tech aqui nos EUA então (sou cidadão)?? O que vcs acham?
Frontend é um inferno, não exatamente pq criar interfaces é difícil, mas se tornou difícil, principalmente na web. Essa combinação de html, css e javascript já deu o que tinha que dar, essa stack deveria dar espaço para abordagens menos complexas para o desenvolvedor. A web está sendo construída de gambiarra em gambiarra (na verdade boa parte da computação kk) mas no front isso chegou a um expoente inimaginável
A verdade sobre front web é que é uma grande gambiarra... O HTML foi pensado para se estático, ai incluíram, posteriormente uma linguagem desestruturada (javascript) interpretada, tenta deixar dinâmico isso ei nasce uma bando de framework sempre tentando arrumar os mesmo problemas e paradigmas. MVC, MVVM e etc... O node deveria ser o padrão e gerar um web assembly. Linguagem interpretada sem ter validação de compilação é coisa de burro. Olha o movimento de Rust, que vai além de ser fortemente, tipado evita problemas de memória e etc. Compra o consumo que os navegadores usam. A W3C nunca fez um trabalho descente. Que é macaco velho viu muito, cada navegador implementar diferente as coisas. É casa da mão Joana. Com a vinda do Web Assembly pensei que iria ter algo bom, mas ainda é a mesma bagunça. A grande dificuldade no front é por conta disso. Mas não subestime as pessoa. Não há nada difícil que um humano não posso complicar mais ainda.
2:43 eu tinha quebrado e nao sabia . iniciante . 6:13 Estou numa escola técnica integrada , e os veteranos nos contaram que basicamente tinhamos que ser autodidatas e eu ja estava apreendendo conceitos basicos , mas alguns chegaram de olhos fechados nao sabendo nada da area.
Gostei do vídeo, mas vou citar você mesmo Lucas Montano, antes de discordar com Clean Code, Design Patterns e etc., primeiro conheça e aplique. É muito perigoso a galera ignorar que existem boas práticas de programação e basear apenas na própria subjetividade quando estão começando a carreira, porque nem todo código que funciona hoje vai ser bem mantenido no futuro. Trabalho atualmente numa empresa do segmento de construção civil, onde arquitetos viraram desenvolvedores, e a falta de estudo específico em boas práticas de programação criou milhares de linhas de spaghetti code, e agora a galera está desesperada nas etapas de manutenção do código. Concordo que muita gente faz golpe com Clean Code e Design Pattern, mas ignorar completamente isso é um golpe maior ainda.
Falou mal do VIM?????? Tirou sarro do ARCH LINUX???? Espera aí, vou logar na minha conta com foto de anime girl e já volto, isso não vai ficar assim, me aguardem!!!
Kkkk
Frontend é para ser fácil mesmo. Nos últimos anos que estão dificultando mesmo, um monte de framework com 5 kg de javascript, é tenebroso o ponto que chegamos para fazer algo que nasceu para ser simples
Vulgo angular...
Tudo tem seu motivo, mais complexidade para mais qualidade
Pensamento limitado, entao da mesma forma o backend é pra ser CRUD simples
@@mateushenrique833
Às vezes, menos é mais
@@wscldmas é mesmo. O lance é fazer funcionar e deixar o mais simples possível de manter (KISS keep it stupid simple). Se só crud simples resolve é pra ser só crud simples mesmo
Como funcionam as equipes e entregas aí na Disney? Usam cartões também? Tem um Scrum master ou um agile coach?
Esse vídeo do bigbox foi bem disruptivo. Curti demais, eu tinha visto no Bigbox, no The Primeagen e agora aqui.
Não acho inútil ler os livros, pois podemos absorver os conhecimentos contido neles , testar e ver se serve para cada um e usar e abstrair o que não gostar, e montar sua própria forma de customizada com o que acha ser melhor.
7:25 agora eu entendi o pq Jimmy Neutron UAhuHAuhAUhUHAhuA
Função deve fazer apenas um única coisa, é uma excelente recomendação e deve ser usada na maior parte dos códigos na minha opinião (Recomendado, não obrigatório).
Eu sempre prezo pela facilidade de leitura e manutenção de um código.
Design Pattern funciona bem só quando não tem um junior mexendo no código deixando tudo public e cagando na arquitetura. Claro, no mundo real, não existe design patterns, pois eles requerem planejamento e isso vai contra o primeiro axioma do GoHorse, prática seguida por grande maioria das empresas brasileiras.
Não vejo benefícios de separar font-end e back-end. Na verdade, só tem benefícios se tiver múltiplos front-ends (web, celular) ou se o back-end é usado com API por inúmeras aplicações. Fazer site tendo só um back-end e só um front-end é uma péssima ideia, porque os programadores tem que escrever mais código.
No final do dia, até os conteúdos que não tem um patrocinador direto acabam seguindo algumas políticas para tentar alcançar o hype da audiência.
Esse livro Clean Code é um saco. É um livro que poderia ser um paper de 4 páginas.
agile era legal até capitalizarem o "a". Aí virou cabide de emprego de coaches.
TDD é legal, mas é igual a crente da Bléia.
Sobre a falsa dicotomia facul vs autodidata, é coisa de quem não fez faculdade e tem ressentimento.
Udemy é uma bosta.
Beleza, tem essa parada de querer cagar regra. Mas sem nenhuma regra vira zona. O clean code não é perfeito e nem tudo precisa ser levado a ferro e fogo, mas pelo menos traz uma noção mínima para fazer as coisas com o mínimo de elegância. No final do dia a entrega é o que fala mais alto, mas depois da entrega vem a manutenção que as vezes pode ter um custo alto. Então não é bem um golpe
Jovem, ou vc é autodidata ou vc tem professor, não existe os dois ao mesmo tempo. Mesmo que vc aprenda algo a mais que o ensino passado pelo professor isso não é ser autodidata, vc teve orientação.
todo autodidata tem um professor direta ou indiretamente. A questão do autodidatismo é mais sobre ensino formal
@@kingoftime470 Boa colocação, mas não diria que vem do ensino formal, pq ensino formal nem existia quando o conceito foi criado, é literalmente se vc teve orientação com professor ou se não teve. O conceito de Mestre e aluno.
isso mesmo, se tem professor, então não é ser autodidata.. pessoal agora tá confundindo isso ai.. kk
Tem Gente que assiste vídeos tutoriais com Udemy ou outras é acha que por isso é Autodidata!! Vai vendo o que tem Brasil a fora!!
Se você leu um livro. Teve um professor (ou vários) so que de maneira assíncrona.
Kaban veio da linha de produção da Toyota, se não me engano... Chão de fábrica.
Sobre Clean Code e Design Patterns. Eu afirmo sem medo de errar que os maiores haters desses processos são pessoas que NÂO ENTENDERAM clean e design patterns. Infelizmente a galera precisa quebrar a cara de verdade, dando manutenção em sistema legado feito nas coxas e ser processado por cliente por entregar sistema cheio de bug. Só aí vão entender a necessidade de programar com qualidade e organização. E mesmo assim ainda vão quebrar a cabeça pra "inventar" uma engenharia no software que atenue os problemas enfrentados, quando poderiam simplesmente deixar de preguiça e estudar DE VERDADE alguma coisa na vida.
Desculpa o desabafo, mas já to de saco cheio de gente que lê as coisas na pressa e na má vontade, implementa com a bunda e depois culpa o processo. Usando uma metáfora pra entender melhor: Você lê uma receita num livro e, na preguiça de ler todo a receita, dá só uma lida por cima no "modo de preparo" e nos "ingredientes", sem se atentar aos detalhes - fogo alto ou baixo; ingredientes mais ou menos maduros; marca recomendada; ingredientes que são "a gosto". Daí na hora de cozinhar, você ainda muda a receita porque você não tinha um dos ingredientes, ou simplesmente não gosta do cheiro. Se a sua receita ficar ruim, não adianta culpar o livro, tu que é preguiçoso e não entendeu bem a receita.
Dessa forma tá cheio de gente na internet metendo bronca nos princípios e boas práticas de programação e, sem apresentar qualquer argumento razoável que justifique sua crítica, apelam para o argumento de que "o projeto está super corrido e não dá tempo de ficar implementando essas coisas". Na verdade, na maioria dos casos, um código bem organizado e implementado conforme os Princípios SOLID, te ajuda a ganhar tempo, pois tem mais facilidade para paralelizar atividades, já que todos na equipe teriam facilidade em dar manutenção nos mesmos projetos.
Inclusive a mesma coisa vale para Agile.
Eu vejo isso muito na galera de software house, alguns só cospem trabalho para o cliente e pronto. Ai fica fácil desdenhar e não valorizar boas práticas. O difícil é sustentar um sistema feito no go horse, feito no lema “quero entregar logo”.
Tem que existir o meio termo, quando o dev é mais malandro ele já vai prevendo o caos, ele já desacoplando módulos do sistema a medida que cresce pois já tem aquele faro de “isso aqui vai dar merda no futuro”
Mas veja, não quero criar intriga nem nada, mas a galera que faz isso na área, é porque não conseguiu ser empregada em áreas críticas. Explico:
Imagine se essa mentalidade preguiçosa e afobada fosse na engenharia civil?
Uma ponte iria cair e matar muita gente.
Em desenvolvimento de software, é possível entregar algo para o cliente e ir fazendo upgrades até o projeto ter chegado ao fim (isso se tiver mesmo um projeto bem estabelecido, o que eu duvido bastante).
Eu não sou da área de informática, mas vejo que está área está cada dia mais e mais cheia de gente preguiçosa chegando (e com isso os valores vão abaixando).
Não tem jeito, é necessário fazer um expurgo dos incompetentes e eles que lutem para ter o que comer.
Agile estragou o mundo de desenvolvimento fez tudo ficar mais chato e desgastante. Já fiz muitos sistemas no passado sem usar qualquer coisa de agile e foi muito menos caótico e mais divertido. O agile só aumentou o burnout nos desenvolvedores.
Acho que o maior problema dos Design Patterns é achar que eles resolvem qualquer problema. Na realidade, o problema se encaixa ao Pattern, não o contrário.
A propaganda desse vídeo pra mim, foi literalmente o ei nerd aparecendo pra falar que programação ainda tá pagando muito bem e tem vaga sobrando
meu pai trabalhou de 30 anos de mecânico em uma fábrica tu acha que ele aprendeu tudo em um curso? Faculdade? Todas as profissões têm que ser auto didata em certo nível
Eu gosto mais de backend, e conheço um pouco de front e digo que nenhum dos dois é fácil... Fácil é ficar sentado sem fazer nada... Na área de TI eu não considero nada fácil, porque em todas as atividades vc tem que ter algum nível de atenção.
O maior golpe da área inteira se chama Metodologia Ágil. O nome é lindo, que empresa que não quer usar uma metodologia que seja ágil? Mas na prática ela é a anti-engenharia. Por definição, ou você gosta de engenharia (documentar e realizar processos) ou você gosta de Agile.
Queria saber tua opinião no que o Agile se tornou Montano, nem que seja pra me xingar e falar que tô totalmente errado.
Pessoal confunde ágil com rápido, mas eh vdd, essa metodologia virou um pesadelo hj em dia, pq o pessoal só sabe seguir receita de bolo e não quer mais pensar.
Eu só queria que waterflow voltasse a moda, até empresa grande está aderindo pra fazer a gente trabalhar em cima de prazos irreais
Fazer um bot pra contar quantas vezes o Lucas Montano do canal Lucas Montano troca o titulo do video, três hipoteses a testar: 1. eu sou maluco, 2. ele está a ver o que mais entrega, 3. Montano quer criar um efeito mandela nos inscritos. Mas estou bem enviezado a aceitar a primeira
antes do fullstack éramos apenas o webmaster , ou na vdd webdesign pois esse era o termo popular pro cliente entender que criamos sites/sistemas web
Excelente conteúdo!!!
A verdade é que qualquer coisa que você usa de maneira cega como se fosse a bala de prata é ruim.
Pensando crítico faz parte em qualquer área e não existe receita de bolo para desenvolvimento de software
Diz a lenda que o Fiasco é o Lucas Montano kkkkk
Tenho essa suspeita também kk
Sobre as boas práticas, o golpe não é buscar fazê-las, mas ser dogmático. Curto muito fazer TDD, mas é loucura fazer disso um dogma. Tem muitos casos que não vale a pena.
Aquele momento que do nada muda pra inglês e pra eu não muda nada pois continuo entendendo do mesmo jeito 😂
Muito good quando this acontece :)
o que eu vejo são pessoas que não tem a maturidade suficiente ou trabalhem com algo que não precisa estruturar o codigo como se menciona nesses livros. Não vejo como golpe. o exemplo da função é clara... porém pode ter suas exceções, assim como a atomicidade de um banco de dados, pode haver algum momento em que é melhor não usar a atomicidade. O SOLID não faz sentido pra vc? não pratique. as vezes é o pessoal que quer usar "Padrões" onde não tem necessidade, mas nem por isso os ensinamento desses livros são golpes
Todo desenvoledor backend acha o front fácil, ate eu perguntar como funciona o ciclo de vida de um componente react e nenhum deles saber responder
Como esse vídeo foi traduzido ?
Tem coisa pior que "uma função só dece fazer uma coisa". Tem quem diga que uma função só pode ter 5 linhas 😂😂
Rapaz… eu não tinha me ligado que já tinha visto o The Primeagen reagindo ao mesmo vídeo até chegar a parte do FE é fácil 😂
Produtividade com vim.. putz.. essa é foda. Eu juro q eu tentei kkk 😂
e pasme, tem gente ai falando que abandonou o VS-Code e foi pro vim.. pode acreditar.
Eu sai do vscode pra usar vim, foi uma merda aprender no início, mas o principal foi a "leveza" o vim é muito mais leve que o vscode e hoje eu gosto muito de desenvolver em vim.
@@messiasolimpio1992 rs.. mas vc nao pegou projetos enormes com um monte de arquivos.. eu trabalho em empresa grande eu sei vim de cabo a rabo, mas é o que o rapaz do topico ai falou... não tem como ter produtividade alta com vim e quem soltar essa pérola numa entrevista, com certeza não será contratado.
Concordo, e olha que uso desde 2014. Mas perder tempo configurando tudo… Ainda bem que no Brasil não existe muito essa tendência de punhetar ferramentas, lá na gringa muito dev que usa VIM nem trabalha na área.
@@gepetovovo2509bem isso. Um exemplo são projetos em .NET, não tem como, o sujeito vai perder horas ou dias tentando configurar, e para que? Só para chegar a fazer 50% do que o Visual studio ou Resharper faz? Kskskk
usou heygen pra dublagem?
Vendo do ponto de vista do Brasil, há algumas considerações. Mas imagina um americano, que pagou 5mil dólares mês por 5 anos, pra se formar e quando sair ganhar 6k de dólar.
Sem a vantagem cambial, tá muito ruim ser dev. O ruim disso tudo, que não está sendo vantagem ser nada, em nenhum país. Salários sêniors mundo a fora estão congelados desde 1971, mas esqueceram de congelar a inflação.
É claramente um golpe...
o foda da TI é que o povo é fan boy.. aí tudo vira escrito na pedra. e aí que o golpe vem...
pega todos os "golpes" como nortes/orientações e usa quando faz sentido (teu exemplo de function é bom nesse sentido).
igual linguagem que é ferramenta, usa a que te atende e te faz entregar.. não te amarra em sopa de letrinhas.. (não seja mais um querendo "botar prego na parede usando um alicate" por religião)
Vcs não tem noção o alívio que eu tive quando vi o clean code lá
por um momento achei que seria um video sem defender bilionários
Nunca achei que diria isso, mas eu adoro a dublagem da IA kkkkkkkkkkkkkkkkk
Lucas, tu joga algum game?
O cara simplesmente meteu a Go Horse Pill no final kkkkkkk
Se voce é Júnior e está focado em Clean Code, a verdade é que você nao quer focar no Code, mas so no clean.
bigboxSWE em português virou o professor de la casa de papel
se o Lucas está montano imagina quando ele terminar.
O Tonny apareceu como humano em um video aqui e teve que fazer uma task de amazenamento de cpf em char ou int
Não acho que Clean code seja um golpe, acho que tem que saber USAR. O Fato é, se você é empregado ou presta serviço, O CÓDIGO NÃO É SEU !!!, Então deixe essa bagaça o minimo entendivel, reutilizável e "performático", pois outra pessoa irá gastar tempo para ler o que tu escreveu. Se voce tem o minimo de senioridade e não tem essa preocupação com teu próprio trampo, seria bom fundar um empresa e programar para vc mesmo.
po lucas to com saudade de tu montano alguma coisa, cade monta algo