Eu acho que a afirmação do "código limpo ser código testável" poderia ser modificada para: "código limpo é código com boa testabilidade". Um código cheio de dependências e responsabilidades é muito mais difícil de testar (não é impossível) do que um código mais coeso e menos acoplado, que é o código limpo. Então temos a testabilidade como um indicador preciso para avaliar um bom design de código.
Concordo em parte. Testabilidade, no caso falando de testes automatizados, são parâmetro de qualidade absoluto somente pra cagadores de regras, com o perdão da palavra. Tem que se analisar a arquitetura do sistema e ver qual é o melhor caminho para se ter um código seguro e limpo. Já vi muitas empresas com código cheio de over engineering, testes em tudo quanto é canto, mas que era mexer 5 minutos pra ver uns bugs escrotíssimos acontecendo. Resumindo: fazer 40 testes p validar um campo de cpf não deixa seu sistema digno de um premio nobel. Tem que saber pesar a mão e fazer um código que funciona, e se determinada regra do clean code estiver deixando seu código complexo demais de maneira ruim, melhor pensar duas vezes antes de segui-la.
@@emanuelmartins9508, é aí que entra a experiência profissional da pessoa para "formar uma opinião". Eu trabalho há mais de 10 anos com TI e os códigos mais fáceis de testar que eu encontrei eram sempre os mais bem escritos. É claro, a sua experiência pode ter sido outra, e nela você pode ter encontrado exceções à regra. Mas assim como o Uncle Bob, sempre notei essa relação entre um bom design de código e sua testabilidade. Não é cuspir regras pela regra em si, é criá-las ou seguí-las baseado na sua vivência profissional.
Perfeitamente colocado. Depois que comecei a escrever testes, meu código ficou muito mais organizado e desacoplado. No começo sofri bastante para testar codigos antigos e acabei entendendo na pele kk.
Estou no mercado tem mais de 14 anos e falo que antes e depois de pegar código de pessoas que entendem o propósito do clean code tem muita diferença. Não são regras mas são ideias muito fáceis de aplicar. Faço questão que minha equipe tenha ideia disso porque dar manutenção é muito mais fácil. Só teste não faz isso, falo por experiência. Testes são essenciais Ótimo vídeo casal 😄
@@LeonardoLuzx tmbm fiquei na duvida. E tmbm ele não deixa claro quais são as "regras do clean code" que ele impõe a equipe dele e que "facilita o trabalho".
@@LeonardoLuzx rapaz! Teste em geral é importante. Onde estou temos por parte de dev os unitários, integração e funcional. A equipe que entrou agora valoriza o código limpo, as clases ficaram menores, menos acopladas, nomes fáceis de entender, contexto bem separado e bem modular. Com os testes unitários e funcional que sempre peço pra eles terem bom senso porque a cada refactoring se detecta possíveis diferenças de comportamento. Com isso pude fazer refactorings grandes. Tem uma equipe de QA que linda com negócio e suas automações. Eu não me preocupo. Com as regressões ok, o código a produção sempre chega redondo. Com isso a gente raramente tem bug e a equipe sempre esta trabalhando em features e não bugfix. Hotfix em 2 anos tivemos 1 porque business queria pra ontem. Achando ruim ou não, de acordo ou não, pelo menos tenho estabilidade.
@@emanuelmartins9508 quando vc puder ler o livro e passar por diversos problemas, pode fazer algum sentido. Mas o uso é opcional =) Só sugiro a quem se interessar.
Acho lindo este conceito de desenvolver um código tão claro, que fica até redundante se colocar comentários, mas quando estou aprendendo uma nova linguagem, os comentários ajudam muito a reforçar a compreensão.
Mas isso é um contexto diferente. Os comentários no código, citados no livro, é que o seu método deve ser construído de forma que você não necessite de um comentário para entender a lógica dentro dele. Isso é diferente de comentar para entender como a linguagem funciona. Isso entra na regra de algo especifico e que entra como algo que deve ser comentado.
O autor do livro constrói os argumentos e conceitos com exemplos e lógica, faz a gente pensar e refletir em cada caso. Não me lembro dele chegar e falar "É assim e pronto". Mais ou menos na metade do livro, ele quebra algumas regras anteriores, pois em tais situações é melhor de uma forma X ou Y. Ou seja, ele nos ensina também a pensarmos além do que está no livro. Nos ensina a pensar nas próximas pessoas que irão olhar nosso código ou você mesmo depois de um tempo. Me ajudou demais e mudou minha forma de codar. Li enquanto estava no estágio e fez total sentido para mim. De vez em quando volto para relembrar alguns detalhes 🙌
ele mesmo deixa claro no livro que o Clean Code é como uma arte marcial: cada um escolhe qual arte marcial quer seguir, mas cada arte marcial terá suas regras, vantagens e desvantagens, às vezes, lutar karatê numa luta de queda pode não ser a melhor escolha.
Livros técnicos e totalmente voltados a uma tecnologia ou um problema específico tendem a envelhecer azedando. Concordo com o amigo de cima, Mateus Gomes, o livro em questão ajuda a abrir a cabeça, traz reflexão para nos melhorarmos, não estabelece as coisas como escritas em pedra, como se fossem leis. Acho legal livros do tipo, conceituais, um ponto de referência, que pode ser adaptável à tecnologia a ser usada e atualizado às tendências de cada época, ou mesmo de um projeto específico (até porque sabemos que, apesar de ideal, não é sempre que conseguimos seguir a cartilha de testes 100%).
Eu era um dos "infelizes" desenvolvedores que teve que usar EJB 2 e para mim faz todo sentido o que o Uncle Bob diz no capítulo 11 do livro sobre os problemas do EJB, que era algo comum na época de lançamento do livro (2008). Mas acredito que a geração atual que não sofreu com esse código enterprise do passado talvez precise de uma 2ª edição, ensinando os mesmos princípios mas utilizando exemplos de erros em tecnologias mais recentes.
Um vídeo para cada regra do Clean Code seria incrível. Parabéns pelo canal que mantém todos nós atualizados, pois cada dia é mais difícil ter tempo para destrinchar um livro.
Excelente video, penso da mesma forma. Clean code não é para quem está aprendendo e sim para quem já tem experiencia e tambem vivencia de mercado. Clean Code e Clean Arquiteture não é um livro de regras e sim um livro para se extrair as melhores experiencias, e entender como se utilizar no dia a dia. Parábens pelo conteudo.
Como tudo na vida, a gente retêm o que faz sentido pra gente e ignora o restante. Esse livro possui muito conhecimento relevante, mas nem todo muito vai ter a necessidade, ou a oportunidade, de implementar tudo que ele oferece.
Eu discordo em partes do ponto de não ser para iniciantes, eu li quando era estágiário e mudou muito a forma como pensava em software, algumas das dores você só vai sentir com a experiência, re-li o mesmo alguns anos depois e tive uma visão bem mais ampla do que a primeira leitura, mas ambas se complementaram, ler sendo iniciante é uma boa na minha visão, mesmo que você não absorva tudo, só não deve ser tomado como um conjunto de regras imutáveis.
Também sou fã de CleanCode, e digo mais... É extramamente necessário conhecer esses conceitos contidos no livro depois de já se ter uma certa xp em desenvolvimento.
Definitivamente Clean Code não é um livro para quem está aprendendo a programar, eu li ele quando estava começando, e mais bagunçou do que ajudou meu aprendizado. Recentemente eu fui reler e parecia que eu estava lendo outro livro. A percepção que eu tive foi muito diferente. Atualmente meu livro está todo riscado, cheio de anotações, pra mim ele se tornou essencial.
@@kamilakksrs A hora certa de pegar esse livro é quando você pegar um código de alguém pra revisar ou fazer a migração de um sistema e sentir vontade de xingar as 7 gerações da família do autor ksksk
Eu uso vários dos conceitos abordados no Clean Code no meu dia a dia de trabalho, e sempre evita possíveis refatorações posteriormente. Clean Code e Clean Architecture, em minha opinião, são livros de cabeceira e só o tempo pode mudar minha opinião! hehehe
Li o livro em pequenas doses e posso dizer que me ajudou demais a melhorar a qualidade do meu código. Tanto os conceitos de código limpo quanto os de arquitetura limpa são muito importantes e nos ajudam sim a fazer códigos melhores e com mais qualidade. A questão da testabilidade é outro ponto crucial pois muitos princípios são empregados para garantir isso, desde DRY, KISS, YAGNI até SOLID. Usando por exemplo injeção de dependências conseguimos criar mocks bem mais facilmente do que declarar tudo dentro da própria classe ou função.
Você chegou a assistir nosso Dicionário do Programador sobre Clean Code? th-cam.com/video/ln6t3uyTveQ/w-d-xo.html De qualquer forma cada regra citada no livro vale uma reflexão em vídeo também. Grande abraço!
Eu apliquei os principios do clean arch, clean coding, solid, ddd e etc e posso afirmar fez uma diferença enorme. Criei um projeto inicial em 6 meses e com menos de 2 meses criei outro reaproveitando as abstracoes que desenvolvi no primeiro.
Na minha humilde opinião, eu acho que o livro do Clean Code ainda é relevante mesmo após tantos anos de seu lançamento. Lógico, podem existir alguns pontos que já foram superados pela evolução das linguagens de programação, mas eu acho que a mensagem do que é importante ainda vai estar lá no livro. Diferente dos apresentadores, eu acho que mesmo os iniciantes deveriam ler o livro! Se por algum motivo algo não fizer sentido num primeiro momento, leia novamente até entender. Nos meus cerca de 13 anos de desenvolvimento, os melhores códigos que vi foram de pessoas que tinham o Clean Code como uma espécie de bíblia da salvação. Por outro lado, os piores códigos foram de pessoas que sequer sabiam da existência do livro.
Muito bom o vídeo. Posso acrescentar que estou lendo o Código Limpo, e até agora estou gostando e percebendo que está trazendo boas práticas no meu codificar, confesso também que algumas partes são muito avançadas para mim como o capítulo sobre sistemas. Acrescento ainda que o livro responde umas perguntas mas gera outras em contra-partida, por isso considero um livro introdutório sobre boas práticas de programação, e também que deve ser lindo mais de uma vez. Uma coisa que deixa a gente a ver navios as vezes é que os autores abordam termos que não são suficientemente explicados no Livro como a Lei de Demeter e o Princípio do Aberto Fechado. Por outro lado, esperar que apenas um livro ilumine todo o caminho de um assunto tão complexo como desenvolvimento de software é muita exigência.
Muito bom! Eu li o livro já com muita caminhada na carreira. Muita coisa eu já fazia pela própria experiência, na verdade pouca coisa eu pude aproveitar. Mas no geral foi uma boa leitura sim.
A primeira coisa que me chamou atenção nesse livro foi logo no começo o Tio Bob falar de Lean , sou certificado GreenBelt e trabalhei muitos anos com melhoria de processos, e isso aplicado a programação muda sua atitude.
Vejo o Clean Code como alguns "guidelines", ou seja, uma referência de boas práticas na qual eu pauto meu trabalho, e não necessariamente como um livro de regras onde se eu não seguir qualquer uma delas eu serei um péssimo profissional. Ao ver a motivação desse vídeo, os comentários do rapaz sobre o trabalho do Uncle Bob, muito ficou para mim sobre essa idéia que alguns jovens profissionais tem de que é necessário tentar questionar ou destruir algo que é estabelecido (e que certamente tem uma forte razão para ser tão popular). Oras, o Uncle Bob esta nesse mercado muito antes da maioria de nós termos inclusive nascido, ele viu a ascensão e a maturação de muitas das tecnologias que tomamos hoje como certas. Porque se posicionar de maneira tão arrogante quanto ao trabalho dele? No mínimo devemos um grande respeito a esse que certamente é um bastião de nossa área. Dito isso, acho que o Clean Code envelheceu muito bem, e é um livro importante na formação de profissionais da nossa área. Mas concordo com a opinião do Gabriel de que não é um livro para se ler logo no início da carreira.
Concordo plenamente, só porque um código não tem testes não quer dizer que ele é ruim ou não profissional. O que realmente importa é o contexto em que isso é usado, e se é possível também aplicar e a qualidade dos testes como mencionado. Quando comecei a programar também nem sequer sabia que isso existia, e de certa forma, escrevia códigos com o SOLID (do meu jeito), mas quando li sobre, meus códigos melhoraram MUITO, MAS MUITO MESMO!
Código eficiente é aquele que entrega o melhor resultado com o mínimo de esforço, tanto no desenvolvimento quanto na manutenção. Tem códigos que de tão simples, se forem colocados em testes automatizados terão sua complexidade aumentada prejudicando a performance e a manutenabilidade. E por outro lado existem códigos que precisam de testes porque não podem ser desacoplados. No fim, não adianta saber “o que/como fazer” se você não souber QUANDO usar cada forma de fazer.
Já trabalho com programação desde a década de 1980 (RPG II, RPG III e RPG IV, linguagem proprietária da IBM para sistema S36, S38 e AS/400) quando nem se falava ainda de OOP e uma das instruções que mais detestava e por isso NUNCA usava, era o famigerado GO TO, que eu costumava dizer que me provocava dor de pescoço de tanto andar subindo e descendo linhas para ler o código (sempre que tinha que trabalhar com código de alguém com essa instrução, sentia a necessidade de refatorar, para conseguir entender, como se tivesse TOC), por isso, sem saber já usava "Clean Code", pois acabava criando tantas procedure (na verdade se chamava ainda Sub-rotinas), quanto as necessária para evitar repetir código e criar blocos que código quilométricos.
Famoso código espaguete. A solução é SRP (princípio da responsabilidade única) e Use Vertical Formatting (os códigos devem ser lidos de cima para baixo).
Clean Code é ótimo.. Os conceitos apresentados no livro podem ser aplicados em inúmeras linguagens de programação. O conceito base não muda, claro que cada framework terá suas boas práticas, mas conceitos de código limpo devem ser seguidos sempre
Gosto muito do Clean Code e do Clean Architecture e acho eles importantíssimos de se ler quando já se tem média experiência (não recomendaria pra quem ta começando), porém um que acho obrigatório (na minha opinião) é o The Clean Coder. Eu acho esse livro simplesmente incrível e me ajudou nos piores momentos da minha carreira e ajuda até hoje.
Uncle Bob fez um masterclass que é tipo um resumo dos livros dele e ainda fala e repete muita coisa que fala em outras entrevistas que ele dá, fiz uma playlist e recomendo sempre: th-cam.com/play/PLo61EKto8ZPHUOld83z0pwpzdlioliu6j.html Acho que foi os livros Clean Code e Clean Coder que me ligaram "o switch" de fazer da programação minha profissão. Eu já programava faz tempo, mas era só "fazedor de código", mas esses livros me abriram os olhos de ser profissional com o código. E acho que poderia ter algumas entradas do dicionário do programador falando daqueles livros de programação clássicos, incluindo o Clean Code!
De uns meses para cá, começou-se a questionar o Uncle Bob mais constante e incisivamente; infelizmente, o motivo é POLÍTICO. Querem "cancelar" o Uncle Bob e sua obra por motivos que nada têm a ver com programação... Às vezes, fazem críticas mais abertamente; às vezes, criticam a obra "de maneira imparcial" para atingi-lo, com foi o caso. Devo muito ao Uncle Bob e aqui é fechamento total com o véio! 👊 #TeamUncleBob
Olha...vcs conseguem pegar algo, de certa forma, complexo de entender em um primeiro momento e transformar isso totalmente compreensível e interessante. Nem precisa acelerar o vídeo, pq nem se percebe o tempo passar absorvendo o conhecimento e vivência q vcs nos passam aqui. Obrigado!
Destrinchar um a um seria uma grande "LEGADO" do código fonte no bom sentido, pois ajudaria a profissionalizar milhares de programadores por longa data, e com a qualidade da explicação de vcs seria algo único no TH-cam.
O livro de fato apresenta ideias que para um iniciante não faz sentido; mas algumas são extremamente importante para uma pessoa que inicia na programação, como por exemplo nomes de classes, métodos e etc. Em relação aos comentários, nada melhor que o código como "comentário". Sim para um desenvolvedor aspirante é importante comentar para entender didaticamente o que está acontecendo, mas para um profissional com vivência na área, o código é o comentário. Por fim, o clean code foi um livro que mudou minha forma de programar, transformando- me em um desenvolvedor de qualidade. Recomendo sempre ele para todas as pessoas que desejam aprender as boas práticas de programação.
Na saga de alcançar o clean code eu cheguei no Haskell, recomendo, fica difícil querer voltar a usar outras linguagens de novo. É como se tudo que o livro fala estivesse nativo na linguagem, ela te faz escrever código limpo sem pensar muito.
Pra mim, foi mais um carinha daqueles que apenas critica baseado na bolhinha dele. O livro faz um ótimo serviço ao puxar esses tópicos bastante importantes. É tipo uma pílula de conhecimento que você pode receitar para alguém que esteja já buscando um pouco mais de técnica e melhoria, depois de superadas as barreiras iniciais.
O momento que estou lendo esse livro, em um momento iniciante ainda estou estudando lógica da programação estudando algoritmos! Com certeza não é o melhor momento para essa leitura mais a conclusão que tiro nesse momento que será bom para que eu possa ter uma ótima base para poder começar escrever meus códigos! Forte abraço muito obrigado pelo vídeo.
Acho que seria legal falarem sobre o cracking the coding interview. Recebi essa indicação de um engenheiro de software em uma palestra sobre o processo seletivo para a google e já adicionei na minha lista de leitura.
Isso não é um livro de ficção que você para um final de semana e lê, é um livro que se lê aos poucos, tem que ser digerir cada capítulo, fora a ênfase em SRP que é fantástica.
@@ramirorccastro Me ajudou muito sim, mas realmente algumas traduções do livro mais atrapalham do que ajudam haha, fora isso é ótimo para o nosso conhecimento!
Sobre o primeiro ponto concordo com o Twitter, acredito que ele está falando sobre testes automatizados, e no mundo real testes são caros, tenho projetos que rodam a anos sem manutenção e ter feito testes pra eles iria impossibilitar o projeto por questões de tempo e/ou custos, acho esses autores muito bons, mas parece que não estão no mesmo mundo real que a gente, alguns detalhes muito teóricos que não vejo se aplicar no dia a dia, ótimo video
O que o pessoal tem que entender com o livro assim como todos os livros é que não precisam necessariamente levar tudo que está ali como verdade absoluta. Um dos melhores exemplos é o uso de I em interfaces como IService, que o Uncle Bob abomina tanto mas em varias linguagem é um padrão definido, não leia cegamente e trate o Tio Bob como um deus da programação e conhecedor de toda a verdade
Enxergo da seguinte maneira: desenvolvedores são a caixa de ferramentas. Esses conceitos são as ferramentas em si. é importante irmos conhecendo novas técnicas, comportamentos, possibilidades, para que no momento certo, utilizemos a ferramenta certa. se hoje não faz sentido utilizar, pode ser que amanhã faça sentido.
Eu programo a uns 2 anos, confesso que parei de ler o livro kkkk mas o pouco li me ensinou bastante e me fez repensar algumas coisas, e apesar de ser antigo ainda dá pra extrair bastante coisa boa dele.
3:50 A Vanessa e Gabriel conversando ai eles cortam a cena, isso faz com q ela do nada mande uma risada rsrs. Tive q voltar pra ver a causa do sorriso e vi q teve um corte kk
Muitos alunos e ex-alunos meus relataram que não conseguiram entender o livro. Por isso escrevi um livro que é voltado para iniciantes em programação, com exemplos de código mais simples e em Java e Python. É o livro Deixe seu código limpo e brilhante - Desmistificando Clean Code com Java e Python. Publicado pela Casa do Código.
Eu acho que ele não deveria ter lido o livro nas férias, acabou não gostando do livro e foi correndo pro twitter reclamar, toda a leitura e assim, umas são boas e outras não, ruins, eu tenho meu clean code más vou ler só quando estiver mais avançado na programação. Parabéns pelo canal vcs são ótimos..
minha opinião sobre testes unitários desenvolver 1 vez é um valor desenvolver com testes é 2x o valor mas empresa que tem má gerenciamento de itens de backlog, fazendo a gente refazer as regras de negocio, então praticamente a gente refaz os itens 2x, ficando então 4x mais o valor total.... se a gente for desenvolver com teste unitário, o cliente tem que saber que terá sim qualidade, mas o preço pode ser 4x maior e o tempo 4x mais demorado, levando em consideração que a cada modificação nas regras, demora o dobro pra ser redesenvolvido !!
Onde eu trabalho e aonde eu trabalhei anteriormente, eu vi/vejo os caras reescrevendo um módulo inteiro para fazer modificações que eram simples. Porque? Código muito acoplado os verdadeiros canivetes suíço, faziam tudo dentro dele. Se o clean code fosse aplicado nesses softwares eles levariam 10% do tempo para modificar. E detalhe, todos com 90 ou mais de cobertura de teste. Testes é para você ter segurança em refatorar o código e clean code é para ter produtividade e facilidade na refatoração.
16:20 bom, já discordo disso Quando comecei a programar (programo em JS com o superset TS), as minhas variáveis eram tipo: a, client1, client2 Eu nem comentava nada, literalmente um código porco e extremamente mal feito. Mas assim que comecei a ler clean code, no mesmo momento comecei a renomear minhas funções e variáveis para coisas mais decentes, e não foi difícil me adaptar, na verdade isso mudou drasticamente a minha produtividade. Praticamente, quase nunca usei comentários, apenas JSDoc quando precisava tipar algo, mas 95% das vezes eu usei TypeScript
Como tudo na programação...depende. Nesse caso, dependendo do estágio de programação em que você se encontre, alguns princípios do clean code podem ser mais ou menos necessários.
Gabriel, crítica construtiva: tenta olhar mais para a câmera quando estiver falando, vc fica olhando demais pro lado e fica um pouco estranho. Excelente canal!
Li o clean code a um ano atrás acho um bom livro com bons princípios, o unico ponto "negativo" não é o livro mas sim a fanbase: nenhum livro pode ser tratado como verdade absoluta, como o proprio livro e esse video ressaltam. O certo é procurar também outros livros na mesma linha: Boas práticas! E fica a recomendação e lembrete: o livro e de 2008 e dá exemplos em Java, busque outros livros e boas praticas sobre a sua linguagem e frameworks também!
Ainda não li, porém já li vários artigos e assisti alguns vídeos sobre a filosofia do clean code, pra mim faz total sentido essa abordagem visto que, mesmo no início nunca gostei de ficar comentando código, sempre tive a visão de que se deveria entender o que o código está fazendo sem a necessidade de comentários, se é necessário colocar comentário então, primeiro você que está escrevendo o código não sabe o que está sendo feito, ou as várias e nomenclatura utilizadas não faz sentido nenhum dentro do contexto.
O meu chegou hoje, queria ter ele na minha coleção, como estou iniciando no aprendizado vou pegar leve, pois acho que será melhor ter um conhecimento mais amplo para tirar mais proveito do livro, mesmo assim vou ler e se não entender algo, por não saber algo em específico, tranquilo, futuramente leio novamente ... de boa!
Por favor! Destrinchem as regras! Daria uma bela playlist para o canal, e garanto que muito mais views! Eu mesmo, certamente maratonaria a playlist várias vezes!
Ótimo vídeo. Gostaria que vcs destrinchasse sim o livro e mandar pra vídeo ate pq ate hoje não o li e to precisando muito dele. Hahahaha Lerei, mas um vídeo me ajudaria muito ate poder comprar o livro.
Sou DEV junior, utilizo o LARAVEL e uma delícia os testes deles. No início tive dificuldade de entender como iria entregar um código limpo com pouco conhecimento de teste e refatoração. Hoje sou o maníaco só código limpo. Mas de verdade, convenhamos a entrega de valor quebra realmente esse tempo necessário pra criação de um bom código. Mas hoje eu sigo dogmas como os citados no vídeo.
Sobre os testes, tem um outro ponto mais marcante, onde o Uncle Bob fala lá na frente mais ou menos que ele poder estar mudando o código, e como ele sabe que o novo código funciona? Porque passou nos testes.
Ainda estou lendo o livro. Mas até o momento acho que muitas coisas são fundamentais de se colocar, principalmente a do nome, mas realmente Clean Code não é para quem está aprendendo programação ainda, mas se entrou em um projeto em uma empresa, aí sim já recomendo dá uma lida, entender cada capítulo do livro e vê se aplica no seu projeto. Mas para mim esse leite está longe de envelhecer, está mais na verdade como um vinho. Nem todos vão gostar, mas pode fazer muito bem para a saúde (do projeto pelo menos 😂).
Sobre os comentários dentro do código o problema maior nem é misturar documentação com o código, mas sim precisar dos comentários pra explicar o que o código faz. "Código limpo deve ser lido como uma 'proza'", ou seja, se seu código for bem feito deve ser auto explicativo.
Olha, estou lendo e me tem sido muito proveitoso. Tirando que o próprio livro sugere ler com olhar crítico sobre o conteúdo, e não dogmático/definitivo. Então Daniel parece ter feito o dever de casa ao levantar suas críticas, o resto fica pelo hype da polêmica hehehe
Eu fui ler esse livro no início do meu aprendizado porque ninguém tinha me dado esse toque... Mas agora já é tarde... Tudo é comentado no meu código...kkkk
O trabalho do programador é saber dosar o que ele precisa aplicar agora e oque ele pode ficar em débito técnico. O livro serve muito bem como um direcionamento de como fazer um código próximo do perfeito, mas no dia a dia você precisa dosar o "quanto perfeito" você consegue escrever o código. O importante é saber o que deixar fácil para uma manutenção futura e o que você pode abrir mão naquele momento e, é fato, não é um livro para iniciante, mas é bom o iniciante saber que tem um jeito melhor de escrever o que ele tá escrevendo e, no fim, o cara que diz coisas como esse da crítica é o cara que muitas vezes tem mesmo é preguiça... tenho até medo de pegar o código de um cara desses pra dar manutenção.
É interessante esse ponto e concordo. E o entendimento e aplicação de conceitos como TDD e Clean Architecture pordem ajudar bastante nesse ponto. TDD pode ajudar a escrevermos menos código de produção e mais simples, mas mais fáceis de serem abstraídos quando necessário enquanto Clean Architecture pode nos ajudar a criar software menos dependente (diretamente) de frameworks e tecnologias específicas.
@@arthurreis263 as vezes é a solução mesmo. Em muitos processos seletivos o desafio técnico tende a ir para esse lado, como o caso do processo seletivo para backend do NuBank, por exemplo. Um problema que eu vejo de muita gente que ensina é querer partir para projetos reais/complexos (que para eles é simples) o que acaba confundindo quem não tem aquela experiência. Outro problema é querer ensinar/aprender ferramentas antes de ensinar/aprender fundamentos.
você pode usar as técnicas de TDD e refatoração e mesmo assim ainda ter nome de variaveis não descritivas, métodos com nomes ruins e números mágicos por toda parte... esse pensamento de "ah o livro clean code não é mais válido porque já uso TDD e refatoração" não faz sentido, utilizar essas técnicas não faz com que seu código fique limpo automaticamente, para mim clean code segue válido e recomendo para todos!
Ele pode estar falando do livro Clean Coder. Nesse ele fala que não é profissional. Tem uma discussao dele sobre isso também online mto boa, só procurar. É obvio que ele está sendo provocativo.
TDD e Clean Code, assim como qualquer técnica ou processo, só são efetivamente usados quando passam a "fazer sentido" para o desenvolvedor, ou seja, quando ele percebe que há alguma utilidade, justificativa e, principalmente, facilidade de incorporar em seu cotidiano. E acredito que a técnica em si - organizar e validar código - seja atemporal e bem-vista para qualquer linguagem. Talvez ele tenha criticado a forma "dogmática" com que esses conceitos foram apresentados ao longo dos últimos anos - tanto é que o próprio Dan North, Martin Fowler, Uncle Bob, etc... até hoje têm que explicar e re-explicar suas descobertas e propostas ...
![MV วิถีชีวิตใต้ - ผา อัยย๊ะ [Official MV HD]](http://i.ytimg.com/vi/nODlkOUu9B0/mqdefault.jpg)
Eu acho que a afirmação do "código limpo ser código testável" poderia ser modificada para: "código limpo é código com boa testabilidade". Um código cheio de dependências e responsabilidades é muito mais difícil de testar (não é impossível) do que um código mais coeso e menos acoplado, que é o código limpo. Então temos a testabilidade como um indicador preciso para avaliar um bom design de código.
Concordo em parte. Testabilidade, no caso falando de testes automatizados, são parâmetro de qualidade absoluto somente pra cagadores de regras, com o perdão da palavra. Tem que se analisar a arquitetura do sistema e ver qual é o melhor caminho para se ter um código seguro e limpo. Já vi muitas empresas com código cheio de over engineering, testes em tudo quanto é canto, mas que era mexer 5 minutos pra ver uns bugs escrotíssimos acontecendo. Resumindo: fazer 40 testes p validar um campo de cpf não deixa seu sistema digno de um premio nobel. Tem que saber pesar a mão e fazer um código que funciona, e se determinada regra do clean code estiver deixando seu código complexo demais de maneira ruim, melhor pensar duas vezes antes de segui-la.
@@emanuelmartins9508, é aí que entra a experiência profissional da pessoa para "formar uma opinião". Eu trabalho há mais de 10 anos com TI e os códigos mais fáceis de testar que eu encontrei eram sempre os mais bem escritos. É claro, a sua experiência pode ter sido outra, e nela você pode ter encontrado exceções à regra. Mas assim como o Uncle Bob, sempre notei essa relação entre um bom design de código e sua testabilidade. Não é cuspir regras pela regra em si, é criá-las ou seguí-las baseado na sua vivência profissional.
Perfeitamente colocado. Depois que comecei a escrever testes, meu código ficou muito mais organizado e desacoplado. No começo sofri bastante para testar codigos antigos e acabei entendendo na pele kk.
Coincidência achar minha instrutora da Udemy aqui. Kkkkkk
@@jhonatanteixeirarios710 Estou vivenciando isso agora kkk
Como é dito no início do livro, ele é uma escola de pensamento, não um conjunto de regras escritas em pedra.
Seria muito legal uma playlist com todas as regras!
Quem gostou da ideia dá um like pra que o Gabriel e a Vanessa passam ver e fazer a playlist!
Up.
Up
Up.
concordo
+1
Estou no mercado tem mais de 14 anos e falo que antes e depois de pegar código de pessoas que entendem o propósito do clean code tem muita diferença. Não são regras mas são ideias muito fáceis de aplicar. Faço questão que minha equipe tenha ideia disso porque dar manutenção é muito mais fácil.
Só teste não faz isso, falo por experiência. Testes são essenciais
Ótimo vídeo casal 😄
Existe uma diferença muito grande entre teste e teste automatizado. Obvio q sem teste n se faz nada. Agora, vc quis dizer teste automatizado?
@@LeonardoLuzx tmbm fiquei na duvida. E tmbm ele não deixa claro quais são as "regras do clean code" que ele impõe a equipe dele e que "facilita o trabalho".
@@LeonardoLuzx rapaz! Teste em geral é importante. Onde estou temos por parte de dev os unitários, integração e funcional. A equipe que entrou agora valoriza o código limpo, as clases ficaram menores, menos acopladas, nomes fáceis de entender, contexto bem separado e bem modular.
Com os testes unitários e funcional que sempre peço pra eles terem bom senso porque a cada refactoring se detecta possíveis diferenças de comportamento. Com isso pude fazer refactorings grandes.
Tem uma equipe de QA que linda com negócio e suas automações. Eu não me preocupo. Com as regressões ok, o código a produção sempre chega redondo. Com isso a gente raramente tem bug e a equipe sempre esta trabalhando em features e não bugfix. Hotfix em 2 anos tivemos 1 porque business queria pra ontem.
Achando ruim ou não, de acordo ou não, pelo menos tenho estabilidade.
@@emanuelmartins9508 quando vc puder ler o livro e passar por diversos problemas, pode fazer algum sentido.
Mas o uso é opcional =)
Só sugiro a quem se interessar.
Acho lindo este conceito de desenvolver um código tão claro, que fica até redundante se colocar comentários, mas quando estou aprendendo uma nova linguagem, os comentários ajudam muito a reforçar a compreensão.
Mas isso é um contexto diferente.
Os comentários no código, citados no livro, é que o seu método deve ser construído de forma que você não necessite de um comentário para entender a lógica dentro dele.
Isso é diferente de comentar para entender como a linguagem funciona. Isso entra na regra de algo especifico e que entra como algo que deve ser comentado.
O autor do livro constrói os argumentos e conceitos com exemplos e lógica, faz a gente pensar e refletir em cada caso. Não me lembro dele chegar e falar "É assim e pronto".
Mais ou menos na metade do livro, ele quebra algumas regras anteriores, pois em tais situações é melhor de uma forma X ou Y. Ou seja, ele nos ensina também a pensarmos além do que está no livro. Nos ensina a pensar nas próximas pessoas que irão olhar nosso código ou você mesmo depois de um tempo.
Me ajudou demais e mudou minha forma de codar. Li enquanto estava no estágio e fez total sentido para mim. De vez em quando volto para relembrar alguns detalhes 🙌
ele mesmo deixa claro no livro que o Clean Code é como uma arte marcial: cada um escolhe qual arte marcial quer seguir, mas cada arte marcial terá suas regras, vantagens e desvantagens, às vezes, lutar karatê numa luta de queda pode não ser a melhor escolha.
O problema mesmo é a rapazeada só conhecer Clean Code.
Livros técnicos e totalmente voltados a uma tecnologia ou um problema específico tendem a envelhecer azedando.
Concordo com o amigo de cima, Mateus Gomes, o livro em questão ajuda a abrir a cabeça, traz reflexão para nos melhorarmos, não estabelece as coisas como escritas em pedra, como se fossem leis.
Acho legal livros do tipo, conceituais, um ponto de referência, que pode ser adaptável à tecnologia a ser usada e atualizado às tendências de cada época, ou mesmo de um projeto específico (até porque sabemos que, apesar de ideal, não é sempre que conseguimos seguir a cartilha de testes 100%).
Eu era um dos "infelizes" desenvolvedores que teve que usar EJB 2 e para mim faz todo sentido o que o Uncle Bob diz no capítulo 11 do livro sobre os problemas do EJB, que era algo comum na época de lançamento do livro (2008). Mas acredito que a geração atual que não sofreu com esse código enterprise do passado talvez precise de uma 2ª edição, ensinando os mesmos princípios mas utilizando exemplos de erros em tecnologias mais recentes.
Um vídeo para cada regra do Clean Code seria incrível. Parabéns pelo canal que mantém todos nós atualizados, pois cada dia é mais difícil ter tempo para destrinchar um livro.
Excelente video, penso da mesma forma. Clean code não é para quem está aprendendo e sim para quem já tem experiencia e tambem vivencia de mercado.
Clean Code e Clean Arquiteture não é um livro de regras e sim um livro para se extrair as melhores experiencias, e entender como se utilizar no dia a dia.
Parábens pelo conteudo.
Exatamente Ewerton, resumiu bem.
Como tudo na vida, a gente retêm o que faz sentido pra gente e ignora o restante. Esse livro possui muito conhecimento relevante, mas nem todo muito vai ter a necessidade, ou a oportunidade, de implementar tudo que ele oferece.
Eu discordo em partes do ponto de não ser para iniciantes, eu li quando era estágiário e mudou muito a forma como pensava em software, algumas das dores você só vai sentir com a experiência, re-li o mesmo alguns anos depois e tive uma visão bem mais ampla do que a primeira leitura, mas ambas se complementaram, ler sendo iniciante é uma boa na minha visão, mesmo que você não absorva tudo, só não deve ser tomado como um conjunto de regras imutáveis.
Esse livro, na real, mudou minha vida como programador.
Também sou fã de CleanCode, e digo mais... É extramamente necessário conhecer esses conceitos contidos no livro depois de já se ter uma certa xp em desenvolvimento.
Definitivamente Clean Code não é um livro para quem está aprendendo a programar, eu li ele quando estava começando, e mais bagunçou do que ajudou meu aprendizado. Recentemente eu fui reler e parecia que eu estava lendo outro livro. A percepção que eu tive foi muito diferente. Atualmente meu livro está todo riscado, cheio de anotações, pra mim ele se tornou essencial.
boa, estava me perguntando se é uma boa opção começar a ler ele... Porem estou começando agora na programação. Vou esperar ficar mais experiente..
@@kamilakksrseu também, ouvi falar do livro e vim ver um feedback, mas como sou iniciante vou deixar passar por hora
@@kamilakksrs A hora certa de pegar esse livro é quando você pegar um código de alguém pra revisar ou fazer a migração de um sistema e sentir vontade de xingar as 7 gerações da família do autor ksksk
Eu uso vários dos conceitos abordados no Clean Code no meu dia a dia de trabalho, e sempre evita possíveis refatorações posteriormente. Clean Code e Clean Architecture, em minha opinião, são livros de cabeceira e só o tempo pode mudar minha opinião! hehehe
Li o livro em pequenas doses e posso dizer que me ajudou demais a melhorar a qualidade do meu código. Tanto os conceitos de código limpo quanto os de arquitetura limpa são muito importantes e nos ajudam sim a fazer códigos melhores e com mais qualidade. A questão da testabilidade é outro ponto crucial pois muitos princípios são empregados para garantir isso, desde DRY, KISS, YAGNI até SOLID. Usando por exemplo injeção de dependências conseguimos criar mocks bem mais facilmente do que declarar tudo dentro da própria classe ou função.
Seria legal um video sobre cada regra... Os videos tem me ajudado muito. Obrigado!
Você chegou a assistir nosso Dicionário do Programador sobre Clean Code?
th-cam.com/video/ln6t3uyTveQ/w-d-xo.html
De qualquer forma cada regra citada no livro vale uma reflexão em vídeo também. Grande abraço!
Eu apliquei os principios do clean arch, clean coding, solid, ddd e etc e posso afirmar fez uma diferença enorme. Criei um projeto inicial em 6 meses e com menos de 2 meses criei outro reaproveitando as abstracoes que desenvolvi no primeiro.
👏👏👏👏👏
eu li clean code quando era estagiario, mudou demais minha forma de pensar em software
Na minha humilde opinião, eu acho que o livro do Clean Code ainda é relevante mesmo após tantos anos de seu lançamento.
Lógico, podem existir alguns pontos que já foram superados pela evolução das linguagens de programação, mas eu acho que a mensagem do que é importante ainda vai estar lá no livro.
Diferente dos apresentadores, eu acho que mesmo os iniciantes deveriam ler o livro! Se por algum motivo algo não fizer sentido num primeiro momento, leia novamente até entender.
Nos meus cerca de 13 anos de desenvolvimento, os melhores códigos que vi foram de pessoas que tinham o Clean Code como uma espécie de bíblia da salvação.
Por outro lado, os piores códigos foram de pessoas que sequer sabiam da existência do livro.
Muito bom o vídeo. Posso acrescentar que estou lendo o Código Limpo, e até agora estou gostando e percebendo que está trazendo boas práticas no meu codificar, confesso também que algumas partes são muito avançadas para mim como o capítulo sobre sistemas. Acrescento ainda que o livro responde umas perguntas mas gera outras em contra-partida, por isso considero um livro introdutório sobre boas práticas de programação, e também que deve ser lindo mais de uma vez. Uma coisa que deixa a gente a ver navios as vezes é que os autores abordam termos que não são suficientemente explicados no Livro como a Lei de Demeter e o Princípio do Aberto Fechado. Por outro lado, esperar que apenas um livro ilumine todo o caminho de um assunto tão complexo como desenvolvimento de software é muita exigência.
Muito bom!
Eu li o livro já com muita caminhada na carreira. Muita coisa eu já fazia pela própria experiência, na verdade pouca coisa eu pude aproveitar. Mas no geral foi uma boa leitura sim.
Sim, li quando junior, depois como pleno, concordo que ele é uma filosofia, algo a ser buscado.
A primeira coisa que me chamou atenção nesse livro foi logo no começo o Tio Bob falar de Lean , sou certificado GreenBelt e trabalhei muitos anos com melhoria de processos, e isso aplicado a programação muda sua atitude.
Fala sobre cada ponto do CC.
Muito obrigado por mais esse excelente conteúdo.
Vocês são o "safe guard" no oceano de dúvidas para quem está inciando.
Conclusão do vídeo foi espetacular. O importante é você saber aplicar no seu contexto, nenhuma técnica de programação é bala de prata.
Vejo o Clean Code como alguns "guidelines", ou seja, uma referência de boas práticas na qual eu pauto meu trabalho, e não necessariamente como um livro de regras onde se eu não seguir qualquer uma delas eu serei um péssimo profissional. Ao ver a motivação desse vídeo, os comentários do rapaz sobre o trabalho do Uncle Bob, muito ficou para mim sobre essa idéia que alguns jovens profissionais tem de que é necessário tentar questionar ou destruir algo que é estabelecido (e que certamente tem uma forte razão para ser tão popular).
Oras, o Uncle Bob esta nesse mercado muito antes da maioria de nós termos inclusive nascido, ele viu a ascensão e a maturação de muitas das tecnologias que tomamos hoje como certas. Porque se posicionar de maneira tão arrogante quanto ao trabalho dele? No mínimo devemos um grande respeito a esse que certamente é um bastião de nossa área. Dito isso, acho que o Clean Code envelheceu muito bem, e é um livro importante na formação de profissionais da nossa área. Mas concordo com a opinião do Gabriel de que não é um livro para se ler logo no início da carreira.
Concordo plenamente, só porque um código não tem testes não quer dizer que ele é ruim ou não profissional. O que realmente importa é o contexto em que isso é usado, e se é possível também aplicar e a qualidade dos testes como mencionado. Quando comecei a programar também nem sequer sabia que isso existia, e de certa forma, escrevia códigos com o SOLID (do meu jeito), mas quando li sobre, meus códigos melhoraram MUITO, MAS MUITO MESMO!
Código eficiente é aquele que entrega o melhor resultado com o mínimo de esforço, tanto no desenvolvimento quanto na manutenção. Tem códigos que de tão simples, se forem colocados em testes automatizados terão sua complexidade aumentada prejudicando a performance e a manutenabilidade. E por outro lado existem códigos que precisam de testes porque não podem ser desacoplados.
No fim, não adianta saber “o que/como fazer” se você não souber QUANDO usar cada forma de fazer.
Cliquei pelo título, estou abalado kkk vejamos o vídeo
Já trabalho com programação desde a década de 1980 (RPG II, RPG III e RPG IV, linguagem proprietária da IBM para sistema S36, S38 e AS/400) quando nem se falava ainda de OOP e uma das instruções que mais detestava e por isso NUNCA usava, era o famigerado GO TO, que eu costumava dizer que me provocava dor de pescoço de tanto andar subindo e descendo linhas para ler o código (sempre que tinha que trabalhar com código de alguém com essa instrução, sentia a necessidade de refatorar, para conseguir entender, como se tivesse TOC), por isso, sem saber já usava "Clean Code", pois acabava criando tantas procedure (na verdade se chamava ainda Sub-rotinas), quanto as necessária para evitar repetir código e criar blocos que código quilométricos.
Famoso código espaguete. A solução é SRP (princípio da responsabilidade única) e Use Vertical Formatting (os códigos devem ser lidos de cima para baixo).
Seria muito bom um vídeo destrinchando cada tópico do Clean Code 🙌
Discussão muito rica! Parabéns pessoal. Discutir esses assuntos é muito necessário, pois dessas discussões que surgem as ideias novas.
Clean Code é ótimo.. Os conceitos apresentados no livro podem ser aplicados em inúmeras linguagens de programação. O conceito base não muda, claro que cada framework terá suas boas práticas, mas conceitos de código limpo devem ser seguidos sempre
Gosto muito do Clean Code e do Clean Architecture e acho eles importantíssimos de se ler quando já se tem média experiência (não recomendaria pra quem ta começando), porém um que acho obrigatório (na minha opinião) é o The Clean Coder. Eu acho esse livro simplesmente incrível e me ajudou nos piores momentos da minha carreira e ajuda até hoje.
Uncle Bob fez um masterclass que é tipo um resumo dos livros dele e ainda fala e repete muita coisa que fala em outras entrevistas que ele dá, fiz uma playlist e recomendo sempre:
th-cam.com/play/PLo61EKto8ZPHUOld83z0pwpzdlioliu6j.html
Acho que foi os livros Clean Code e Clean Coder que me ligaram "o switch" de fazer da programação minha profissão.
Eu já programava faz tempo, mas era só "fazedor de código", mas esses livros me abriram os olhos de ser profissional com o código.
E acho que poderia ter algumas entradas do dicionário do programador falando daqueles livros de programação clássicos, incluindo o Clean Code!
De uns meses para cá, começou-se a questionar o Uncle Bob mais constante e incisivamente; infelizmente, o motivo é POLÍTICO.
Querem "cancelar" o Uncle Bob e sua obra por motivos que nada têm a ver com programação...
Às vezes, fazem críticas mais abertamente; às vezes, criticam a obra "de maneira imparcial" para atingi-lo, com foi o caso.
Devo muito ao Uncle Bob e aqui é fechamento total com o véio! 👊 #TeamUncleBob
Show de instruções.
Quando posso sempre assisto vocês.
clean code é atemporal, melhor livro sobre software
O titulo é chamativo, nem vi o vídeo ainda, mas eu sou favorável ao Clean Code, melhorou muito meu código depois desse livro.
Tive que parar tudo para ouvir esse assunto que tanto me interessa.
Olha...vcs conseguem pegar algo, de certa forma, complexo de entender em um primeiro momento e transformar isso totalmente compreensível e interessante. Nem precisa acelerar o vídeo, pq nem se percebe o tempo passar absorvendo o conhecimento e vivência q vcs nos passam aqui. Obrigado!
Muito bom o vídeo !! E a cereja do bolo no final a ponderação.
Destrinchar um a um seria uma grande "LEGADO" do código fonte no bom sentido, pois ajudaria a profissionalizar milhares de programadores por longa data, e com a qualidade da explicação de vcs seria algo único no TH-cam.
O livro de fato apresenta ideias que para um iniciante não faz sentido; mas algumas são extremamente importante para uma pessoa que inicia na programação, como por exemplo nomes de classes, métodos e etc. Em relação aos comentários, nada melhor que o código como "comentário". Sim para um desenvolvedor aspirante é importante comentar para entender didaticamente o que está acontecendo, mas para um profissional com vivência na área, o código é o comentário. Por fim, o clean code foi um livro que mudou minha forma de programar, transformando- me em um desenvolvedor de qualidade. Recomendo sempre ele para todas as pessoas que desejam aprender as boas práticas de programação.
Minha Lista de livros:
Java efetivo(serve pra Go também) - Bloch
Refatoração - Fowler
UML e Padrões - Larman
Na saga de alcançar o clean code eu cheguei no Haskell, recomendo, fica difícil querer voltar a usar outras linguagens de novo. É como se tudo que o livro fala estivesse nativo na linguagem, ela te faz escrever código limpo sem pensar muito.
Pra mim, foi mais um carinha daqueles que apenas critica baseado na bolhinha dele. O livro faz um ótimo serviço ao puxar esses tópicos bastante importantes. É tipo uma pílula de conhecimento que você pode receitar para alguém que esteja já buscando um pouco mais de técnica e melhoria, depois de superadas as barreiras iniciais.
Comecei a ler recentemente o Clean Code e ta fazendo super sentido até agora.
O momento que estou lendo esse livro, em um momento iniciante ainda estou estudando lógica da programação estudando algoritmos!
Com certeza não é o melhor momento para essa leitura mais a conclusão que tiro nesse momento que será bom para que eu possa ter uma ótima base para poder começar escrever meus códigos! Forte abraço muito obrigado pelo vídeo.
por favor faz o vídeo separado de cada regra do clean code !!
sensacional , final da historia o melhor código é conforme sua experiência.
Excelente gente!! 💝 mais vídeos sobre os livros desse autor 😅 gratidão 🙏
Amo todos os livros que mostraram, eu n li todos ainda. Mas acredito que o maior ensinamento seria como programar para outras pessoas
Acho que seria legal falarem sobre o cracking the coding interview. Recebi essa indicação de um engenheiro de software em uma palestra sobre o processo seletivo para a google e já adicionei na minha lista de leitura.
Isso não é um livro de ficção que você para um final de semana e lê, é um livro que se lê aos poucos, tem que ser digerir cada capítulo, fora a ênfase em SRP que é fantástica.
Eu só não comprei esse livro pois tem muitas reclamações sobre a tradução dele que acaba mais confundindo que ajudando.
Verdade, eu comprei o livro e devolvi, muito mal traduzido hahahaha!
Sim, a tradução é fraca e mtas vezes acaba atrapalhando na interpretação do texto.
Mas o livro é bom 😁
@@ramirorccastro Me ajudou muito sim, mas realmente algumas traduções do livro mais atrapalham do que ajudam haha, fora isso é ótimo para o nosso conhecimento!
Sem dúvida, que a tradução não é das melhores. De qualquer forma o livro é ótimo.
Compra em inglês ue
Sobre o primeiro ponto concordo com o Twitter, acredito que ele está falando sobre testes automatizados, e no mundo real testes são caros, tenho projetos que rodam a anos sem manutenção e ter feito testes pra eles iria impossibilitar o projeto por questões de tempo e/ou custos, acho esses autores muito bons, mas parece que não estão no mesmo mundo real que a gente, alguns detalhes muito teóricos que não vejo se aplicar no dia a dia, ótimo video
Código testável evita muita dor de cabeça futuramente e dá mais qualidade ao código. Penso que a refatoração é algo mais custoso em relação a prazos.
show, eu to lendo O Codificador Limpo dele e to aprendendo bastante coisa, vale a pena a leitura para qualquer senioridade...
Queremos vídeos para cada dica do Clean Code....
Uma serie de videos seria maravilhoso
O que o pessoal tem que entender com o livro assim como todos os livros é que não precisam necessariamente levar tudo que está ali como verdade absoluta. Um dos melhores exemplos é o uso de I em interfaces como IService, que o Uncle Bob abomina tanto mas em varias linguagem é um padrão definido, não leia cegamente e trate o Tio Bob como um deus da programação e conhecedor de toda a verdade
Clean Code não é um conjunto de regras, mas sim de boas práticas.
Enxergo da seguinte maneira: desenvolvedores são a caixa de ferramentas. Esses conceitos são as ferramentas em si.
é importante irmos conhecendo novas técnicas, comportamentos, possibilidades, para que no momento certo, utilizemos a ferramenta certa. se hoje não faz sentido utilizar, pode ser que amanhã faça sentido.
Eu programo a uns 2 anos, confesso que parei de ler o livro kkkk mas o pouco li me ensinou bastante e me fez repensar algumas coisas, e apesar de ser antigo ainda dá pra extrair bastante coisa boa dele.
3:50 A Vanessa e Gabriel conversando ai eles cortam a cena, isso faz com q ela do nada mande uma risada rsrs. Tive q voltar pra ver a causa do sorriso e vi q teve um corte kk
Adorei o conhecimento desse vídeo.
Muitos alunos e ex-alunos meus relataram que não conseguiram entender o livro.
Por isso escrevi um livro que é voltado para iniciantes em programação, com exemplos de código mais simples e em Java e Python.
É o livro Deixe seu código limpo e brilhante - Desmistificando Clean Code com Java e Python.
Publicado pela Casa do Código.
Eu acho que ele não deveria ter lido o livro nas férias, acabou não gostando do livro e foi correndo pro twitter reclamar, toda a leitura e assim, umas são boas e outras não, ruins, eu tenho meu clean code más vou ler só quando estiver mais avançado na programação. Parabéns pelo canal vcs são ótimos..
Eu estou lendo arquitetura limpa e posteriormente quero ler código limpo.
Li código limpo e estou lendo arquitetura :)
minha opinião sobre testes unitários
desenvolver 1 vez é um valor
desenvolver com testes é 2x o valor
mas empresa que tem má gerenciamento de itens de backlog, fazendo a gente refazer as regras de negocio, então praticamente a gente refaz os itens 2x, ficando então 4x mais o valor total....
se a gente for desenvolver com teste unitário, o cliente tem que saber que terá sim qualidade, mas o preço pode ser 4x maior e o tempo 4x mais demorado, levando em consideração que a cada modificação nas regras, demora o dobro pra ser redesenvolvido !!
Sim, videos detalhando todas regras em separadas. Será muito bom!
Onde eu trabalho e aonde eu trabalhei anteriormente, eu vi/vejo os caras reescrevendo um módulo inteiro para fazer modificações que eram simples. Porque? Código muito acoplado os verdadeiros canivetes suíço, faziam tudo dentro dele. Se o clean code fosse aplicado nesses softwares eles levariam 10% do tempo para modificar. E detalhe, todos com 90 ou mais de cobertura de teste. Testes é para você ter segurança em refatorar o código e clean code é para ter produtividade e facilidade na refatoração.
16:20 bom, já discordo disso
Quando comecei a programar (programo em JS com o superset TS), as minhas variáveis eram tipo: a, client1, client2
Eu nem comentava nada, literalmente um código porco e extremamente mal feito.
Mas assim que comecei a ler clean code, no mesmo momento comecei a renomear minhas funções e variáveis para coisas mais decentes, e não foi difícil me adaptar, na verdade isso mudou drasticamente a minha produtividade.
Praticamente, quase nunca usei comentários, apenas JSDoc quando precisava tipar algo, mas 95% das vezes eu usei TypeScript
Como tudo na programação...depende.
Nesse caso, dependendo do estágio de programação em que você se encontre, alguns princípios do clean code podem ser mais ou menos necessários.
Gabriel, crítica construtiva: tenta olhar mais para a câmera quando estiver falando, vc fica olhando demais pro lado e fica um pouco estranho. Excelente canal!
Obrigado pelo feedback, já percebi isso é estou tentando melhorar.
Li o clean code a um ano atrás acho um bom livro com bons princípios, o unico ponto "negativo" não é o livro mas sim a fanbase: nenhum livro pode ser tratado como verdade absoluta, como o proprio livro e esse video ressaltam. O certo é procurar também outros livros na mesma linha: Boas práticas!
E fica a recomendação e lembrete: o livro e de 2008 e dá exemplos em Java, busque outros livros e boas praticas sobre a sua linguagem e frameworks também!
Ainda não li, porém já li vários artigos e assisti alguns vídeos sobre a filosofia do clean code, pra mim faz total sentido essa abordagem visto que, mesmo no início nunca gostei de ficar comentando código, sempre tive a visão de que se deveria entender o que o código está fazendo sem a necessidade de comentários, se é necessário colocar comentário então, primeiro você que está escrevendo o código não sabe o que está sendo feito, ou as várias e nomenclatura utilizadas não faz sentido nenhum dentro do contexto.
O meu chegou hoje, queria ter ele na minha coleção, como estou iniciando no aprendizado vou pegar leve, pois acho que será melhor ter um conhecimento mais amplo para tirar mais proveito do livro, mesmo assim vou ler e se não entender algo, por não saber algo em específico, tranquilo, futuramente leio novamente ... de boa!
Por favor! Destrinchem as regras! Daria uma bela playlist para o canal, e garanto que muito mais views! Eu mesmo, certamente maratonaria a playlist várias vezes!
14:36 Tragam os vídeos sim ☺️
comecei a ler ai nao estava entendendo alguns pontos e preferi avançar nos estudos antes para depois ler.
Ótimo vídeo. Gostaria que vcs destrinchasse sim o livro e mandar pra vídeo ate pq ate hoje não o li e to precisando muito dele. Hahahaha
Lerei, mas um vídeo me ajudaria muito ate poder comprar o livro.
Sobre destrinchar os vídeos, eu apoio
Sou DEV junior, utilizo o LARAVEL e uma delícia os testes deles. No início tive dificuldade de entender como iria entregar um código limpo com pouco conhecimento de teste e refatoração. Hoje sou o maníaco só código limpo. Mas de verdade, convenhamos a entrega de valor quebra realmente esse tempo necessário pra criação de um bom código. Mas hoje eu sigo dogmas como os citados no vídeo.
Esse tema é muito polêmico, sempre haverá discussão
Sobre os testes, tem um outro ponto mais marcante, onde o Uncle Bob fala lá na frente mais ou menos que ele poder estar mudando o código, e como ele sabe que o novo código funciona? Porque passou nos testes.
Isso é muito particular, gosto não se discute. Muitos estão gostando.
Ainda estou lendo o livro. Mas até o momento acho que muitas coisas são fundamentais de se colocar, principalmente a do nome, mas realmente Clean Code não é para quem está aprendendo programação ainda, mas se entrou em um projeto em uma empresa, aí sim já recomendo dá uma lida, entender cada capítulo do livro e vê se aplica no seu projeto. Mas para mim esse leite está longe de envelhecer, está mais na verdade como um vinho. Nem todos vão gostar, mas pode fazer muito bem para a saúde (do projeto pelo menos 😂).
Sobre os comentários dentro do código o problema maior nem é misturar documentação com o código, mas sim precisar dos comentários pra explicar o que o código faz.
"Código limpo deve ser lido como uma 'proza'", ou seja, se seu código for bem feito deve ser auto explicativo.
Olha, estou lendo e me tem sido muito proveitoso. Tirando que o próprio livro sugere ler com olhar crítico sobre o conteúdo, e não dogmático/definitivo. Então Daniel parece ter feito o dever de casa ao levantar suas críticas, o resto fica pelo hype da polêmica hehehe
Eu fui ler esse livro no início do meu aprendizado porque ninguém tinha me dado esse toque...
Mas agora já é tarde...
Tudo é comentado no meu código...kkkk
O trabalho do programador é saber dosar o que ele precisa aplicar agora e oque ele pode ficar em débito técnico. O livro serve muito bem como um direcionamento de como fazer um código próximo do perfeito, mas no dia a dia você precisa dosar o "quanto perfeito" você consegue escrever o código. O importante é saber o que deixar fácil para uma manutenção futura e o que você pode abrir mão naquele momento e, é fato, não é um livro para iniciante, mas é bom o iniciante saber que tem um jeito melhor de escrever o que ele tá escrevendo e, no fim, o cara que diz coisas como esse da crítica é o cara que muitas vezes tem mesmo é preguiça... tenho até medo de pegar o código de um cara desses pra dar manutenção.
O que vocês acharam da tradução dessa edição? Vejo bastante comentários falando q é péssima.
Dá pra fazer um código sujo que seja testável também, então não acho certo dizer que é limpo se é testável.
Seria bacana vê-los destrinchar o clean code.
A nossa produtividade ta baixando devido ao excesso de abstrações e excesso de configurações que as tecnologias exigem. Jhonatan blow fala mto disso
É interessante esse ponto e concordo. E o entendimento e aplicação de conceitos como TDD e Clean Architecture pordem ajudar bastante nesse ponto. TDD pode ajudar a escrevermos menos código de produção e mais simples, mas mais fáceis de serem abstraídos quando necessário enquanto Clean Architecture pode nos ajudar a criar software menos dependente (diretamente) de frameworks e tecnologias específicas.
@@arthurreis263 as vezes é a solução mesmo. Em muitos processos seletivos o desafio técnico tende a ir para esse lado, como o caso do processo seletivo para backend do NuBank, por exemplo. Um problema que eu vejo de muita gente que ensina é querer partir para projetos reais/complexos (que para eles é simples) o que acaba confundindo quem não tem aquela experiência. Outro problema é querer ensinar/aprender ferramentas antes de ensinar/aprender fundamentos.
você pode usar as técnicas de TDD e refatoração e mesmo assim ainda ter nome de variaveis não descritivas, métodos com nomes ruins e números mágicos por toda parte... esse pensamento de "ah o livro clean code não é mais válido porque já uso TDD e refatoração" não faz sentido, utilizar essas técnicas não faz com que seu código fique limpo automaticamente, para mim clean code segue válido e recomendo para todos!
Estou a ficar viciado em café ☕
E ao vosso canal 👍
Ele pode estar falando do livro Clean Coder. Nesse ele fala que não é profissional. Tem uma discussao dele sobre isso também online mto boa, só procurar. É obvio que ele está sendo provocativo.
TDD e Clean Code, assim como qualquer técnica ou processo, só são efetivamente usados quando passam a "fazer sentido" para o desenvolvedor, ou seja, quando ele percebe que há alguma utilidade, justificativa e, principalmente, facilidade de incorporar em seu cotidiano. E acredito que a técnica em si - organizar e validar código - seja atemporal e bem-vista para qualquer linguagem. Talvez ele tenha criticado a forma "dogmática" com que esses conceitos foram apresentados ao longo dos últimos anos - tanto é que o próprio Dan North, Martin Fowler, Uncle Bob, etc... até hoje têm que explicar e re-explicar suas descobertas e propostas ...
Ego de twitter isso sim, como alquem fala mal do clean code ? é a mesma coisa de falar que ficou obsoleto quem arruma a cama... não faz sentido.