Suas Funções Nunca Mais Serão as Mesmas Depois desse Vídeo // Clean Code (Capítulo 3)

[@brunojunqueira737]

Por favor, falem sobre o Abstract Factory bem detalhado! :) :) :)

[@geandre83]

O que acho massa disso tudo é a oportunidade de um Dev de uma cidade pequena do Matogrosso do Sul, ter acesso esse tipo de conteudo. Parabéns por essa play list! Muito bom aprender com vcs

[@vtVilao]

Q cidade?

[@geandre83]

@@vtVilao de Cassilândia - MS

[@brunojunqueira737]

Obrigado por esses vídeos sobre os livros técnicos da área de TI. Graças à vocês, estou montando uma biblioteca aqui em casa com os principais títulos!

[@CleitonMaciell]

Lendo capítulo 4, esperando o próximo vídeo! Abraço!

[@SuelenMMariano]

Aqui da Austria pagando faculdade e aprendendo de verdade no seu canal!. Obrigada! Pretendo junto ao meu esposo assinar o Alura!. Conheci seu canal atravez de uma grande amiga que é programadora pleno!. Parabens pra vcs! Amo o canal!. Amo o ensinamento que vcs trazem!. Obrigada!!!!! 👏👏👏

[@codigofontetv]

Muito obrigado por nos acompanhar e pelos elogios. Desejamos tudo de melhor que a vida possa proporcionar à vocês na Austria. Sucesso e muitas felicidades.

[@SuelenMMariano]

@@codigofontetv desculpa escrevi tudo no singular. Mas me refiro a vocês dois!. Respeito pelo canal e gratidão a vocês dois!. Ensinam muito! Falam de uma forma limpa e que nos ajuda de mais!. O mundo da programação é nosso objetivo!. Queremos muito isso!. Mas entrar nele é bem confuso!. Muita coisa pra aprender!. Obrigada pelas palavras!.

[@carlostimoteoarruda4337]

Ótima série

[@carlostimoteoarruda4337]

Oba!!!! Mais um episódio!!!!

[@zardobeckerg.1220]

Achei otimo essa serie so Clean Code! Obrigado CodigoFonte

[@edmilson.nascimento]

Que serie f#$@! Eu estou adorando a serie e acho o conteuro super util. Faz parte da evolução do programador "work smarter, not harder". Parabens pessoal!

[@codigofontetv]

Muito obrigado Edmilson! Isso é um grande incentivo para continuarmos

[@marcioramos9203]

Gosto muito desse tipo de video. Onde temos o conteúdo teórico e suas motivações e a prática onde aplica-lo. Parabéns pelo Canal!

[@codigofontetv]

Muito obrigado 😃

[@junioranheu]

Comprei esse livro hoje! Que coincidência :)

[@leandromachado7199]

A PEP-8 sugere, como boa pratica, que os nomes dos métodos e funções em Python sejam snake_case.

[@atnsousa]

fazendo uma contribuição: em python temos algumas convenções (acordos formais, mas não são leis rs) que nos orientam a como deve ser "escrito" os nomes de variáveis, classes e funções. Classes utilizam-se de letras maiúsculas e minusculas, sem aspaços e sem separadores, já funções, e variáveis, é tudo em minúsculos e com o underline como separador de palavras. reforçando: não é lei, cada programador carrega consigo os hábitos/resquícios de outras linguagens.

[@jonnyvv]

Com certeza e uma das lições mais importantes, iniciei numa nova equipe que em todo code review algum detalhe desse é encontrado. Em compensação a leitura e a manutenção do código se torna muito mais simples e ágil. No começo quando não se está acostumado, pode parecer meio trabalhoso, mas depois que está no sangue só tem benefícios.

[@marciorjusto]

Mas é por isso que a escolha da IDE é tão importante: com plugins, templates, "linters", etc... é possível "automatizar" esse processo de verificação das "normas" de escrita. E atualmente há até Inteligência Artificial sendo usada para "aprender" essas normas e sugeri-las

