Princípios de programação que ninguém te ensinou

PortuguêsالعربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia日本語한국어Русский中文
TThe Coding Koala
Computing/SoftwareManagement

Transcript

00:00:00Você sabe por que algumas pessoas parecem nunca evoluir como desenvolvedores, mesmo depois de anos
00:00:04nesta área? Existem vários fatores envolvidos. E um desses motivos é não entender
00:00:09os princípios fundamentais da programação. Esses não são apenas conceitos teóricos que você aprende uma vez
00:00:14e esquece. É o material de verdade que realmente fará você crescer mais rápido como desenvolvedor.
00:00:19Vamos começar com o primeiro princípio: a regra do escoteiro. Este princípio vem dos escoteiros nos EUA.
00:00:25Basicamente, eles têm uma regra simples: deixe o acampamento mais limpo do que o encontrou.
00:00:31Não sei quantos de vocês conhecem o Uncle Bob, mas foi ele quem popularizou esse conceito
00:00:36na comunidade de programação, que é a prática de deixar o código um pouco mais limpo do que você o encontrou.
00:00:41Ao fazer alterações em uma base de código existente, a qualidade do código frequentemente se degrada, o que pode
00:00:47aumentar a dívida técnica. E a dívida técnica pode ser reduzida com melhoria contínua,
00:00:52não importa o quão pequena seja. Suponha, por exemplo, que você foi designado para fazer uma alteração no
00:00:57valor nesta função. Você fez, mas percebe que o nome da variável não é compreensível
00:01:03o suficiente. Então, como a maioria dos desenvolvedores, você poderia simplesmente ignorar e fazer o commit do que lhe foi pedido.
00:01:08Mas se você seguir esse princípio, você também mudaria o nome da variável para algo mais
00:01:12compreensível. Este é apenas um exemplo simples; não se trata apenas de nomes de variáveis, mas se você vir algo que
00:01:18pode ser melhorado, apenas faça. E esse gesto simples será muito valioso para a base de código.
00:01:24Segundo princípio: evite a otimização prematura. O que isso significa é: não tente tornar seu
00:01:30código mais rápido antes que ele realmente precise ser rápido. Primeiro, faça funcionar. Só depois, otimize se necessário.
00:01:36Há uma citação famosa de Donald Knuth: "A otimização prematura é a raiz de todos os males",
00:01:42o que é verdade, porque os programadores frequentemente desperdiçam a maior parte do tempo preocupados com a velocidade de
00:01:47partes não críticas de seus programas. Isso acontece porque existe esse conceito de
00:01:51otimizar tudo. Este princípio não é contra otimizar sua base de código. É sobre
00:01:57entender o que precisa ser otimizado e, o mais importante, quando otimizar. E eu acho que este
00:02:03é o ponto fraco da maioria dos desenvolvedores, pois já vi pessoas usando microsserviços mesmo tendo
00:02:08100 usuários, ou adicionando cache para algo que nem é necessário. Terceiro princípio:
00:02:14escreva código para o mantenedor, o que significa simplesmente que, ao escrever código, você deve fazê-lo de uma
00:02:19forma que os futuros desenvolvedores que farão a manutenção não tenham dificuldades em gerenciar e
00:02:23entender o que foi feito. Isso porque o código que você escreve hoje será mantido por outros desenvolvedores ou por
00:02:29você mesmo. Se você focar apenas em fazer funcionar e não focar na clareza, no futuro, se
00:02:35precisar voltar ao código, terá dificuldade em entender o que está acontecendo. Veja
00:02:39este exemplo. Ambos funcionam e têm exatamente a mesma funcionalidade. Mas qual você preferiria
00:02:45ver na sua base de código? Então, a conclusão é: sempre que você escrever ou gerar código com IA,
00:02:50certifique-se sempre de que ele seja fácil de entender e sustentável antes de realizar o commit do seu trabalho.
00:02:55Nosso quarto princípio é o YAGNI, que é uma abreviação para "you aren't going to need it" (você não vai precisar disso).
00:03:01Este princípio simplesmente significa que você não deve construir algo de que não precisa realmente, ou apenas porque
00:03:06talvez precise no futuro. Porque a maioria dos desenvolvedores tem o hábito de prever o que
00:03:10podem precisar no futuro. Mas, na maioria das vezes, isso nunca será usado e apenas adiciona complexidade
00:03:16extra ao projeto. Lembre-se sempre disto: se você está trabalhando em algo que talvez precise no
00:03:21futuro, você não está dedicando seu tempo ao que precisa atualmente. Quinto princípio: faça a coisa
00:03:27mais simples que poderia funcionar. O que isso significa é que, sempre que enfrentar um problema, escolha sempre a
00:03:32solução mais simples que realmente funcione. Não pense demais. Não crie engenharia excessiva. Apenas pergunte
00:03:38a si mesmo: qual é a coisa mais simples que poderia resolver isso agora? Essa ideia vem da programação
00:03:43extrema (Extreme Programming), que nos diz para construir algo simples primeiro e depois refatorar para algo
00:03:48melhor. A maioria dos desenvolvedores não percebe, mas frequentemente tentam construir a solução perfeita desde
00:03:53o início, o que acaba complicando excessivamente a solução. Com este princípio, você obtém um código que funciona
00:03:59mais cedo e, mesmo que precise mudar depois, geralmente é mais fácil do que consertar um design complexo
00:04:04que estava errado desde o princípio. E acredite em mim, como desenvolvedor, perceber quando você está criando engenharia excessiva
00:04:10é muito importante. Então, esses foram os cinco princípios de programação que você deve começar
00:04:14a implementar imediatamente. Além desses, existem também outros princípios que não cobri
00:04:19neste vídeo. Se isso foi útil, me avise nos comentários e farei uma segunda parte.
00:04:24Por enquanto, é isso. Certifique-se de deixar seu apoio e vejo vocês no próximo vídeo.

