Akita disse de forma inteligente que as principais técnicas da programação é a simplicidade e a clareza , e tudo diz como serão as declarações de entradas e de saídas, comentar o programa para facilitar compreensão do código, evitar ser confuso, preferir exibir "println" do que "printf", dominar bem as técnicas de orientação a objeto e métodos, praticar, e ver os diversos pontos de vista de que se trata um assunto. Akita foi objetivo na sua experiência de programador, foi brilhante, nossas palmas pelo mérito.
Nossa não conhecia esse Fabio Akita, mas a explicação dele da confusão que foi feita no conceito de Design Pattern no Brasil por conta da tradução de Pattern e de Standart serem iguais usando a metafora da casa foi fenomenal. Trabalhei por 5 anos como interprete Ing-PT e agora migrei pra data science, é engraçado como as duas areas requerem inteligencias parecidas. No fim, as duas lidam com problemas de linguagem né. Maravilhosa explicação e conversa, 10/10! Obrigado pelo video.
Cara, recomendo dms tbm o canal dele, muito conteúdo de programação ainda mais ele q tem muita experiencia, além do canal dele ser sem AD, pois é totalmente ditatico, aprendi muito coisa por baixo dos panos com os videos dele.
dos programadores youtubers, o Fabio é de longe o melhor. Nunca vi ninguém tão coerente quanto ele e o segundo melhor é o Carlos melo (um grande especialista em data science por sinal.)
Conheço ele há anos. Acho que ele pode ser considerado o Papa da Programação no Brasil. O cara já passou por tudo,desde o começo o do mundo,da Programação. Eu até sou mais velho que ele e acompanhei tudo isso,mas sem aperfeiçoar e trabalhar com isso antes.Ouvindo ele falar,passa um filme PB na mente. Só um cara como ele pode ser chamado de sênior.
Muito boa essa conversa! Agregou bastante a minha forma de ver o código. Não se preocupar tanto com o desempenho do programa, mas dar prioridade para a manutenção futura do mesmo. A grande maioria dos sistemas que desenvolvemos não precisa, realmente, se preocupar com desempenho. Em alguns casos sim, por exemplo, em apps para smartphones, onde o ideal é tentar não consumir muita bateria, e o tráfego absurdo de dados também pode ser algo a se observar. Pra mim, que desenvolvo desktop, o mais importante é a manutenção, pois o sistema em que atuo é um ERP gigante, e se perder nele é muito fácil, com códigos de uns 30 anos atrás... rsrsrs Show de bola!
Top demais, não sou programador, mas gosto muito do assunto. Seria interessante uma tela compartilhada mostrando exemplos práticos de alguns detalhes mencionados. Parabéns aos desenvolvedores do conteúdo!
1. Comente. Comente tudo, até comentários. Comentários nunca estão em excesso 2. Ifs e elses, sempre. Quanto mais laços condicionais e laços de repetição melhor 3. Esqueça toda e qualquer programação orientada a objetos. Programação estruturada é o futuro 4. Se nem você conseguir entender o q codou, excelente! 5. Foque apenas no framework, nem pense em olhar as bases e, principalmente, não leia documentação. Gaste 6h por bug, isso vai fazer crescer cabelo no seu peito
Ver o Akita, à quem tenho como grande referência e mentor na minha educação, participando na alura, a escola de cursos online onde dedico uma enorme parte do meu tempo de estudos, é um prazer gigantesco. Convide-o mais vezes, Paulo! 🥳🥳
vc recomenda a Alura mano ? muitos me disseram ser uma plataforma muito iniciante onde tu n sai do basico a ponto que tu aprenderia tudo isso porr conta no youtube. Qual seu feedback sobre a plataforma ?
sim. a maioria dos devs sofrem disso, buscar sobre tudo ou em antagonismo, a síndrome de impostor, que não é resultado somente aos devs, como em todas as áreas da vida e profissionais
Muito bom esse conteúdo. Eu passei de Engenheiro de estrururas a desenvolvedor de software de estruturas. Antes me preocupava só em fazer algo funcional, pra resolver meus problemas localmente. Agora que preciso manter codigos que vão pra produção vejo como o buraco é em baixo e como precisamos das boas práticas. Sempre pensando que o codigo que estamos fazendo hje, pode ser usado por anos a fio.
Mais um aqui, com mestrado em estruturas e tudo kkk Programação me conquistou e nem penso mais em voltar, mas o raciocínio lógico da engenharia ajudou bastante
Essa conversa me lembrou muito uma palestra do Uncle Bob sobre isso. O Akita sempre traduzindo bem esses conceitos pra gente. No final vira tudo um binariozão pro computador entender, mas o importante é ter boas práticas que tanto quem programa quanto outros que poderão dar manutenção no código possam também entender. Muito boa a conversa! Parabéns.
Que bom saber que curtiu, Kamily! Obrigada por nos acompanhar! 💙 Você pode ficar de olho também nas nossas redes sociais, sempre levamos conteúdos semelhantes. 😉
c a r a l h o, que episódio f0d@. o Akita é um cara fora da curva. um dos poucos iluminados da "velha guarda" que sabe realmente como compartilhar conhecimento.
Salve!!! Trabalhei com mainframes na década de 70 e posso dizer que o custo de debugar um programa era o ponto mais dispendioso de um projeto. A fatura do aluguel de uma CPU IBM, por exemplo, era baseada no tempo de uso mensal da mesma e isso era muito, muito caro. Assim, o bom programador era aquele que conseguia colocar o programa em produção com o mínimo de execuções de testes possíveis.
Trabalhei com mainframe ibm 3270 nos anos 80 na Cesp. Se o código fosse testado mais que 3 vezes, o gerente do cpd vinha no dia seguintes para dar esporro, pois tínhamos que fazer teste de mesa
Ainda não sou programador, mas estou estudando para isso. Os vídeos do Akita são sempre fonte de inspiração para mim, como também, os podcasts da Alura me ajudam a entender melhor o mundo profissional.
Aqui estou eu, ouvindo, olhando e admirando dois gigantes, espero um dia chegar nesse nível! O @akita não perde a oportunidade de falar da década de 80/90, raízes!!
Eu posso estar sendo "o chato" aqui mas a real é que design patterns sao superestimados. Existem formas muito mais sofisticadas e elegantes pra os mesmo problemas usando linguagem funcional e metaprogramação (muitas vezes esses problemas nem existem). Na verdade muitos desses "problemas" que dp resolve foi a oo que criou.
Eu fiz exatamente isso no projeto do quinto módulo da imersão. Depois que terminei, separei em várias funções de forma a poder chamar cada recurso quando necessário, invés de repeti-los. Quanto ao pattern, eu sempre pensei neles como modelo, exemplo, amostra, tipo uma lista de cores de uma casa de construção que a pessoa olha e escolhe uma cor para pontar a sua casa. O pintor é o programador que usa o modelo de acordo a necessidade do momento.
Excelente pontos expostos pelo Akita, tem gente tão neurótica e confusa hoje em dia com os conceitos de Design Patterns, Enterprise patterns, TDD, DDD etc ... que vi alguns chegarem a dizer que se o código não utilizar metodologias X, Y ou Z, no seu desenvolvimento, será impossível de dar manutenção no futuro, não será escalável, performático e assim vai ... sério mesmo? E o pior, outros que quando vão desenvolver uma funcionalidade X em um sistema, e começam a refatorar código fora do escopo da atividade, só por que viu um método que não segue o pattern X, correndo o risco de criar mais problemas, pois como a mudança não foi planejada, ninguém irá testá-la ... Aonde trabalho mesmo, será necessário rever alguns conceitos utilizados no desenvolvimento de alguns componentes, pois criaram a base em cima de 100 mil patterns e designs hypes da atualidade, o que tornou uma tarefa "monstro" o simples desenvolvimento um componente ...
Sobre a questão de performance e produtividade que o Akita comenta, uma linha de raciocínio interessante é que mesmo que a lang X não seja a mais rápida, ela pode ser rápida o suficiente para boa parte dos casos de uso, valendo seu uso para ganhos de produtividade, por exemplo.
"A produtividade vale mais, do que a economia de performance que eu teria" AKITA, Fábio (2021). Muita sensatez em uma frase! Paulo e Fábio, parabéns pelo vídeo!
"Daqui a dois dias você vai olhar pro seu código e não entender mais", basta um final de semana para que eu esqueça o que estou fazendo. Não atoa, quando estou num projeto Desktop, por exemplo, e preciso voltar pra um Mobile, demoro mais até pra gerar a release... Ótimo vídeo!
07:20 To passando por esse problema aí. Preciso colocar o "site da padaria" no ar, mas quando vejo que o código não tá ficando legal, largo tudo e vou estudar as boas práticas. Já tem uns 7 meses que to nisso, mas não reclamo, agora tenho uma visão do ciclo de vida do software e não só do código. Acho que finalmente posso colocar o "site da padaria" no ar.
O Akita explica muito bem e traz analogias muito interessantes. O papo desses dois é excelente. Acompanho desde a primeira vez que o Paulo chamou o Akita. E o mais legal pra quem é da área é ver uma conversa dessas e perceber os paralelos com a prática diária no desenvolvimento de software. Parabéns a vocês por esse trabalho incrível!
19:15 kkkkkkkkkkk acabei de me lembrar de um dos meus primeiros trabalhinhos na faculdade com java que eu meti 4 for's e um monte de if dentro de um método com umas sei lá 50 linhas hahahahaha
Conheço o Paulo através do Nerd Cast e eu sempre crio uma pessoa na minha mente quando conheço ela só por voz. Agora assistindo um video com ele é estranho porque sempre que olho pra ele acho que ele está sendo dublado pela pessoa que criei na minha mente.
Eu ainda estou aprendendo lógica de programação e, quando o Akita fala sobre termos técnicos parece que estou ouvindo um ET, mas as dicas que ele dá sobre o "como trabalhar" ou como "se situar" de forma a não apenas aprender, mas se desenvolver na área, são interessantíssimas. Ele vai destruindo nossas ilusões, mas são ilusões que, em algum momento, teriam sabotado os alicerces do nosso trabalho, então é bom aprender logo enquanto construímos esses alicerces.
Adorei o ponto do Akita. Me parece bem tipica discussão do aumento do débito técnico. Códigos sem boa prática gera uma bola de neve que leva ao aumento do débito técnico que leva ao aumento de custo para qualquer manutenção no futuro...
Muito bom, realmente trabalhando em equipe quando precisamos analisar e ou usar de exemplo o código de outra pessoa, geralmente é uma tristeza... mas não considero porque eu codo bem e o colega coda mal e ou vice-versa, mas simplesmente porque com a correria do dia a dia, não temos tempo para nos alinhar quanto equipe e definir um padrão, em toda empresa que eu passo eu tento fazer com que a equipe tenha um padrão, de novo, eu não sou ninguém para estipular.. eu apenas tento começar a discussão para que possamos progredir juntos. Sempre tenho dificuldade com códigos dos colegas por limitações minhas e deles, assim como pessoas também tem dificuldades com os meus códigos e até eu tenho também kkk
Sugiro a leitura do Zen of Python >>> import this Bonito é melhor que feio. Explícito é melhor que implícito. Simples é melhor que complexo. Complexo é melhor que complicado. Linear é melhor do que aninhado. Esparso é melhor que denso. Legibilidade conta. Casos especiais não são especiais o bastante para quebrar as regras. Ainda que praticidade vença a pureza. Erros nunca devem passar silenciosamente. A menos que sejam explicitamente silenciados. Diante da ambiguidade, recuse a tentação de adivinhar. Dever haver um - e preferencialmente apenas um - modo óbvio para fazer algo. Embora esse modo possa não ser óbvio a princípio a menos que você seja holandês. Agora é melhor que nunca. Apesar de que nunca normalmente é melhor do que *exatamente* agora Se a implementação é difícil de explicar, é uma má ideia Se a implementação é fácil de explicar, pode ser uma boa ideia Namespaces são uma grande ideia - vamos ter mais dessas!
Tenho que admitir que dar nomes pras coisas é muito difícil kkkkkk Sempre fico pensando "Será que é esse nome é bom, será que tá muito grande"? É uma coisa viu.
Quem ainda não leu, não vai entender que, todas as descrições do Sr. Akita, no que diz respeito a “boas práticas”, parafraseiam o Sr. Martin (Uncle Bob) em seu livro Clean Code. Então, se ainda tem alguma dúvida (talvez pelo fato do Sr. Akita não apontar o caminho de bom grado, mas, por misericórdia aos menos ignorantes, deixar dicas sutis)... *LEIA O LIVRO CLEAN CODE!* Desde “Junte seu time e decidam um padrão de vocês”, até “Não tente programar limpo, faça rodar e depois limpe o código”, e mesmo “Não existe número certo de linhas, se a função pode ser entendida de primeira não importa se ela tem 5 ou 15 linhas”, todas são parte das abordagens do Sr. Martin (Uncle Bob) em seu livro. Nota pessoal: Esse livro não é um “passo a passo de como programar limpo”, ele é um manual de como ser um programador bom de verdade (um passo muito importante para você se tornar um programador *excelente* um dia)!
Eu pego bastante trabalho free lance pra criar apps de gerenciamento de pequenas empresas... Porém a maioria são empresas bem pequenas, com 9, 10, 20 funcionários... Precisam de algo rápido, simples e que saia rápido. Acabei criando uma biblioteca de banco de dados em Java que eu só jogo o jar dentro do meu projeto e prontinho, tudo funcionado com uma simplicidade absurda! O que dá pra ligar entre o que foi dito no vídeo e esse BD? - Acelerei a minha produção ao criar um BD que não requer instalação separada e nenhuma configuração extra. - Facilitei o backup. O DB cria uma arvore de subpastas dentro de uma pasta primária chamada "db", basta copiar essa pasta e o backup tá pronto. - Poupei recursos da máquina. - Facilitei o entendimento do projeto já que minha biblioteca dispensa o uso de classes "Repository". O uso consiste em simplesmente implementar "Ente" na minha classe. Isso já gera todos os métodos de CRUD e um identificador "EnteId" que é um número long que vai de -2^64 até 2^64... Ou seja, tem ID ai suficiente pra salvar o número de átomos no universo... Agora, o problema... Qual grande empresa usaria isso nos pequenos projetos? Por isso eu prefiro trabalhar free lance. Gasto menos do meu juízo ganhando meu dinheiro do mesmo jeito.
28:00 Pelo que andei pesquisando o Alistair Cockburn não escreveu um livro sobre Arquitetura Hexagonal. Um dos livros mais famosos dele mesmo é esse da imagem "Escrevendo Casos de Uso Eficazes".
reduzir "If and Elses" testar seus programas com atenção reduzir os pages por meio de testes e reduções organização e endentação sempre deixar classes bem específicas ou seja fazer pequenas bagunças e organiza-las
Atualmente, estou imerso no programa ONE Oracle Next Education T6, uma colaboração entre a Oracle e a Alura. O curso me abriu a mente para o aprendizado de Lógica de Programação e a exploração dos fundamentos da programação com JavaScript. Além disso, destaco o meu interesse nesse vídeo sobre boas práticas de programação, o qual considerei bastante instrutivo e valioso. #oraclenexteducation #alura #HelloONET6
O Akita muito bom porque ele domina tópico de ciência da computação. Acompanho ele desde 2019 fiquei impressionado como o vídeo dele o Hello World como você nunca viu. Dali em diante passei a acompanhar o canal dele
Muito bom. A única coisa que eu não concordo é sobre o aumento da capacidade de processamento vs utilização real. Hoje em dia os programadores se apoiam muito justamente nesse aumento exponencial das capacidades de processamento e armazenamento duas ordens de grandeza mais rápidos do que há dez anos atrás, a ponto de que, para um simples "hello world" em Node ou React necessita de um projeto com mais de 300 Mb e 250.000 arquivos! Instale duas ou três bibliotecas no projeto e esse número sobe para mais de trezentos mil arquivos. Além disso, o excesso de modularização, uso de ferramentas exclusivas para o ambiente DEV e a falta de teste de um sistema com um volume de dados próximos ao real, utilizando banco de dados em memória para testes, por exemplo, quando o ambiente final será com um banco real direto ou em micro-serviço externo, faz aparecerem umas operações bizarras que levam de minutos a horas para serem concluídas, excesso de carga no servidor, etc, exigindo a contratação de mais poder, claro, onde uma otimização nas consultas e técnicas de cache programática, quando apenas o cache do SGDB não é suficiente trariam para tempos mais aceitáveis. Resumindo, discutir "sexo dos anjos" em sistemas pequenos ou que o ganho de desempenho seria ínfimo, realmente não importa, mas testar num ambiente QAS próximo ao de produção, com os bancos, volume de dados e conexões externas, isso é importante para revelar gargalos. Na área de front end, por exemplo, sempre bom testar o site que tenha muitas animações num computador bem inferior ao de desenvolvimento (a menos que o do dev já seja inferior 🤘🏾). Um banco que vá receber 10 milhões de registros, testar com 2/3 milhões no mínimo.
Tem muito norte-americano que abraça Design Patterns como Standards também. Vai além da tradução o problema. Gostaria de mencionar que existem também os "de-facto standards" que são confundidos como obrigações. Gostei muito da análise. Adicionaria ainda o fato que cada projeto pode criar seus próprios padrões.
Em 12:00; Quer dizer que codigos como PHP, Java Script, Phyton e etc, são codigos mais extensos porém mais acertivos, enquanto codigos como Java, C, etc, são compiladores porém mais passiveis de erros e uma legibilidade carente?
E eu achando que "Patterns" era "Padrões" ... Meu Deus hahahahaa ... são repetições não necessariamente necessárias ... kkkk ... top demais ... Parabéns pelo conteúdo.
muito legal a discussão, acho que fugiu um pouco do tópico principal que são boas práticas de programação, nome de variáveis, funções ou métodos que façam aquilo que foram escritos pra fazer, módulos e classes pequenos que possam ser reutilizados, não ficar copiando e colando trecho de código ao invés disso modularizar o trecho, uso de interfaces e contratos ou um padrão de projeto poderia ser utilizado como exemplo o MVC é bem claro e poderia ser exemplificado também enfim, independente de poder de processamento as boas práticas podem ser aplicadas ainda mais pensando em times grandes que trabalham no mesmo código, uso de constantes e presar pela imutabilidade que ajuda muito a manter o código modular e coeso. uma vez eu vi um exemplo bacana que deram para esse tópico a função LS do Linux por exemplo foi escrita há mais de 4 décadas e nunca foi modificada pelo simples fato de ser extremamente simples e fazer o que foi proposto no caso listar um diretório.
Agora sim um formato mais palatável do programa. Sem ter que olhar pra camera os 2 ficam menos robóticos kkkk vou até me inscrever, assistiria 1h tranquilo
Eu tento manter meu código o mais organizado possível, tento usar o mínimo de comparação de variáveis com strings ou números soltos quando eu vejo que a comparação se repete em muitos lugares. Passei umas 6/7 semanas rafazendo o app que eu trabalho do zero porque inicialmente tive que fazer muito rápido pro produto sair rápido e chegou em um ponto que qualquer linha que eu adicionava 4/5 coisas diferentes quebravam. Aproveitei o produto no ar, li planejei, refatorei, mudei algumas ferramentas (comecei a usar TypeScript, por exemplo, que ajuda horrores) e hoje eu posso dizer que tenho orgulho do que tô fazendo, não que não tivesse antes, tava funcionando, mas só eu sei como (aliás, só a eu do dia que eu escrevi sabe como XD).
Eu já ouvi professores do RUclips dizendo que boas práticas são apenas burocracia e também já escutei muitos usuários usando o termo "Cagando regras" quando alguém ensina o certo.
Esse ponto que ele disse sobre o linguição acontece demais no dia a dia. A gente desenvolve o código de uma maneira, e dois dias depois quando voltamos nele, nossa ótica já muda em relação a desempenho. Daí acabamos refatorando tudo pra termos uma melhor visibilidade quando voltarmos nele no futuro.
Akita disse de forma inteligente que as principais técnicas da programação é a simplicidade e a clareza , e tudo diz como serão as declarações de entradas e de saídas, comentar o programa para facilitar compreensão do código, evitar ser confuso, preferir exibir "println" do que "printf", dominar bem as técnicas de orientação a objeto e métodos, praticar, e ver os diversos pontos de vista de que se trata um assunto. Akita foi objetivo na sua experiência de programador, foi brilhante, nossas palmas pelo mérito.
Queremos um podcast de Guilherme Silveira e Fabio Akita, abstraindo o mundo e a engenharia de software toda sexta a noite! kkkkk
Tenho muita dificuldade em refatorar código legado (código que escrevi 2 dias atrás)
hahahahahahahahahahhaha 😂 😂 😂 😂 😂 😂
kkkkkkkkkkkkk
KKKKKKKK
Sinal que tá evoluindo kkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
Nossa não conhecia esse Fabio Akita, mas a explicação dele da confusão que foi feita no conceito de Design Pattern no Brasil por conta da tradução de Pattern e de Standart serem iguais usando a metafora da casa foi fenomenal.
Trabalhei por 5 anos como interprete Ing-PT e agora migrei pra data science, é engraçado como as duas areas requerem inteligencias parecidas. No fim, as duas lidam com problemas de linguagem né.
Maravilhosa explicação e conversa, 10/10!
Obrigado pelo video.
Cara, recomendo dms tbm o canal dele, muito conteúdo de programação ainda mais ele q tem muita experiencia, além do canal dele ser sem AD, pois é totalmente ditatico, aprendi muito coisa por baixo dos panos com os videos dele.
dos programadores youtubers, o Fabio é de longe o melhor. Nunca vi ninguém tão coerente quanto ele e o segundo melhor é o Carlos melo (um grande especialista em data science por sinal.)
Conheço ele há anos. Acho que ele pode ser considerado o Papa da Programação no Brasil. O cara já passou por tudo,desde o começo o do mundo,da Programação. Eu até sou mais velho que ele e acompanhei tudo isso,mas sem aperfeiçoar e trabalhar com isso antes.Ouvindo ele falar,passa um filme PB na mente. Só um cara como ele pode ser chamado de sênior.
Muito boa essa conversa! Agregou bastante a minha forma de ver o código.
Não se preocupar tanto com o desempenho do programa, mas dar prioridade para a manutenção futura do mesmo.
A grande maioria dos sistemas que desenvolvemos não precisa, realmente, se preocupar com desempenho.
Em alguns casos sim, por exemplo, em apps para smartphones, onde o ideal é tentar não consumir muita bateria, e o tráfego absurdo de dados também pode ser algo a se observar.
Pra mim, que desenvolvo desktop, o mais importante é a manutenção, pois o sistema em que atuo é um ERP gigante, e se perder nele é muito fácil, com códigos de uns 30 anos atrás... rsrsrs
Show de bola!
Akita com o Paulo é uma combinação que rende muita coisa boa.
Que bom que curtiu, Arthur! 💙
@@alura Aula magnífica! Super agradeço a vocês.
@@alura C,vc,,b b
@@1robsonAqui .
..
8Per
@@1robsonAqui ppp
Top demais, não sou programador, mas gosto muito do assunto. Seria interessante uma tela compartilhada mostrando exemplos práticos de alguns detalhes mencionados. Parabéns aos desenvolvedores do conteúdo!
Oi Valter, ficamos muito felizes que você gostou do nosso conteúdo. Obrigada pela sugestão 😊
1. Comente. Comente tudo, até comentários. Comentários nunca estão em excesso
2. Ifs e elses, sempre. Quanto mais laços condicionais e laços de repetição melhor
3. Esqueça toda e qualquer programação orientada a objetos. Programação estruturada é o futuro
4. Se nem você conseguir entender o q codou, excelente!
5. Foque apenas no framework, nem pense em olhar as bases e, principalmente, não leia documentação. Gaste 6h por bug, isso vai fazer crescer cabelo no seu peito
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
Foram os 30 minutos mais bem investidos da semana. Obrigado pelo conteúdo, vocês são feras.
Ficamos felizes que curtiu 💙
Ver o Akita, à quem tenho como grande referência e mentor na minha educação, participando na alura, a escola de cursos online onde dedico uma enorme parte do meu tempo de estudos, é um prazer gigantesco. Convide-o mais vezes, Paulo! 🥳🥳
vc recomenda a Alura mano ? muitos me disseram ser uma plataforma muito iniciante onde tu n sai do basico a ponto que tu aprenderia tudo isso porr conta no youtube. Qual seu feedback sobre a plataforma ?
Sou professor de informática do Instituto Federal Fluminense. Se um dia eu tiver 10% da didática e conhecimento do Akita eu domino o mundo :D
Campos dos Goytacazes?
Tagsdandagstsfsag💘🥰😗🥰😗😚🥰😚🙃🤩🌜😚🥰🥰😗🥰😚🌜😗❤️🌜🙂🌜😗😚🌜😊🌜😚🌜🙂😗🌜🤗🌜🤗🌜☺️🌛😘🤩🌜🤗😊🌛🤩🌛😘😘😆😉🥰😘😗😚😗😘😗😂😂😗🥰😗😘😗
Ll
Esse é o tipo de conteúdo que nos livra de achismos e de síndromes do "eu preciso parecer um gênio". O bom senso deve sempre guiar o bom dev.
sim. a maioria dos devs sofrem disso, buscar sobre tudo ou em antagonismo, a síndrome de impostor, que não é resultado somente aos devs, como em todas as áreas da vida e profissionais
0p
Muito bom esse conteúdo. Eu passei de Engenheiro de estrururas a desenvolvedor de software de estruturas.
Antes me preocupava só em fazer algo funcional, pra resolver meus problemas localmente. Agora que preciso manter codigos que vão pra produção vejo como o buraco é em baixo e como precisamos das boas práticas.
Sempre pensando que o codigo que estamos fazendo hje, pode ser usado por anos a fio.
Engenheiro estrutural aqui também! Kkk passei para desenvolvimento de software em 2017. Uma das melhores decisões da minha vida!
Mais um aqui, com mestrado em estruturas e tudo kkk
Programação me conquistou e nem penso mais em voltar, mas o raciocínio lógico da engenharia ajudou bastante
Essa conversa me lembrou muito uma palestra do Uncle Bob sobre isso. O Akita sempre traduzindo bem esses conceitos pra gente. No final vira tudo um binariozão pro computador entender, mas o importante é ter boas práticas que tanto quem programa quanto outros que poderão dar manutenção no código possam também entender. Muito boa a conversa! Parabéns.
Nunca vi um vídeo tão bom e exemplificando tão bem o mundo de desenvolvimento. Massa demais! Preciso de um vídeo desse toda semana 👏👏👏
Que bom saber que curtiu, Kamily! Obrigada por nos acompanhar! 💙 Você pode ficar de olho também nas nossas redes sociais, sempre levamos conteúdos semelhantes. 😉
Que conversa produtiva. Imagino o quão prazeroso e rentável (me referindo a conhecimento) deve ser participar de uma conversa com os dois. Incrível!
c a r a l h o, que episódio f0d@. o Akita é um cara fora da curva. um dos poucos iluminados da "velha guarda" que sabe realmente como compartilhar conhecimento.
Salve!!!
Trabalhei com mainframes na década de 70 e posso dizer que o custo de debugar um programa era o ponto mais dispendioso de um projeto. A fatura do aluguel de uma CPU IBM, por exemplo, era baseada no tempo de uso mensal da mesma e isso era muito, muito caro. Assim, o bom programador era aquele que conseguia colocar o programa em produção com o mínimo de execuções de testes possíveis.
Trabalhei com mainframe ibm 3270 nos anos 80 na Cesp. Se o código fosse testado mais que 3 vezes, o gerente do cpd vinha no dia seguintes para dar esporro, pois tínhamos que fazer teste de mesa
Ainda não sou programador, mas estou estudando para isso.
Os vídeos do Akita são sempre fonte de inspiração para mim, como também, os podcasts da Alura me ajudam a entender melhor o mundo profissional.
Oi Jose, ficamos muito felizes em fazer parte do seu desenvolvimento!
Aqui estou eu, ouvindo, olhando e admirando dois gigantes, espero um dia chegar nesse nível!
O @akita não perde a oportunidade de falar da década de 80/90, raízes!!
Akita é muito foda, ele aprende com os erros que comete e ADMITE que errou, característica fundamental em quem tem ambição
Akita dá show!
Leu minha mente… Estava estudando boas práticas de programação.
Que bom que o conteúdo te ajudou, Douglas!!
Eu posso estar sendo "o chato" aqui mas a real é que design patterns sao superestimados. Existem formas muito mais sofisticadas e elegantes pra os mesmo problemas usando linguagem funcional e metaprogramação (muitas vezes esses problemas nem existem). Na verdade muitos desses "problemas" que dp resolve foi a oo que criou.
Cada aula do Akita eh quase que um semestre inteiro na faculdade...
Pp0
Eu fiz exatamente isso no projeto do quinto módulo da imersão. Depois que terminei, separei em várias funções de forma a poder chamar cada recurso quando necessário, invés de repeti-los.
Quanto ao pattern, eu sempre pensei neles como modelo, exemplo, amostra, tipo uma lista de cores de uma casa de construção que a pessoa olha e escolhe uma cor para pontar a sua casa. O pintor é o programador que usa o modelo de acordo a necessidade do momento.
Excelente pontos expostos pelo Akita, tem gente tão neurótica e confusa hoje em dia com os conceitos de Design Patterns, Enterprise patterns, TDD, DDD etc ... que vi alguns chegarem a dizer que se o código não utilizar metodologias X, Y ou Z, no seu desenvolvimento, será impossível de dar manutenção no futuro, não será escalável, performático e assim vai ... sério mesmo?
E o pior, outros que quando vão desenvolver uma funcionalidade X em um sistema, e começam a refatorar código fora do escopo da atividade, só por que viu um método que não segue o pattern X, correndo o risco de criar mais problemas, pois como a mudança não foi planejada, ninguém irá testá-la ...
Aonde trabalho mesmo, será necessário rever alguns conceitos utilizados no desenvolvimento de alguns componentes, pois criaram a base em cima de 100 mil patterns e designs hypes da atualidade, o que tornou uma tarefa "monstro" o simples desenvolvimento um componente ...
Pois é, criei asco de quem fica utilizando essas coisas como se fosse uma religião.
Ou tenho uma disfunção neurologica ou sou lento , assisti 3x para começar a entender metade do video...
Isso é uma aula, so pode...
Sobre a questão de performance e produtividade que o Akita comenta, uma linha de raciocínio interessante é que mesmo que a lang X não seja a mais rápida, ela pode ser rápida o suficiente para boa parte dos casos de uso, valendo seu uso para ganhos de produtividade, por exemplo.
Sensei Akita, o cara tem propriedade, e além disso tudo é um cara que passa uma motivação gigantesta pra área da programação.
Cara é sensacional a reflexão sobre maquinas, performance e as boas praticas de código ser para as PESSOAS e não para a MAQUINA!
Entendo que o refatoramento é muito importante, porém as empresas não pagam essas horas, quer o projeto o mais rápido possível para o cliente
AiAi.. apaixonante ouvir dois homens inteligentes conversando :3
3:10
" Hoje em dia que projeto tem so uma pessoa? "
Eu falando em voz alta no trabalho enquanto faço um projeto sozinho "Oxe eu aqui !"
"A produtividade vale mais, do que a economia de performance que eu teria" AKITA, Fábio (2021).
Muita sensatez em uma frase! Paulo e Fábio, parabéns pelo vídeo!
Ficamos muito contentes de saber que você gostou do vídeo 🥰
Camiseta do FullMetal mostra caráter
E o meu de 2 giga ram 😥💔😂😂
"Daqui a dois dias você vai olhar pro seu código e não entender mais", basta um final de semana para que eu esqueça o que estou fazendo. Não atoa, quando estou num projeto Desktop, por exemplo, e preciso voltar pra um Mobile, demoro mais até pra gerar a release...
Ótimo vídeo!
amei conhecer pattern usando hobbits haha
07:20 To passando por esse problema aí. Preciso colocar o "site da padaria" no ar, mas quando vejo que o código não tá ficando legal, largo tudo e vou estudar as boas práticas. Já tem uns 7 meses que to nisso, mas não reclamo, agora tenho uma visão do ciclo de vida do software e não só do código. Acho que finalmente posso colocar o "site da padaria" no ar.
O Akita explica muito bem e traz analogias muito interessantes. O papo desses dois é excelente. Acompanho desde a primeira vez que o Paulo chamou o Akita. E o mais legal pra quem é da área é ver uma conversa dessas e perceber os paralelos com a prática diária no desenvolvimento de software. Parabéns a vocês por esse trabalho incrível!
13:10 , eu ouvindo o Akita falando isso, e vindo na minha cabeça a Ubisoft uahauah
19:15 kkkkkkkkkkk acabei de me lembrar de um dos meus primeiros trabalhinhos na faculdade com java que eu meti 4 for's e um monte de if dentro de um método com umas sei lá 50 linhas hahahahaha
Ótimo! Sempre pensei assim. "Faz funcionar e depois deixa bonito"!
Conheço o Paulo através do Nerd Cast e eu sempre crio uma pessoa na minha mente quando conheço ela só por voz. Agora assistindo um video com ele é estranho porque sempre que olho pra ele acho que ele está sendo dublado pela pessoa que criei na minha mente.
Eu ainda estou aprendendo lógica de programação e, quando o Akita fala sobre termos técnicos parece que estou ouvindo um ET, mas as dicas que ele dá sobre o "como trabalhar" ou como "se situar" de forma a não apenas aprender, mas se desenvolver na área, são interessantíssimas. Ele vai destruindo nossas ilusões, mas são ilusões que, em algum momento, teriam sabotado os alicerces do nosso trabalho, então é bom aprender logo enquanto construímos esses alicerces.
Estou fazendo i
Bvh4
@@annajulianunes212 ?? KKK
Eu ficaria 10 hrs vendo o Akita falar
A gente também hahaha
Meu projeto ainda tem só 1 pessoa... kkkk
Excelente conteúdo. Parabéns!!
O Akita ele dá porrada na cara mesmo, por isso que eu gosto dele.
Adorei o ponto do Akita. Me parece bem tipica discussão do aumento do débito técnico. Códigos sem boa prática gera uma bola de neve que leva ao aumento do débito técnico que leva ao aumento de custo para qualquer manutenção no futuro...
Massa!!! Excelente papo, que contribuição pra comunidade \o/
Onde está o link para a parte 2, 3, 4 e 5? hahaha
👀👀👀
Akita + Paulo é like antes de começar o video....
conteúdo excelente, mas que cenário loko, a produção tá de parabéns!
Ficou lindo, né? 💙🥰
Sobre código limpo: para limpar ele precisa existir.
👏👏👏👏 Caramba! o Akita tem muito conhecimento ! Ele deve ter sido programador em outra vida :)
Que legal que você curtiu! 💙
Muito bom, realmente trabalhando em equipe quando precisamos analisar e ou usar de exemplo o código de outra pessoa, geralmente é uma tristeza... mas não considero porque eu codo bem e o colega coda mal e ou vice-versa, mas simplesmente porque com a correria do dia a dia, não temos tempo para nos alinhar quanto equipe e definir um padrão, em toda empresa que eu passo eu tento fazer com que a equipe tenha um padrão, de novo, eu não sou ninguém para estipular.. eu apenas tento começar a discussão para que possamos progredir juntos. Sempre tenho dificuldade com códigos dos colegas por limitações minhas e deles, assim como pessoas também tem dificuldades com os meus códigos e até eu tenho também kkk
esse codigo nao termina quando da Crtl s ... boaaa
Muito bom! 👏🏼
Interessante falar sobre isso, pois acredito que, nesse mundo louco da programação, está precisando demais disso
Vale um semestre de algumas graduações... pelamor
Olá, interessante seria colocar o áudio nos agregadores de podcast. Obrigado
Ótima sugestão, iremos providenciar.
Akita tem muita bagagem, pé no chão.
Ser rápido é o mais importante, por isso na física me ensinaram Fortran
Melhor explicação resumida em português...sensacional.
Sugiro a leitura do Zen of Python
>>> import this
Bonito é melhor que feio.
Explícito é melhor que implícito.
Simples é melhor que complexo.
Complexo é melhor que complicado.
Linear é melhor do que aninhado.
Esparso é melhor que denso.
Legibilidade conta.
Casos especiais não são especiais o bastante para quebrar as regras.
Ainda que praticidade vença a pureza.
Erros nunca devem passar silenciosamente.
A menos que sejam explicitamente silenciados.
Diante da ambiguidade, recuse a tentação de adivinhar.
Dever haver um - e preferencialmente apenas um - modo óbvio para fazer algo.
Embora esse modo possa não ser óbvio a princípio a menos que você seja holandês.
Agora é melhor que nunca.
Apesar de que nunca normalmente é melhor do que *exatamente* agora
Se a implementação é difícil de explicar, é uma má ideia
Se a implementação é fácil de explicar, pode ser uma boa ideia
Namespaces são uma grande ideia - vamos ter mais dessas!
Que aula!
Isso seria assuntos para seminário. Obrigado Paulo e Akita.
Que bom que gostou, Anderson 💙
Tenho que admitir que dar nomes pras coisas é muito difícil kkkkkk Sempre fico pensando "Será que é esse nome é bom, será que tá muito grande"? É uma coisa viu.
Make it work, than make it better!
Gosto muito das orientações do Akita,muito sensato e inteligente e sem frescura
onde da mais like?
Bicho, que bate papo massa!
Quem ainda não leu, não vai entender que, todas as descrições do Sr. Akita, no que diz respeito a “boas práticas”, parafraseiam o Sr. Martin (Uncle Bob) em seu livro Clean Code.
Então, se ainda tem alguma dúvida (talvez pelo fato do Sr. Akita não apontar o caminho de bom grado, mas, por misericórdia aos menos ignorantes, deixar dicas sutis)...
*LEIA O LIVRO CLEAN CODE!*
Desde “Junte seu time e decidam um padrão de vocês”, até “Não tente programar limpo, faça rodar e depois limpe o código”, e mesmo “Não existe número certo de linhas, se a função pode ser entendida de primeira não importa se ela tem 5 ou 15 linhas”, todas são parte das abordagens do Sr. Martin (Uncle Bob) em seu livro.
Nota pessoal:
Esse livro não é um “passo a passo de como programar limpo”, ele é um manual de como ser um programador bom de verdade (um passo muito importante para você se tornar um programador *excelente* um dia)!
Eu pego bastante trabalho free lance pra criar apps de gerenciamento de pequenas empresas... Porém a maioria são empresas bem pequenas, com 9, 10, 20 funcionários... Precisam de algo rápido, simples e que saia rápido. Acabei criando uma biblioteca de banco de dados em Java que eu só jogo o jar dentro do meu projeto e prontinho, tudo funcionado com uma simplicidade absurda!
O que dá pra ligar entre o que foi dito no vídeo e esse BD?
- Acelerei a minha produção ao criar um BD que não requer instalação separada e nenhuma configuração extra.
- Facilitei o backup. O DB cria uma arvore de subpastas dentro de uma pasta primária chamada "db", basta copiar essa pasta e o backup tá pronto.
- Poupei recursos da máquina.
- Facilitei o entendimento do projeto já que minha biblioteca dispensa o uso de classes "Repository". O uso consiste em simplesmente implementar "Ente" na minha classe. Isso já gera todos os métodos de CRUD e um identificador "EnteId" que é um número long que vai de -2^64 até 2^64... Ou seja, tem ID ai suficiente pra salvar o número de átomos no universo...
Agora, o problema... Qual grande empresa usaria isso nos pequenos projetos? Por isso eu prefiro trabalhar free lance. Gasto menos do meu juízo ganhando meu dinheiro do mesmo jeito.
28:00 Pelo que andei pesquisando o Alistair Cockburn não escreveu um livro sobre Arquitetura Hexagonal. Um dos livros mais famosos dele mesmo é esse da imagem "Escrevendo Casos de Uso Eficazes".
reduzir "If and Elses"
testar seus programas com atenção
reduzir os pages por meio de testes e reduções
organização e endentação
sempre deixar classes bem específicas
ou seja fazer pequenas bagunças e organiza-las
Essas duas feras da ficar horas só ouvindo muito bom.
Ficamos muito felizes com o seu comentário, Alexandre! Eles são demais mesmo 😁💙
Eu odeio o Akita, agora eu vou ter que reescrever meu codigo todo para outra pessoas entender, o que seriamos sem pessoas como o MESTRE Akita ...
Atualmente, estou imerso no programa ONE Oracle Next Education T6, uma colaboração entre a Oracle e a Alura. O curso me abriu a mente para o aprendizado de Lógica de Programação e a exploração dos fundamentos da programação com JavaScript. Além disso, destaco o meu interesse nesse vídeo sobre boas práticas de programação, o qual considerei bastante instrutivo e valioso.
#oraclenexteducation #alura #HelloONET6
dei like pela camiseta do akita kkk
O Akita muito bom porque ele domina tópico de ciência da computação. Acompanho ele desde 2019 fiquei impressionado como o vídeo dele o Hello World como você nunca viu. Dali em diante passei a acompanhar o canal dele
Muito bom. A única coisa que eu não concordo é sobre o aumento da capacidade de processamento vs utilização real. Hoje em dia os programadores se apoiam muito justamente nesse aumento exponencial das capacidades de processamento e armazenamento duas ordens de grandeza mais rápidos do que há dez anos atrás, a ponto de que, para um simples "hello world" em Node ou React necessita de um projeto com mais de 300 Mb e 250.000 arquivos! Instale duas ou três bibliotecas no projeto e esse número sobe para mais de trezentos mil arquivos. Além disso, o excesso de modularização, uso de ferramentas exclusivas para o ambiente DEV e a falta de teste de um sistema com um volume de dados próximos ao real, utilizando banco de dados em memória para testes, por exemplo, quando o ambiente final será com um banco real direto ou em micro-serviço externo, faz aparecerem umas operações bizarras que levam de minutos a horas para serem concluídas, excesso de carga no servidor, etc, exigindo a contratação de mais poder, claro, onde uma otimização nas consultas e técnicas de cache programática, quando apenas o cache do SGDB não é suficiente trariam para tempos mais aceitáveis.
Resumindo, discutir "sexo dos anjos" em sistemas pequenos ou que o ganho de desempenho seria ínfimo, realmente não importa, mas testar num ambiente QAS próximo ao de produção, com os bancos, volume de dados e conexões externas, isso é importante para revelar gargalos. Na área de front end, por exemplo, sempre bom testar o site que tenha muitas animações num computador bem inferior ao de desenvolvimento (a menos que o do dev já seja inferior 🤘🏾). Um banco que vá receber 10 milhões de registros, testar com 2/3 milhões no mínimo.
Tem muito norte-americano que abraça Design Patterns como Standards também. Vai além da tradução o problema. Gostaria de mencionar que existem também os "de-facto standards" que são confundidos como obrigações. Gostei muito da análise. Adicionaria ainda o fato que cada projeto pode criar seus próprios padrões.
Em 12:00; Quer dizer que codigos como PHP, Java Script, Phyton e etc, são codigos mais extensos porém mais acertivos, enquanto codigos como Java, C, etc, são compiladores porém mais passiveis de erros e uma legibilidade carente?
Me perdeu no "roda o teste" kkkk
E eu achando que "Patterns" era "Padrões" ... Meu Deus hahahahaa ... são repetições não necessariamente necessárias ... kkkk ... top demais ... Parabéns pelo conteúdo.
Super bem colocadas todas as observações. Só a experiência para tanto esclarecimento.
A regra é clara! Tem Akita tem Like
muito legal a discussão, acho que fugiu um pouco do tópico principal que são boas práticas de programação, nome de variáveis, funções ou métodos que façam aquilo que foram escritos pra fazer, módulos e classes pequenos que possam ser reutilizados, não ficar copiando e colando trecho de código ao invés disso modularizar o trecho, uso de interfaces e contratos ou um padrão de projeto poderia ser utilizado como exemplo o MVC é bem claro e poderia ser exemplificado também enfim, independente de poder de processamento as boas práticas podem ser aplicadas ainda mais pensando em times grandes que trabalham no mesmo código, uso de constantes e presar pela imutabilidade que ajuda muito a manter o código modular e coeso. uma vez eu vi um exemplo bacana que deram para esse tópico a função LS do Linux por exemplo foi escrita há mais de 4 décadas e nunca foi modificada pelo simples fato de ser extremamente simples e fazer o que foi proposto no caso listar um diretório.
Que video maravilhoso! Uma baita de uma aula.
Ficamos felizes que tenha gostado, Herberson! 💙 Se precisar de qualquer apoio ao longo da sua jornada, estamos aqui para te ajudar! 😉
Respondendo a pergunta "Que projeto hoje em dia que tem só uma pessoa" :
- Projetos de Firmware!
(Exemplo: Empresas pequenas de dispositivos IoT) .
Agora sim um formato mais palatável do programa. Sem ter que olhar pra camera os 2 ficam menos robóticos kkkk vou até me inscrever, assistiria 1h tranquilo
Eu tento manter meu código o mais organizado possível, tento usar o mínimo de comparação de variáveis com strings ou números soltos quando eu vejo que a comparação se repete em muitos lugares. Passei umas 6/7 semanas rafazendo o app que eu trabalho do zero porque inicialmente tive que fazer muito rápido pro produto sair rápido e chegou em um ponto que qualquer linha que eu adicionava 4/5 coisas diferentes quebravam. Aproveitei o produto no ar, li planejei, refatorei, mudei algumas ferramentas (comecei a usar TypeScript, por exemplo, que ajuda horrores) e hoje eu posso dizer que tenho orgulho do que tô fazendo, não que não tivesse antes, tava funcionando, mas só eu sei como (aliás, só a eu do dia que eu escrevi sabe como XD).
Eu já ouvi professores do RUclips dizendo que boas práticas são apenas burocracia e também já escutei muitos usuários usando o termo "Cagando regras" quando alguém ensina o certo.
Akita nunca entrega uma resposta pra nenhuma pergunta, percebi que ele só te da um contexto de qual a forma mais facil de você mesmo chegar até ela.
A experiência traz ponderação e bom senso.
Simplesmente sensacional o bate papo, com alto nível e muita clareza. Obrigado pelo conteúdo!
Esse ponto que ele disse sobre o linguição acontece demais no dia a dia. A gente desenvolve o código de uma maneira, e dois dias depois quando voltamos nele, nossa ótica já muda em relação a desempenho. Daí acabamos refatorando tudo pra termos uma melhor visibilidade quando voltarmos nele no futuro.
Primeirao! Estou platinando todo conteúdo de Java e Web Services da Alura!
Nossa que top !!! melhor conversa que já ouvi sobre o tema. Parabens !
Akitaaaaaaa foda demais!
var frodo = 'pé grande!' 🤣
Quando o código não funciona fica mais fácil dar nome kk. Quando o Akita engata um quinta ai fica bom de mais! Vlw pelo conteúdo e partiu estudar hein