[@cssgabriel]

Muito bom!! Aprendi demais com esse vídeo.. já quero sair refatorando kkkk

[@ricardodeoliveiraalves339]

Para falar sobre como escrever código, temos que considerar também: Boswell & Foucher, Pete Goodliffe, ... São visões diferentes que se complementam. Se bem que tio Bob é com certeza o maior expoente nesse tópico. No fim, tudo resume-se à: seu código deve ser facilmente entendido por terceiros (lembre-se de que o "terceiro" pode ser você mesmo daqui alguns dias, meses, anos,...) Eu mesmo já fiz uns códigos que quando estavam frescos na cabeça, eram super simples e faziam sentido. Alguns meses mais tarde quando precisei dar manutenção no código, que eu mesmo tinha escrito, o nível de "que por.. é essa" subiu drasticamente... e é essa situação que você quer evitar ao escrever um código.

[@alexsandroandrade6771]

Muito bom o conteúdo e explicação do vídeo. Como sempre material de qualidade para estudo e análise de novos conceitos do mundo da programação. Obrigado.

[@Diego-Garcia]

Excelente! É ótimo mostrar essas boas práticas... na prática 😂 No caso do Python, eu recomendo vocês darem uma pesquisada na biblioteca built-in "itertools". Nela tem muitas funções utilitárias que ajudam ao trabalhar com lógicas que envolvem muito cálculo (sem falar que apenas lendo as implementações das funções você aprende muito). Outra biblioteca muito útil quando você está codando utilizando técnicas do paradigma de programação funcional é a "operator".

[@charliebellow2229]

Bem legal essa série. Eu não aprendo muito lendo, preciso de vídeos como esse pra me ajudar a enteder os conceitos!! Ajudou bastante e já estou pensando em como melhorar meu código

[@heitormbonfim]

Gostei desse novo formato.

[@elielsonsouza3025]

Its very good! Working! Thanks.

[@arcstur]

O tratamento de erro no Rust com o enum Result é incrível na minha opinião

[@samuel_do_prado]

Muito obrigado pelo conteúdo, sensacional! Façam um vídeo sobre o abstract factory pattern, por favor

[@codigofontetv]

Faremos!

[@samuel_do_prado]

@@codigofontetv 🥳

[@arcstur]

Acho que o mais importante é manter as funções pequenas, com isso parece que tudo vai se resolvendo.

[@isaacbaruccruzdasilva7701]

Creio que a parte mais importante é a do nível de abstração. Mas uma que eu não sabia era a dos números mágicos kkkk realmente tem que estar atento.

[@heitormbonfim]

Quero ver ela codando tbm!!!!

[@rotognin]

Existem pessoas que possam pensar: "ah, mas a validação de cpf nunca muda, deixa o código assim mesmo..."... isso diz muito do caráter dessa pessoa! kkk Brincadeiras à parte, a refatoração necessita de muita atenção, pois qualquer detalhe pode acabar escapando e parando de funcionar! Aí vem a vontade de "não mexer no que já está funcionando"!

[@gabrielpereiramendes3463]

#excelente

[@wevertontsousa]

Vocês são D+! Uma dúvida, a ideia de muitos parâmetros para Construtores não se aplica certo? Pois para criar o objeto Cliente os parâmetros do Construtor seriam os mesmos passados Antes ao método adicionar.

[@JoMatSar]

Pessoal, parabens pelo canal. Falem sobre Abstract Factory, please!

[@investidor_anonimo]

Série top

[@isaiasluiz5697]

Show, boas dicas. O triste disso é re- faturar um Monte de códigos. Kkk

[@marciorjusto]

Vá por partes, refatore um pouco de código por vez, mas somente depois de ter construído testes unitários automatizados.

[@engecivila]

colocar no retorno de uma funcao por exemplo return 1 < 2 que implicitamente ja eh true ao inves if (1 < 2) return True return false é indicado?

