Achei muito interessante a parte de utilização do banco. Algum dia você poderia fazer um vídeo explicando sua abordagem para utilização (o que abstrair, o que não abstrair etc.) pensando no contexto de um MVP. Seria muito bem-vindo.
No livro Clean Craftsmanship do Uncle Bob ele contextualiza melhor a aplicação e a fase de se pensar em "Clean Code". Mas muita coisa do Clean Code é paráfrase de textos do Ron Jeffries e de autores mais antigos. Bob promoveu uma reunião mais coesa das publicações antigas. O mais importante é entender que o Clean Code é a fase posterior ao TDD e Bob o coloca como resultado disciplinar do TDD. A medida mais precisa que muitos desprezam são os conceitos de Coesão e Acoplamento, onde a gente consegue uma medida aproximada do que de fato seria Clean Code. Muitos confudem Clean Code com patterns, o que não dão causa direta mas indireta. Refactoring do Fowler, TDD do Kent Beck e XP do Bill Wake são textos que deveriam ser obrigatórios como introdução antes de ler o Clean Code. O maior erro, na minha opinião, é ler o Clean Code sem saber o que é XP, TDD e Refactoring. Coloca-se a carroça na frente dos bois. Clean Code acabou virando merchan. Acho que seria legal um vídeo sobre acervo de livros pragmáticos de engenharia de software (série Signature da Addison-Wesley por exemplo).
De uma pesquisada sobre "Primitive Obsession". Os value objects estão muito mais relacionados a isso do que uma classe que cuida de seus próprios comportamentos. Exemplo tosco: Uma classe chamada "Pessoa" que tem um value object chamado "Endereço". A "Pessoa" vai ter as funções de adicionar o tipo "Endereço" nela mesma e o tipo "Endereço" deve ser único nessa "Pessoa". Isso é só um exemplo tosco (não sei se o melhor) mas pode ser feito com muitas outras coisas, por exemplo criar um value object para "Email", "Id", "Money" etc. Eu particularmente não sou muito a favor disso por aumentar muito a complexidade do código, porém em alguns casos deixa o código mais legível e de fácil teste. Vale a pena testar, errar e saber quando usar :)
Não quis entrar na questão do DDD com suas definições de value objects e aggregators, pois acho que acaba complicando ainda mais a vida de quem quer desenvolver um software simples hahaha
Sei lá, não gosto muito dessa abordagem que sai acoplando demais os objetos. Nesse exemplo que citou, prefiro o Endereço separado da Pessoa, é bem provável que no futuro o sistema precise permitir que a pessoa tenha mais endereços cadastrados, ou seja, um assimilação 1...N. Isso sem mencionar que talvez surja um objeto "Cliente" ou "Vendedor" por exemplo, que também vai se beneficiar do objeto Endereço desvinculado ao fluxo de "Pessoa", pois também terá um ou mais endereços cadastrados. Na sua abordagem, faz mais sentido uma abstração, onde Pessoa é uma classe abstrata, interface, derivada, base, ou qualquer que seja o nome que a sua linguagem utiliza, e aí sim, você teria objetos mais específicos, como Cliente e Vendedor, manipulando os atributos herdados de Pessoa. Enfim, também usei um exemplo tosco =)
Concordo por A mais B com a tua opinião sobre o que compõe um "código perfeito". Programação procedural (quase) sempre é mais simples, direta e menos burocrática.
Por favor, continua o vídeo, é bem elucidativo. Passei um tempo pagando os boletos com Python e agora estou migrando de volta para Java, enquanto faço aquela reciclagem, vários desses estalos "isso é muito coisa de Javeiro" vem a minha mente, inclusive, obrigado por me mostrar que eu - ainda - não estou louco, pois eu tento não ter esse viés de 'coisa de Javeiro', ainda assim ele se faz presente a todo tempo. hahahha
Pelo que eu entendi você não gosta de OOP, a maioria dos itens que você discordou são coisas que em OOP fazem sentido. O livro clean code é de uma época onde o "jeito certo" de programar era OOP, hoje a programação funcional ganhou bastante hype e tem quem prefira programação estruturada (ambientes onde o Clean Code não faz sentido)
Eu gostei do clean code quando li a primeira vez. Hoje em dia acho que não precisa usar todos os ensinamentos logo de início e que vale a pena definir o que é "limpo o suficiente" pro código que você está desenvolvendo.
Sobre o Clean Code, acho que tem muita coisa lá que é definição conceitual e não necessariamente é aplicável para você limpar código, por exemplo, tem um capítulo que fala sobre funções onde o que mais rola lá são definições como conceito de mônades, díades, etc quando o talvez o mais importante fosse entender o motivo pelo qual uso de funções com muitos parâmetros atrapalha na testabilidade delas (algo que ao meu ver o tio Bob falhou em explicar no livro). Uma recomendação minha que não tem muito a ver com a premissa do livro em si é: NÃO COMPRE A EDIÇÃO TRADUZIDA. Há traduções lá que atrapalham muito o entendimento, pois os jargões são muito mais difundidos em inglês e senti uma verdadeira frustração na versão em português, que descobri ter sido feita por um pessoal da UFRJ, onde eles cagaram toda uma lista de referências cruzadas para os code smells (uma das coisas que acho mais interessantes e aplicáveis do livro), onde você simplesmente não consegue achar tal code smell em tal página do livro porque possivelmente por causa de um aumento ou diminuição do número de páginas, houve uma defasagem da posição dos itens sumarizados... No mais é um bom livro sim, mas realmente não dá pra ficar dogmatizando essas coisas, ainda mais num mundo onde a relação prazo x valor é o que mais conta.
Essa última coisa que vc falou, sobre preferir objetos de valor acima de tipos primitivos, é exatamente o que vc desenhou no Excalidraw. É realmente pra usar uma Struct ou algo parecido.
acho que a sua interpretação de que polimorfismo e herança são sinônimos foi ruim, por exemplo com padrão strategy ou com interfaces únicas para diferentes classes concretas não deixa de ser polimorfismo, outra forma de fazer polimorfismo é ter o método com o mesmo nome, mas com a quantidade de parâmetros diferentes em linguagens com tipagem estática.
O método com o mesmo nome, mas com quantidades de parametros diferentes se chama sobrecarga, e sinceramente, parece ser algo realmente útil e proveitoso à primeira vista, mas aumenta o custo quando você precisa escrever classes de testes. Ultimamente tenho preferido utilizar somente um método com todos os parâmetros, e, se necessário, você trata os parâmetros dentro do próprio método. Facilita na hora de identificar o fluxo e ao escrever testes unitários.
Posso estar errado, mas entendo que quando a os detalhes da estrutura diz o que é, ele entendo que é um objeto (licença poética), até porque lua não tem classes ele possuí tables e as tables são objetos, e pode adicionar funções dentro da table assim como é possível fazer em C.
No final você comenta sobre Dependency Injection, nos ultimos dias eu comecei a estudar sobre Arquitetura de Portas e Adaptadores, você acha que quando deseja-se a usar esse tipo de arquitetura, no React/Nextjs, por exemplo, devo utilizar em todo o projeto?
eu finalmente li o clean code esse ano. Pra mim, ate uns 40% do livro tem bons conselhos. Mas por ja estar trabalhando numa empresa que pede codigo limpo e ter lido o arquitetura limpa, nada ali era novo. So que da metade do livro ate o final o livro fica absurdamente chato. Tao chato que da vontade de pedir uma segunda versão do livro sem essa parte para que outas pessoas nao tenham de passar por isso
Galego, nn sei se ja tem video sobre mas pode fazer um sobre recorrencia dos algoritmos? aprendi na faculdade mas hoje eu queria aperfeiçoar isso mais pois não consigo olhar para uma recorrencia de um algoritmo x dependendo do algoritmo e imaginar como ele funciona, ou o inverso, fazer uma recorrencia pra um algoritmo X.
Você não muda de banco 0.5 % das vezes, mas dependency injection ajuda a testar, embora eu não siga a escola de mock em testes, já segui mas não sigo mais
Vídeo muito bom, mas só um ponto, vc fala que nao gosta de polimorfismo, mas mostra algo no python(que nao sei o que é) que parece ser uma interface e suas implementações. Mas no geral vc consegue fazer polimorfismo com interfaces. O polimorfismo ta mais ligado com o O do solid(Open Closed Principle), ou seja, nao é somente com classes abstratas e herança
Alguem tem alguma dica, acabei de terminar o técnico e pretendo iniciar a faculdade ano que vem , porém quero seguir estudando , o que eu deveria aprender ou dominar?
Opa tudo bem ? acho que voce se equivocou na parte de objeto de valor, não seria para a estrutura de variaveis, e sim para controlar variaveis primitivas que possuem dominio restritivo, por exemplo: Email, que é uma string, porem não é qualquer string que é um email, o mesmo vale para Id's numericos, que não aceitam valores negativos, isso facilita a homogenização dos dados no sistema, voce tem certeza que todos os dados estão certos. Outro ponto, não concordo que Objetos de valor é coisa de Javeiro kk pq é horrivel de trabalhar com objetos de valor quando a linguagem não tem suporte a Operator Overloading Fora isso, otimo video !!!
A gente nota que tem muita coisa que realmente é gosto pessoal. Preferir objetos de valor ao invés de tipos primitivos pra mim é mandatório. Geralmente quem não gosta dessa regra é quem gosta mais de linguagens de tipagem mais fraca. Por mim tudo tinha que ter tipagem forte, a nivel de Rust mesmo. O quanto tem problema e bug que eu vi que podia ser evitado se função x recebesse um objeto de valor com tipo definido ao invés de um stringão genérico, não tá escrito.
o clean code e clean architecture são quase que exclusivamente para OOP. O que é pior, porque é uma forma de tornar o OOP (que já é ruim) mais "OOPzado" ainda. Já vi muitos devs (boa parte gringos) muito experientes explicarem que o problema não é exatamente o seu código acabar tendo um objeto e sim orientar todo o desenvolvimento do seu código a objetos. Não só isso causa um atraso absurdo porque você tem que ficar filosofando o que que deve ser encapsulado ou não, mas como também isso acaba sendo totalmente inviável conforme seu projeto começa a tomar grandes proporções. Talvez esse seja o problema de devs que defendem muito OOP, eles geralmente não trabalham com, ou mantém, projetos grandes e sérios.
@@Marlon21z Usam sim. A não ser que vc considere projetos como Cassandra, Kafka, Elasticsearch, Hadoop e etc. como projetos que não são sérios. Não leva a sério os comentários desse mano ai, além de só falar besteira, tem vários comentários dele desrespeitosos com a galera. Pela forma que ele fala deve ter uns 15 anos.
Cara, vi um vídeo seu de forma totalmente aleatória e você lembra muito o Gabriel Poliglota, que também tem canal no UA-cam, até a voz é similar... vc tem algum parentesco com ele? Ou eu estou maluco? Kkkkk
Eu gosto muito do Clean Code, tem muita coisa la que concordo, mas sempre achei que tem coisas muito exageradas que eu nunca concordei. Então pra mim o problema não é o Clean Code são as pessoas que tornam o livro uma bíblia onde tudo que está escrito passa a ser uma verdade absoluta.
Acho que te falta um certo entendimento do que é polimorfismo. Talvez por codar em python, mas sem polimorfismo na linguagens tipadas tudo seria procedural o que é horrível qdo o software é grande e precisa de manutenção
Clean code não é livro técnico Clean code não é livro técnico Clean code não é livro técnico E nenhum livro de opiniões sobre como programar e conduzir projetos é livro técnico Tá cheio de livro técnico por aí, envolvendo algoritmos, frameworks, teoria, mas livrinho do uncle bob é mencionado com frequência porque já é meme e é fácil de ler de ponta a ponta pra discutir no twitter, um livro técnico de verdade não é algo que todos vão ter lido, é algo que normalmente só tu dentre teus círculos vai ler, e isso vai te especializar ever-so-slightly em alguma coisa
Clean Code && Design Patterns infelizmente são mal entendidos. A proposta deles é serem: * princípios, * padrões. O que vai decidir é se adotar naquele caso será mais benéfico do que não adotar. Não precisa ser uma lei bíblica absoluta 🤔
Sou javeiro e também evito herança e polimorfismo, são ótimas fontes de bug, só não gera mais bug que mutabilidade. E o spring é um grande framework de dependency injection. Deixa muito difícil pra os novatos configurar o projeto, porque a gente nunca sabe qual arquivo vai ser lido. Eu questionei meu time esses dias, a gente usa o data jpa do spring e ele mexe tanto na query que várias vezes da problema de performance. A gente teve que refatorar o projeto para que o spring parasse de fazer queries desnecessárias. Mas no mais é top, hahahaha é verboso mas é gostoso
Bixo, se tem um livro que achei bem crítico mas coeso a certas práticas do Clean Code, foi o A Philosophy of Software Design, de John Ousterhout. Além de capítulos que abrem a mente sobre como criar interfaces e visualizar elas de uma forma bem clara. Ele mete o pau em alguns pontos do livro do Robert, tipo quando ele contraria a opinião dele sobre a extensão de métodos. Mas é tudo bem fundamentado antes dessa quebração. Eu mesmo já me vi pensando: “peraí… mas isso aqui não é viável hoje em dia”. É como você disse, o livro Clean Code é uns 70% bom, porque os outros 30% foram de água para leite vencido. Hoje em dia no lugar de Clean Code para iniciantes que já conheçam os fundamentos, recomendaria The Programmatic Programmer 2nd Edition, depois Refactoring e somente depois Clean Code. Agora se for pra botar o cara na linha de pensamento de engenheiro mesmo, então Code Complete 2 entra nessa lista.
só brasileiro? kkkk pesquisa aí: Casey Muratori x Uncle bob: clean code debacle. O uncle bob é tão fraco que acabou apelando para trolagens e memes de perna longa porque não sabe rebater uma crítica. A verdade é que ele é daqueles caras muito teóricos, que não testa a própria teoria antes de sair vendendo.
@@trex511ft Bastou o Uncle Bob se posicionar contra a cartilha dos democratas (left) pra começarem os cancelamentos... aí foi questão de tempo pro conteúdo técnico dele ser afetado.
@@ThugLifeModafocah não viaja mano kkkk, vários caras que criticaram o clean code são republicanos cristãos etc. Essas críticas vêm de décadas já, lá fora, mas aqui só agora começou a "popularizar". O uncle bob é muito falastrão, as palestras dele são 20 minutos filosofando, falando de tudo menos programação só para passar o tempo. Já desafiaram a mostrar um projeto real que ele tenha trabalhado usando todo esse "overengineering" que ele proclama ser bom. Ele não responde de forma direta e nem os fanboyzinhos dele. Preferem apelas para sarcasmo e fanboyismo. É um clássico político e como a maioria do povo em geral cai em lábia de político, programação não seria diferente (apesar que eu tinha algumas esperanças do povo dessa área ser mais inteligente, pensar por si próprio, mas me enganei. Gadisse não escolhe área).
@@trex511ft anham, confia... Ele sempre foi respeitado e debates sempre ocorreram sobre as praticas entre os dinossauros com respeito. Entretanto, quando ele se posicionou, ai começaram os ataques, os chingamentos, o cancelamento e sua contribuição passou a ser lixo.
@@trex511ft Cara, lê até o final o que eu disse... eu especifiquei que acontece no twitter e com "agressividade", o que não houve no caso do Casey. Repare no tweet que o galego mostra aos 0:45. Essas macacadas, infelizmente, é sim específicas de alguns brasileiros.
10:38 ou seja, código mais complexo kk. O ponto não é que você deve manter uma complexidade adequada, na verdade o ideal é diminuir a complexidade ao máximo mesmo, na minha opinião. A questão é que você não pode também ter uma ideia superficial de complexidade, e achar que só porque um código tem mais linhas então ele é mais complexo, ou algum outro critério superficial assim. Todos os argumentos que você utilizou pra defender uma complexidade "adequada", na verdade você está falando é de diminuir a complexidade mesmo.
Desculpe eu e meus manos amamos Java(kotlin) até dar um NPE dps disso passamos a odiar kkkk quem estuda Java ou tem 30+ ou perdeu tudo na vida e tá buscando algo pra suprir
A minha raiva com esses tipos de conselhos é que, o que era pra ser dicas e conceitos pra te ajudar no trabalho, acaba virando uma espécie de lei marcial inquestionável onde vc será severamente punido se questionar uma unica linha sequer. Quer dizer, não tem bom senso e pensamento critico, somente siga, cala a boca e venere. Se tem nome em inglês bonitinho e saiu da boca d alguem famoso, vira lei inquestionável e ai d vc se desviar uma virgula. Agora fala pra mim se isso não parece comportamento de seita?
acho que qualquer pessoa com meio cérebro que tenha tentado fazer um programa simples de terminal em C e depois em Java, percebe o quanto objeto atrasa sua vida.
Não tem problema fazer gambiarra, o problema é você não saber o que está executando, se tu sabe o motivo e as circunstâncias de estar fazendo aquilo, de como fazer melhor e o por que é uma má solução ok, até por que como o fiasco mesmo disse que trabalha na área sabe que tem momentos que nem tudo é técnico e a gambiarra vai meio que se " justificar ", vai para o backlog e depois vê kkkkkkkkkkk
Tem sim kk essa mentalidade é a raiz de muito sistema com código macarronico por aí. Você pode até usar gambiarra, mas tem que ser a exceção e tem que um excelente motivo pra isso. E logo em seguida, depois que apagou o incêndio, precisa criar uma tarefa pra refatorar a gambiarra pra não deixar o lixo acumular e depois se arrepender.
aos 0:33, concordo com o Piu... tá maluco, menina ta doidona. E quais ideias não muito legais ele tem sobre mulheres no desenvolvimento de software??? kkkkkkkkkkkkkkkk pqp. Nego vomita mesmo qualquer absurdo que lhe chega da bolhinha left sem nem se dar o trabalho.
segui teus conselhos sobre leetcode e agora sou dev junior GO em uma empresa bem grande de mobilidade urbana. Você é demaaaais!
Parabéns! Sucesso.
Quais dicas vc daria para conseguir uma vaga de junior ?
@@FelicianoOliveira-kg1cp Rebole lentinho pros cria
@@FelicianoOliveira-kg1cp cara eu só posso te falar para nunca desistir, não tenho uma receita de bolo.
Você diz toda a série de leetcode dele ou foi algum vídeo em específico que te ajudou mais nesse sentido?
Melhor canal da bolha dev, genuinamente o único que tem me ajudado
Quanto mais Javeiro melhor Galego. Viva o Java
Achei muito interessante a parte de utilização do banco. Algum dia você poderia fazer um vídeo explicando sua abordagem para utilização (o que abstrair, o que não abstrair etc.) pensando no contexto de um MVP. Seria muito bem-vindo.
seria legal
oxe, não gostei do final, na hora que estava ficando bom tu dropou! por min se tu fizer um vídeo de 1h eu vou ficar 1h vendo!
No livro Clean Craftsmanship do Uncle Bob ele contextualiza melhor a aplicação e a fase de se pensar em "Clean Code".
Mas muita coisa do Clean Code é paráfrase de textos do Ron Jeffries e de autores mais antigos. Bob promoveu uma reunião mais coesa das publicações antigas.
O mais importante é entender que o Clean Code é a fase posterior ao TDD e Bob o coloca como resultado disciplinar do TDD. A medida mais precisa
que muitos desprezam são os conceitos de Coesão e Acoplamento, onde a gente consegue uma medida aproximada do que de fato seria Clean Code.
Muitos confudem Clean Code com patterns, o que não dão causa direta mas indireta. Refactoring do Fowler, TDD do Kent Beck e XP do Bill Wake são textos que deveriam ser obrigatórios como introdução antes de ler o Clean Code. O maior erro, na minha opinião, é ler o Clean Code sem saber o que é XP, TDD e Refactoring. Coloca-se a carroça na frente dos bois. Clean Code acabou virando merchan. Acho que seria legal um vídeo sobre acervo de livros pragmáticos de engenharia de software (série Signature da Addison-Wesley por exemplo).
De uma pesquisada sobre "Primitive Obsession". Os value objects estão muito mais relacionados a isso do que uma classe que cuida de seus próprios comportamentos. Exemplo tosco: Uma classe chamada "Pessoa" que tem um value object chamado "Endereço". A "Pessoa" vai ter as funções de adicionar o tipo "Endereço" nela mesma e o tipo "Endereço" deve ser único nessa "Pessoa".
Isso é só um exemplo tosco (não sei se o melhor) mas pode ser feito com muitas outras coisas, por exemplo criar um value object para "Email", "Id", "Money" etc.
Eu particularmente não sou muito a favor disso por aumentar muito a complexidade do código, porém em alguns casos deixa o código mais legível e de fácil teste. Vale a pena testar, errar e saber quando usar :)
Não quis entrar na questão do DDD com suas definições de value objects e aggregators, pois acho que acaba complicando ainda mais a vida de quem quer desenvolver um software simples hahaha
Acho que em boas vezes um ddd bem aplicado simplifica e muito
Sei lá, não gosto muito dessa abordagem que sai acoplando demais os objetos.
Nesse exemplo que citou, prefiro o Endereço separado da Pessoa, é bem provável que no futuro o sistema precise permitir que a pessoa tenha mais endereços cadastrados, ou seja, um assimilação 1...N.
Isso sem mencionar que talvez surja um objeto "Cliente" ou "Vendedor" por exemplo, que também vai se beneficiar do objeto Endereço desvinculado ao fluxo de "Pessoa", pois também terá um ou mais endereços cadastrados.
Na sua abordagem, faz mais sentido uma abstração, onde Pessoa é uma classe abstrata, interface, derivada, base, ou qualquer que seja o nome que a sua linguagem utiliza, e aí sim, você teria objetos mais específicos, como Cliente e Vendedor, manipulando os atributos herdados de Pessoa.
Enfim, também usei um exemplo tosco =)
Vídeo ótimo. Faz a parte 2 mano, pls. E já emenda outro de arquitetura limpa.
esperando parte 2 Galego, vídeo ficou muito bom!
seus vídeos tem fôlego pra te tornar um dos maiores influencers de tech do BR, cara.
Concordo por A mais B com a tua opinião sobre o que compõe um "código perfeito". Programação procedural (quase) sempre é mais simples, direta e menos burocrática.
Curti demais esse estilo de vídeo galego é bem dahora ter essa visão pra quem tá iniciando na carreira
Esse vídeo é muito bom na explicação além do asmr do microfone batendo no cabo!
Por favor, continua o vídeo, é bem elucidativo. Passei um tempo pagando os boletos com Python e agora estou migrando de volta para Java, enquanto faço aquela reciclagem, vários desses estalos "isso é muito coisa de Javeiro" vem a minha mente, inclusive, obrigado por me mostrar que eu - ainda - não estou louco, pois eu tento não ter esse viés de 'coisa de Javeiro', ainda assim ele se faz presente a todo tempo. hahahha
Continua o video pra parte 2 mano, estou aprendendo bastante com a sua linha de visão das coisas
Gugu gosto MT de ti, vc é muito meu fã
todos somos seu fã
Kkkkk
Excelente Galego ! O assunto é importante
Pelo que eu entendi você não gosta de OOP, a maioria dos itens que você discordou são coisas que em OOP fazem sentido. O livro clean code é de uma época onde o "jeito certo" de programar era OOP, hoje a programação funcional ganhou bastante hype e tem quem prefira programação estruturada (ambientes onde o Clean Code não faz sentido)
polimorfismo é uma coisa, herança é outra (12:39)
Percebi isso tb
Eu gostei do clean code quando li a primeira vez. Hoje em dia acho que não precisa usar todos os ensinamentos logo de início e que vale a pena definir o que é "limpo o suficiente" pro código que você está desenvolvendo.
Sobre o Clean Code, acho que tem muita coisa lá que é definição conceitual e não necessariamente é aplicável para você limpar código, por exemplo, tem um capítulo que fala sobre funções onde o que mais rola lá são definições como conceito de mônades, díades, etc quando o talvez o mais importante fosse entender o motivo pelo qual uso de funções com muitos parâmetros atrapalha na testabilidade delas (algo que ao meu ver o tio Bob falhou em explicar no livro).
Uma recomendação minha que não tem muito a ver com a premissa do livro em si é: NÃO COMPRE A EDIÇÃO TRADUZIDA. Há traduções lá que atrapalham muito o entendimento, pois os jargões são muito mais difundidos em inglês e senti uma verdadeira frustração na versão em português, que descobri ter sido feita por um pessoal da UFRJ, onde eles cagaram toda uma lista de referências cruzadas para os code smells (uma das coisas que acho mais interessantes e aplicáveis do livro), onde você simplesmente não consegue achar tal code smell em tal página do livro porque possivelmente por causa de um aumento ou diminuição do número de páginas, houve uma defasagem da posição dos itens sumarizados...
No mais é um bom livro sim, mas realmente não dá pra ficar dogmatizando essas coisas, ainda mais num mundo onde a relação prazo x valor é o que mais conta.
Eu tenho a versão traduzida e realmente é bem ruim, mas não sabia que foi feita pela UFRJ. Uma pena.
Essa última coisa que vc falou, sobre preferir objetos de valor acima de tipos primitivos, é exatamente o que vc desenhou no Excalidraw. É realmente pra usar uma Struct ou algo parecido.
gostaria que continua-se
Gostei do Sweeter, onde comprar?
Polimorfismo pra mim depende, mas sempre tem que ter um grande ganho pra ser utilizado, você usa de 2 a 4 vezes no ano e olhe lá.
acho que a sua interpretação de que polimorfismo e herança são sinônimos foi ruim, por exemplo com padrão strategy ou com interfaces únicas para diferentes classes concretas não deixa de ser polimorfismo, outra forma de fazer polimorfismo é ter o método com o mesmo nome, mas com a quantidade de parâmetros diferentes em linguagens com tipagem estática.
O método com o mesmo nome, mas com quantidades de parametros diferentes se chama sobrecarga, e sinceramente, parece ser algo realmente útil e proveitoso à primeira vista, mas aumenta o custo quando você precisa escrever classes de testes.
Ultimamente tenho preferido utilizar somente um método com todos os parâmetros, e, se necessário, você trata os parâmetros dentro do próprio método. Facilita na hora de identificar o fluxo e ao escrever testes unitários.
muito bom! continue, por favor.
Posso estar errado, mas entendo que quando a os detalhes da estrutura diz o que é, ele entendo que é um objeto (licença poética), até porque lua não tem classes ele possuí tables e as tables são objetos, e pode adicionar funções dentro da table assim como é possível fazer em C.
No final você comenta sobre Dependency Injection, nos ultimos dias eu comecei a estudar sobre Arquitetura de Portas e Adaptadores, você acha que quando deseja-se a usar esse tipo de arquitetura, no React/Nextjs, por exemplo, devo utilizar em todo o projeto?
eu finalmente li o clean code esse ano. Pra mim, ate uns 40% do livro tem bons conselhos. Mas por ja estar trabalhando numa empresa que pede codigo limpo e ter lido o arquitetura limpa, nada ali era novo. So que da metade do livro ate o final o livro fica absurdamente chato. Tao chato que da vontade de pedir uma segunda versão do livro sem essa parte para que outas pessoas nao tenham de passar por isso
Concordo plenamente, meu nobre!
No aguardo da parte 2
Caralho! Com menos 1min de video e ja partiu pro ad hominem. Humildade aí
Galego, nn sei se ja tem video sobre mas pode fazer um sobre recorrencia dos algoritmos? aprendi na faculdade mas hoje eu queria aperfeiçoar isso mais pois não consigo olhar para uma recorrencia de um algoritmo x dependendo do algoritmo e imaginar como ele funciona, ou o inverso, fazer uma recorrencia pra um algoritmo X.
O que acha do livro: Desmistificando Algoritmos do Cormen?
alguem sabe que programa que ele usa para escrever no final, to precisando.
Excalidraw ?
Você não muda de banco 0.5 % das vezes, mas dependency injection ajuda a testar, embora eu não siga a escola de mock em testes, já segui mas não sigo mais
Qual o nome desse "sketch pad"?
já tem o próximo vídeo? se fosse de 1h eu assistiria tava dhr
Vídeo muito bom, mas só um ponto, vc fala que nao gosta de polimorfismo, mas mostra algo no python(que nao sei o que é) que parece ser uma interface e suas implementações. Mas no geral vc consegue fazer polimorfismo com interfaces. O polimorfismo ta mais ligado com o O do solid(Open Closed Principle), ou seja, nao é somente com classes abstratas e herança
O medo do desconhecido assusta o dev. O problema nem é o código mas sim a pressa para entregas e o perfeccionismo.
Convenção padrão vocês são do time
When {
}
Ou do time
When
{
}
Escolha com sabedoria
2 opção
Primeira opção.
Polimorfismo não é somente herança. Dependency inversion é uma forma de usar polimorfismo, por exemplo.
ele confundiu polimorfismo com herança.
Galego sempre sensato.
Já esbarrei em vários códigos ruim só voltando em repositórios antigos meus
Orm mal utilizado é a raiz de todos os mals.
Alguem tem alguma dica, acabei de terminar o técnico e pretendo iniciar a faculdade ano que vem , porém quero seguir estudando , o que eu deveria aprender ou dominar?
Lógica de programação.
Opa tudo bem ? acho que voce se equivocou na parte de objeto de valor, não seria para a estrutura de variaveis, e sim para controlar variaveis primitivas que possuem dominio restritivo, por exemplo: Email, que é uma string, porem não é qualquer string que é um email, o mesmo vale para Id's numericos, que não aceitam valores negativos, isso facilita a homogenização dos dados no sistema, voce tem certeza que todos os dados estão certos.
Outro ponto, não concordo que Objetos de valor é coisa de Javeiro kk pq é horrivel de trabalhar com objetos de valor quando a linguagem não tem suporte a Operator Overloading
Fora isso, otimo video !!!
A gente nota que tem muita coisa que realmente é gosto pessoal. Preferir objetos de valor ao invés de tipos primitivos pra mim é mandatório. Geralmente quem não gosta dessa regra é quem gosta mais de linguagens de tipagem mais fraca. Por mim tudo tinha que ter tipagem forte, a nivel de Rust mesmo. O quanto tem problema e bug que eu vi que podia ser evitado se função x recebesse um objeto de valor com tipo definido ao invés de um stringão genérico, não tá escrito.
o clean code e clean architecture são quase que exclusivamente para OOP. O que é pior, porque é uma forma de tornar o OOP (que já é ruim) mais "OOPzado" ainda. Já vi muitos devs (boa parte gringos) muito experientes explicarem que o problema não é exatamente o seu código acabar tendo um objeto e sim orientar todo o desenvolvimento do seu código a objetos. Não só isso causa um atraso absurdo porque você tem que ficar filosofando o que que deve ser encapsulado ou não, mas como também isso acaba sendo totalmente inviável conforme seu projeto começa a tomar grandes proporções. Talvez esse seja o problema de devs que defendem muito OOP, eles geralmente não trabalham com, ou mantém, projetos grandes e sérios.
@@trex511ft Projetos grandes e sérios não usam OOP? Foi mal se a pergunta for óbvia, sou iniciante
@@Marlon21z Usam sim. A não ser que vc considere projetos como Cassandra, Kafka, Elasticsearch, Hadoop e etc. como projetos que não são sérios.
Não leva a sério os comentários desse mano ai, além de só falar besteira, tem vários comentários dele desrespeitosos com a galera. Pela forma que ele fala deve ter uns 15 anos.
Sim, continue o vídeo concordando/discordando de clean code :)
Povo fala muito do Clean Code, mas negligenciam outros livros bons como o Code Complete 2.
Faz a parte 2 sim
Cara, vi um vídeo seu de forma totalmente aleatória e você lembra muito o Gabriel Poliglota, que também tem canal no UA-cam, até a voz é similar... vc tem algum parentesco com ele? Ou eu estou maluco? Kkkkk
faz um de dicas de system design.
Eu gosto muito do Clean Code, tem muita coisa la que concordo, mas sempre achei que tem coisas muito exageradas que eu nunca concordei.
Então pra mim o problema não é o Clean Code são as pessoas que tornam o livro uma bíblia onde tudo que está escrito passa a ser uma verdade absoluta.
Faz um vídeo sobre "como sair de um dev junior de 10 anos"
Acho que te falta um certo entendimento do que é polimorfismo. Talvez por codar em python, mas sem polimorfismo na linguagens tipadas tudo seria procedural o que é horrível qdo o software é grande e precisa de manutenção
Dica, passa um filtro pra remover os cliques do teu áudio no audacity
De que adianta seguir o clean code se na vida real é a estrutura pastas dentro de pastas do PHP e o Java JSF, JSP com thymeleaf.
continue
Clean code não é livro técnico
Clean code não é livro técnico
Clean code não é livro técnico
E nenhum livro de opiniões sobre como programar e conduzir projetos é livro técnico
Tá cheio de livro técnico por aí, envolvendo algoritmos, frameworks, teoria, mas livrinho do uncle bob é mencionado com frequência porque já é meme e é fácil de ler de ponta a ponta pra discutir no twitter, um livro técnico de verdade não é algo que todos vão ter lido, é algo que normalmente só tu dentre teus círculos vai ler, e isso vai te especializar ever-so-slightly em alguma coisa
"Clean code não é um livro técnico" meus olhos sangram
Kkkkkkk
Clean Code && Design Patterns infelizmente são mal entendidos. A proposta deles é serem: * princípios, * padrões. O que vai decidir é se adotar naquele caso será mais benéfico do que não adotar. Não precisa ser uma lei bíblica absoluta 🤔
Ué, implementação de interface é polimorfismo
poh paizão tu ainda pergunta??
por mim tu lia o livro inteiro concordando/discordando linha a linha
Sou javeiro e também evito herança e polimorfismo, são ótimas fontes de bug, só não gera mais bug que mutabilidade.
E o spring é um grande framework de dependency injection. Deixa muito difícil pra os novatos configurar o projeto, porque a gente nunca sabe qual arquivo vai ser lido. Eu questionei meu time esses dias, a gente usa o data jpa do spring e ele mexe tanto na query que várias vezes da problema de performance. A gente teve que refatorar o projeto para que o spring parasse de fazer queries desnecessárias. Mas no mais é top, hahahaha é verboso mas é gostoso
Bixo, se tem um livro que achei bem crítico mas coeso a certas práticas do Clean Code, foi o A Philosophy of Software Design, de John Ousterhout.
Além de capítulos que abrem a mente sobre como criar interfaces e visualizar elas de uma forma bem clara. Ele mete o pau em alguns pontos do livro do Robert, tipo quando ele contraria a opinião dele sobre a extensão de métodos.
Mas é tudo bem fundamentado antes dessa quebração.
Eu mesmo já me vi pensando: “peraí… mas isso aqui não é viável hoje em dia”. É como você disse, o livro Clean Code é uns 70% bom, porque os outros 30% foram de água para leite vencido.
Hoje em dia no lugar de Clean Code para iniciantes que já conheçam os fundamentos, recomendaria The Programmatic Programmer 2nd Edition, depois Refactoring e somente depois Clean Code.
Agora se for pra botar o cara na linha de pensamento de engenheiro mesmo, então Code Complete 2 entra nessa lista.
"então até a próxima,,,," ahahahahahahaha
resolve advent of code pra nos
O final ficou truncado, acabou de repente
Hoje de manhã coloquei meu pedido de amigo oculto esse Livro de Clean Code hahaha
Esse hate em cima do uncle bob é feio e brega demais. Ainda mais vergonhoso é que só brasileiro parte para agressividade lá no twitter dele.
só brasileiro? kkkk pesquisa aí: Casey Muratori x Uncle bob: clean code debacle. O uncle bob é tão fraco que acabou apelando para trolagens e memes de perna longa porque não sabe rebater uma crítica. A verdade é que ele é daqueles caras muito teóricos, que não testa a própria teoria antes de sair vendendo.
@@trex511ft Bastou o Uncle Bob se posicionar contra a cartilha dos democratas (left) pra começarem os cancelamentos... aí foi questão de tempo pro conteúdo técnico dele ser afetado.
@@ThugLifeModafocah não viaja mano kkkk, vários caras que criticaram o clean code são republicanos cristãos etc. Essas críticas vêm de décadas já, lá fora, mas aqui só agora começou a "popularizar". O uncle bob é muito falastrão, as palestras dele são 20 minutos filosofando, falando de tudo menos programação só para passar o tempo.
Já desafiaram a mostrar um projeto real que ele tenha trabalhado usando todo esse "overengineering" que ele proclama ser bom. Ele não responde de forma direta e nem os fanboyzinhos dele. Preferem apelas para sarcasmo e fanboyismo.
É um clássico político e como a maioria do povo em geral cai em lábia de político, programação não seria diferente (apesar que eu tinha algumas esperanças do povo dessa área ser mais inteligente, pensar por si próprio, mas me enganei. Gadisse não escolhe área).
@@trex511ft anham, confia... Ele sempre foi respeitado e debates sempre ocorreram sobre as praticas entre os dinossauros com respeito. Entretanto, quando ele se posicionou, ai começaram os ataques, os chingamentos, o cancelamento e sua contribuição passou a ser lixo.
@@trex511ft Cara, lê até o final o que eu disse... eu especifiquei que acontece no twitter e com "agressividade", o que não houve no caso do Casey. Repare no tweet que o galego mostra aos 0:45. Essas macacadas, infelizmente, é sim específicas de alguns brasileiros.
10:38 ou seja, código mais complexo kk. O ponto não é que você deve manter uma complexidade adequada, na verdade o ideal é diminuir a complexidade ao máximo mesmo, na minha opinião.
A questão é que você não pode também ter uma ideia superficial de complexidade, e achar que só porque um código tem mais linhas então ele é mais complexo, ou algum outro critério superficial assim. Todos os argumentos que você utilizou pra defender uma complexidade "adequada", na verdade você está falando é de diminuir a complexidade mesmo.
O polimorfismo vai depender do projeto que tu está criando.
Desculpe eu e meus manos amamos Java(kotlin) até dar um NPE dps disso passamos a odiar kkkk quem estuda Java ou tem 30+ ou perdeu tudo na vida e tá buscando algo pra suprir
Po, termina isso kkk
A minha raiva com esses tipos de conselhos é que, o que era pra ser dicas e conceitos pra te ajudar no trabalho, acaba virando uma espécie de lei marcial inquestionável onde vc será severamente punido se questionar uma unica linha sequer. Quer dizer, não tem bom senso e pensamento critico, somente siga, cala a boca e venere. Se tem nome em inglês bonitinho e saiu da boca d alguem famoso, vira lei inquestionável e ai d vc se desviar uma virgula. Agora fala pra mim se isso não parece comportamento de seita?
amo usar polimorfismo, mas programo em java então deve ser isso kkkkkk
caralho nunca concordei tanto com alguem em um video
Escrever codigo ruim hoje te faz escrever codigo bom depois.
Acho a escrita do uncle bob ruim, que livro moroso.
Continua
Consegue explicar melhor pq ti não gosta de objetos?
acho que qualquer pessoa com meio cérebro que tenha tentado fazer um programa simples de terminal em C e depois em Java, percebe o quanto objeto atrasa sua vida.
Não tem problema fazer gambiarra, o problema é você não saber o que está executando, se tu sabe o motivo e as circunstâncias de estar fazendo aquilo, de como fazer melhor e o por que é uma má solução ok, até por que como o fiasco mesmo disse que trabalha na área sabe que tem momentos que nem tudo é técnico e a gambiarra vai meio que se " justificar ", vai para o backlog e depois vê kkkkkkkkkkk
Tem sim kk essa mentalidade é a raiz de muito sistema com código macarronico por aí. Você pode até usar gambiarra, mas tem que ser a exceção e tem que um excelente motivo pra isso. E logo em seguida, depois que apagou o incêndio, precisa criar uma tarefa pra refatorar a gambiarra pra não deixar o lixo acumular e depois se arrepender.
aos 0:33, concordo com o Piu... tá maluco, menina ta doidona. E quais ideias não muito legais ele tem sobre mulheres no desenvolvimento de software??? kkkkkkkkkkkkkkkk pqp. Nego vomita mesmo qualquer absurdo que lhe chega da bolhinha left sem nem se dar o trabalho.
Pelo visto voce nao é muito fã de OOP. Seria legal um video desteinchando isso
uncle bob based
bom vídeo, seu casaco é ridiculo
Clean Code só acerta nas coisas triviais.