Key Takeaway

O crescimento rápido como desenvolvedor depende da aplicação de princípios como a Regra do Escoteiro e o YAGNI para reduzir dívida técnica e evitar a engenharia excessiva.

Highlights

  • A Regra do Escoteiro estabelece que o código deve ser deixado um pouco mais limpo do que foi encontrado a cada modificação.

  • A otimização prematura, definida como o esforço em aumentar a velocidade antes da necessidade real, consome tempo em partes não críticas do programa.

  • O código deve priorizar a clareza para facilitar a manutenção por futuros desenvolvedores.

  • O princípio YAGNI (You Aren't Going To Need It) previne a adição de complexidade desnecessária baseada em previsões de necessidades futuras.

  • A Programação Extrema recomenda a implementação da solução mais simples que funcione para permitir refatoração posterior em vez de buscar a perfeição inicial.

Timeline

A Regra do Escoteiro e a Melhoria Contínua

  • A base de código degrada naturalmente após cada alteração.
  • A melhoria contínua, mesmo que pequena, reduz a dívida técnica acumulada.
  • Renomear variáveis confusas durante tarefas simples exemplifica a aplicação prática desta regra.

Baseada na premissa dos escoteiros de deixar o acampamento melhor do que o encontraram, esta prática foca na limpeza progressiva do código. Quando um desenvolvedor identifica algo passível de melhoria, como a clareza de um nome de variável enquanto realiza outra tarefa, a alteração deve ser feita imediatamente. Ignorar essas melhorias contribui para o aumento da dívida técnica a longo prazo.

Evitando a Otimização Prematura

  • A otimização prematura é a raiz de diversos problemas de desenvolvimento.
  • A velocidade de execução só deve ser tratada após o código estar funcional.
  • Arquiteturas complexas como microsserviços ou caches são indevidas para sistemas de pequena escala, como os com apenas 100 usuários.

Programadores desperdiçam tempo precioso tentando tornar o código rápido antes mesmo de ele cumprir sua função básica. A prioridade deve ser o funcionamento correto, deixando a otimização para quando for estritamente necessária. O erro comum reside na implementação de estruturas complexas que não agregam valor ao estado atual do projeto.

Manutenibilidade e o princípio YAGNI

  • O código escrito hoje será mantido por outros no futuro.
  • A clareza do código é o fator determinante para a facilidade de futuras manutenções.
  • O princípio YAGNI evita a criação de funcionalidades baseadas em previsões futuras que raramente se concretizam.

Ao escrever código, a facilidade de leitura é crucial para que futuros mantenedores compreendam a lógica implementada. O hábito de prever necessidades futuras apenas adiciona complexidade desnecessária ao projeto. Focar apenas no que é essencial agora maximiza a eficiência do tempo de desenvolvimento.

Simplicidade e Engenharia Excessiva

  • A Programação Extrema preconiza a construção da solução mais simples funcional primeiro.
  • A tentativa de construir a solução perfeita desde o início resulta em designs excessivamente complexos e incorretos.
  • Refatorar uma solução simples é mais produtivo do que corrigir um design complexo e falho desde a base.

A engenharia excessiva é um obstáculo comum, surgindo da tentativa de criar soluções perfeitas antecipadamente. Optar pela solução mais simples que resolve o problema imediato permite obter resultados mais rápidos e facilita mudanças futuras. Identificar o momento em que ocorre a engenharia excessiva é essencial para a evolução do desenvolvedor.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video