[@carlos-rian]

Bem legal o conteúdo. Apenas indico usar o pyright e mypy, pois melhora a escrita de forma "pythonica", dessa forma parece mais um C#/JS. Assim como todas as linguagens python tem um guia de estilo, apesar de permitir qualquer forma é aconselhável usar o padrão de estilo/escrita.

[@atnsousa]

o que acho legal desses tipos de vídeos, é a exposição de colocar a mão na massa (e parabéns por isso)... para muito isso é um obstáculo (eu me incluo nisso), pois há sempre um receio de fazer algo errado, ou ainda de não ter compreendido como o autor desejava e assim criar códigos incorretos, com base no tema proposto.

[@MyFriendDev]

(reassisitindo aqui pra revisar oq li no livro) acho engraçado que eu aqui agora fazendo os métodos em java usando essa regra tava ficando preocupado em ter muitos pequenos métodos e se n me engano no capitulo 10 ele diz exatamente pra não se preocupar com isso pq é muito mais fácil de testar os pequenos métodos e entender o que eles estão fazendo [mas ainda sigo no medo do method Hell xD]

[@viniciuscogo1591]

Por favor, falem sobre o Abstract Factory bem detalhado!

[@leonardopereira3764]

Abstract Factory !!!! Nunca pedimos nada!!! Por favorzinho!!!

[@noriller]

Não sei se ta no capitulo, mas pra esse tipo de coisa e especialmente codigo legado: testes se não tem teste, cobre de teste o suficiente e vai alterando um pouco por vez, sempre tendo certeza que não ta quebrando nada. não consigo salientar o quão importante é testar antes de refatorar algo legado, a experiencia de refatorar (ou mesmo só de mexer com) codigo legado vira outra coisa!

[@Diego-Garcia]

Aí tu descobre erro de lógica do código enquanto está escrevendo os testes 😂

[@noriller]

@@Diego-Garcia direto! E eu que fiquei recebendo um erro quando não tinha nada de errado e só depois de perder uns cabelos vi que retornava uma string duplicada de outro erro?

[@marciorjusto]

Excelente!!!

[@MrRodrigorrch]

Falem sobre o Abstract Factory =)

[@DougLopes]

Interessante ver código python com funções curtas, sempre que vejo algum são funções gigantes que fazem muita coisa, nem sabia que python tinha classe. Acho que nem todos os CPF's tem o mesmo número de dígitos, então talvez fosse interessante ao invés de usar números absolutos usar o (número total_de_digitos - 1) pra pegar o último por exemplo. Ótimo vídeo.

[@TheMarcosVerissimo]

Gente, eu entendo a necessidade de manter código legível, mas a parte de que dentro de if/else haja apenas uma linha pode deixar a coisa meio complicada. No fim das contas arrisca-se ter uma matrioshka gigantesca em que algumas vezes teremos que ficar procurando o código da função. Aí dentro dessa função tem uma outra chamada a outra função, e por aí vai. Além do que, não há um overhead de execução a tantas chamadas de funções que poderia diminuir a eficiência do código? Talvez um equilíbrio entre a legibilidade extrema e a eficiência seja o ideal, não acham?

[@marciorjusto]

Também entendo que deve haver equilíbrio e bom-senso, mas o livro não impõe regras, apenas sugere práticas que podem facilitar o trabalho. O problema são os códigos "macarrônicos" geralmente legados ou feitos às pressas e encapsulados em "classes faz-tudo".

[@fdomds]

Quando você precisa otimizar funções para reduzir custos no lambda ou functions na gcp, acaba aplicando algumas destas dicas sem ler o livro. rs

[@areaprogramacao]

