Executando verificação de segurança...
5
devtiagoabreu
3 min de leitura ·

😉 Bora Dar um "Up" no Código a Cada Check-in? A Regra de Ouro do Escoteiro Dev! 🏕️➡️🏡✨

Bora Dar um "Up" no Código a Cada Check-in? 😉 A Regra de Ouro do Escoteiro Dev! 🏕️➡️🏡✨

E aí, time TabNews! Suave? 🤙 Hoje a gente vai falar de uma parada simples, mas que transforma qualquer codebase num lugar mais agradável de se trabalhar: a Regra do Escoteiro aplicada ao código. 🪵➡️💎

Saca só, a ideia é a seguinte: assim como um bom escoteiro deixa o acampamento mais limpo do que encontrou, a gente, como dev, tem o dever de deixar o código um pouquinho melhor a cada vez que mexemos nele. 🤝

Parece besteira, né? Mas pensa comigo: imagina que você chega num código que parece um campo de batalha depois de uma guerra de branches (quem nunca? 😅). Se cada um que passou por ali tivesse feito só uma coisinha pra melhorar, a história seria outra, concorda? 🤔

Mas como botar essa regra em prática no dia a dia? 🤔 Não precisa ser nada mirabolante, viu? Pequenas ações já fazem uma diferença ENORME! 😉

Exemplos práticos pra você já começar a aplicar: 👇

  • Achou aquela variável com nome tipo "xpto"? 🏷️➡️✨ Que tal dar um nome mais descritivo que explique o que ela realmente faz? Tipo totalDeUsuariosAtivos em vez de tua. Bem melhor, né? 👍
  • Viu uma função que tá gigante, fazendo mil coisas ao mesmo tempo? ✂️➡️📦 Se der, quebra ela em funções menores, cada uma com uma responsabilidade clara. Facilita demais entender o fluxo! 👌
  • Rolou aquele "Ctrl+C Ctrl+V" maroto em algum lugar? 😬 Opa! 👀 Que tal extrair essa lógica repetida para uma função ou classe reutilizável? Código duplicado é igual a dor de cabeça em dobro no futuro! 🤕➡️😌
  • Tem um if aninhado que parece um labirinto? maze➡️🗺️ Se puder, simplifica essa lógica, usa um return antecipado ou extrai condições para variáveis com nomes claros. Sua sanidade agradece! 😄
  • A formatação tá daquele jeito, cada um com sua indentação? 😵‍💫 Que tal dar uma ajeitada na formatação pra deixar tudo mais consistente e fácil de ler? Uma IDE configurada com um formatter ajuda muito nessa! ✨

A moral da história? 🚀

Não precisa chegar e refatorar o sistema inteiro de uma vez (a não ser que a situação esteja crítica mesmo! 😅). Mas a cada tarefa, a cada bugfix, a cada nova feature, reserve um tempinho pra deixar aquela parte do código um pouquinho melhor. É tipo arrumar a sua mesa antes de ir embora: no dia seguinte, tudo fica mais organizado pra você e para quem mais for usar. 🏡

Seguindo essa Regra do Escoteiro do Código, a gente garante que nosso projeto se mantenha limpo 🧼, organizado 📚 e fácil de manter 🛠️ a longo prazo. E o melhor de tudo: evita aquela sensação de "quem deixou essa bagunça aqui?!" quando a gente volta pra um código antigo. 😂

E aí, curtiu a ideia? Bora aplicar essa regra e deixar nossos códigos brilhando! ✨ E você, qual a menor melhoria que você já fez no código que fez uma grande diferença? Compartilha com a gente nos comentários! 👇

Fonte: https://open.spotify.com/show/2XWWtGYoi8jdzSUX2ncq3g?si=L9lTp-ctSwaFNqN0KzlF8A

Carregando publicação patrocinada...
5
felprangel

Esse é um conceito que sempre me deixou com uma pulga atrás da orelha. Uncle Bob cita isso em mais de um livro, e não consigo me imaginar fazendo isso num código da empresa em que trabalho.

Pense o seguinte cenário, peguei uma tarefa grande, que no final das contas vai dar uns 30 arquivos alterados no PR, se eu aplicar esse conceito de melhorar alguma coisinha sempre que eu puder, a tarefa dobra de tamanho e fica muito mais coisa pra quem for revisar.

Pode ser uma má interpretação minha, mas como fica pra resolver esse problema?

3
devtiagoabreu
Autor
Autor

Fala, @felprangel! 🤙

Massa demais esse ponto que você trouxe! E faz total sentido. Se toda PR já vem daquele jeito, cheia de mudanças, sair melhorando tudo no caminho pode transformar o code review num verdadeiro modo hardcore. 😅

Mas a parada da Regra do Escoteiro não é sair refatorando geral sempre que der na telha (até porque aí vira "Refactor Driven Development" 😂). O ideal é ir na manha, aplicando melhorias pequenas e cirúrgicas que não impactem demais a PR. Tipo:

🔹 Ajustar um nome de variável que estava gritante de ruim.
🔹 Simplificar um if caótico, mas sem mudar toda a lógica do fluxo.
🔹 Extrair um método quando fica óbvio que algo pode ser reutilizado.

Agora, se a gente trombar com um monstro de espaguete, a real é que talvez seja melhor abrir um tech debt separado e discutir com o time. Senão, o PR vira um "refatora tudo e mais um pouco", e aí complica mesmo. 😆

Resumindo: pequenos passos, grandes impactos no longo prazo. Não precisa dobrar o tamanho da tarefa, só dar aquela ajeitada onde der sem complicar. 🚀

O que acha? Curtiu essa abordagem? 😃

4