As 7 principais regras do Clean Code! 1. Utilizar nomenclatura clara e intuitiva é importante utilizar nomes que tenham relação com a finalidade do código. 2. Seguir os padrões utilizados no código padronização desses elementos, que poderão ser facilmente identificados por outras pessoas programadoras. 3. Manter os dados de configuração separados do código fonte Os dados de configuração, como strings de conexão com o banco de dados, devem ser adicionados em um arquivo separado do código fonte 4. Evitar repetições excessivas Prefira desenvolver códigos curtos e que tenham uma única função específica, 5. Ter cuidado com o uso de comentários no código eles devem ser utilizados com moderação e alterados sempre que houver necessidade 6. Realizar o tratamento de erros garantir o bom funcionamento do software, quanto para exibir mensagens esclarecedoras sobre o problema encontrado. 7. Executar testes limpos Utilizar Clean Code é importante para que o código seja compreendido com mais facilidade por outras pessoas desenvolvedoras e seja possível realizar manutenções mais rápidas e eficientes.

[@gepetovovo2509]

@@marciorjusto quero ver é se vc tem 1h pra entregar na pressão e falar q vai fazer tudo isso.. em Nárnia dá pra fazer, mas ali no Fervo não dá não e o cliente não vai pagar por essa demora toda ai não, nunca na minha vida vi código limpo, aonde isso é falado a 15 ou 20 anos, no papel tudo é maravilhoso, mas na vida real é codigo tudo zuado, lento, com bugs e turnover alto em empresas ai.

[@gepetovovo2509]

@@marciorjusto mas a REALIDADE não é essa uahahaha.. vc trabalha com isso, ou só é aqueles estudantes que vem cheio de teorias e com peito estufado igual a um pombo??? eu trabalho com isso a mais de 20 anos e é outra pegada não é NARNIA não.

[@gepetovovo2509]

@@marciorjusto e estudo é uma coisa e pressão é outra, muitos vem iludidos e maravilhados achando que vão encontrar ambiente "pomposo", eu ganho ai por volta de 110,00/h e não tem nada disso ai não.. uahaha.

[@gepetovovo2509]

@@marciorjusto ai amigo tu trabalha só com PL/SQL que pra mim é muito facil, eu trabalho com ORACLE desde o 8i e um dos sistemas aqui internamente é Delphi que chama uma package em ORACLE 12c, que integra com WS escrito em c# que vai dados pro Protheus da TOTVs que ainda manda dados numa DMZ com mongo db com endpoint em nodejs q é pra outros clientes olharem um relatório macro com interface em React Native, tem demanda que tem q alterar todas elas e no caso sou eu pra alterar tudo e vai falar que vai demorar 1 dia pra ficar com firula ai de IDE.. quero ver a sua magia com uma IDE só pra fazer tudo isso.. kkk acho q é por isso que sou bem remunerado, por saber várias linguagens mexer em tudo ao mesmo tempo, sem enrolar.

[@KillerzaumGames]

Seria bom falar sobre factory, tem um tempo já que estou pra aprender

[@talesjulian2050]

A questão de uma linha por função ficou bem confusa pra mim, pois em algum momento, o sistema fará alguma verificacao para seguir um determinado fluxo ou outro. Um exemplo seriam as exception, como neste caso você teria uma terceira função que chamaria um fluxo ideal ou um alternativo nos quais estão em funções distintas? Em algum momento terá uma condicional.

[@marciorjusto]

Pelo que entendo de "uma linha por função", seria agrupar o máximo de comandos que atendam a uma funcionalidade em uma procedure ou function. Quando esta for chamada no bloco principal, será usada no máximo 1 linha, pois a lógica, variáveis, constantes e até exceptions estão encapsuladas dentro desse bloco. Claro que condicionais continuam a existir no bloco principal, mas esses vão descrever o fluxo muito mais em termos de regras de negócio, sem misturar com comandos de "baixo nível" como exceptions. É nesse sentido que a legibilidade do código sugerida pelo autor do livro melhora e simplifica.

da pra usar o ChatGPT pra ajudar na fatoração dos códigos

[@bgeneto]

Muito bom o vídeo, parabéns e obrigado! Isso ajuda muito os programadores iniciantes! Mas por falar em normalização.... Poderiam ter utilizado Python e inglês do início ao fim (misturou as linguagens) e, já que está usando Python, seria interessante usar o PEP8 ao nomear as variáveis, métodos etc :-)

[@hebertcampos9326]

Quero entrar na área de Dev ios ano que vem, vocês indicaria alguma graduação para que eu possa estar dando início?

[@97DanielxD]

Explica o abstract factory patern please

[@lukasmarques9201]

Cria um Enum para os digitos 10 e 11

[@heltoncanada]

Abstract Factory, please!

[@joaotomchak7279]

Sabendo o básico do básico e praticamente não ter programado nada, ainda vale a pena ler o Clean Code?

[@ClaytonAAlves]

"nível de abstração" não é "nível de indentação". O nível de abstração está mais relacionado com a coesão da função.

[@samprafael]

E cada capítulo dessa série descubro mais erros que sempre cometo....

[@rafaelrmtt]

Uma dúvida: A criação de tantas funções não torna o programa mais lento?

[@Seu_Lunga]

Só tem 1 problema, vcs usaram OO, isso já muda completamente, a refatoração deveria ter sido feita usando o mesmo paradigma.

[@octograma0705]

👍😉

[@MarcusBecker]

Até parei de ler o livro, vou ficar só nos vídeos dessa mini-série! :)

[@codigofontetv]

Não deixe de ler, é importante! Se quiser leia junto com o lançamento dos capítulo correspondente do livro, assim as lições fixam ainda mais. ;)

[@evandr000]

Eu tenho pena de quem for tentar aplicar essas regras num projeto React totalmente funcional XD

[@Herik_Santos]

Kkkkk eu sempre começo minhas aplicações em inglês, mas depois de um tempo meu vocabulário fica limitado e tasco-lhe um português

[@lucianobritodev]

Porque não usaram um regex maroto?

[@ricardopouza4198]

Ninguem do youtube fala da programação da urna eletrônica. Seria um bom video para se tomar strike kkk

[@thiagosilvamarques2904]

Eu não concordo tanto assim com algumas coisas, me parece que você resolve bem mais para um nicho especifico, por exemplo, parâmetros para funções, funções sem parâmetro, não e tão funcional se relevarmos, algo como paradigma funcional. além de que funções sem parâmetros, em grande maioria dos casos são triviais ou geram efeitos colaterais por se tratarem de funções que mudando o estado de algo, pois não são puras, pois seu funcionamento deveria depender dos valores de entrada. Pra mim o Uncle Bob, responde muito bem para linguagens multiparadigmas ou de POO, mas me parece que fica devendo em alguns pontos no quesito paradigma funcional, principalmente nessa parte de funções, mas são alguns poucos pontos, que ajudam vc a escrever um código mais limpo, mas por os exemplos serrem em Java, também não fazem sentido

[@BrunoQ-ueiroz]

Só uma dúvida. Pode-se criar função dentro de função? Kk

[@miguellopes9177]

Pelo que eu saiba (que não é muito alias) você pode chama uma função dentro de outra função. Mas criar uma já fica zoado

[@Diego-Garcia]

Sim, no Python pode.

[@BrunoQ-ueiroz]

@@Diego-Garcia Dessa resposta eu gostei 😎

[@AndreCarneiro666]

Não faz sentido usar atributos protegidos em Python. Na prática não funciona e causa problemas nos testes. O mesmo para funções/métodos. Usem atributos com um underscore apenas. Nunca dois!

[@maisnaterra]

em portugues é complicado, em ingles é pior kk mas deve ser bom pra aprender a lingua

[@jaquisonsouza5143]

O primeiro código é muito verboso... temos o regex que nos proporciona um código muito mais limpo e fácil de entender

[@Tocherman]

BitWise não é clean code.

[@davidsonrogeriodeaguiar2878]

Por favor, falem sobre o Abstract Factory bem detalhado!