Boa refatoração vs. má refatoração

• A refatoração de código desempenha um papel importante para manter a saúde da base de código
• Porém, uma refatoração mal feita pode acabar tornando o código mais complexo e mais difícil de manter
• É preciso saber distinguir boa refatoração de má refatoração e como evitar as armadilhas da refatoração ruim

O bom, o ruim e o feio da refatoração

• Abstração pode ser algo bom ou ruim. O ponto-chave é saber quando e como aplicá-la
• Explica algumas armadilhas comuns e como evitá-las (o código do texto original foi omitido)

1. Mudar significativamente o estilo de código

• Desenvolvedores frequentemente cometem o erro de mudar completamente o estilo de código durante uma refatoração
• Introduzir novas bibliotecas ou adotar um estilo de código totalmente diferente pode prejudicar a manutenção
• É melhor melhorar o código para que ele fique mais idiomático e legível, sem introduzir um paradigma totalmente novo ou dependências externas

2. Abstração desnecessária

• Adicionar abstrações novas em excesso sem entender o código existente é um problema
• Isso pode apenas aumentar a complexidade e dificultar a compreensão
• É melhor separar a lógica em funções pequenas e reutilizáveis, sem introduzir complexidade desnecessária

3. Adicionar inconsistência

• Atualizar apenas uma parte da base de código para funcionar de maneira totalmente diferente pode causar confusão e frustração
• Se for necessário introduzir um novo padrão, é melhor buscar primeiro o acordo da equipe
• É importante manter uma abordagem consistente para obtenção de dados em toda a aplicação

4. Não entender o código antes de refatorar

• Aprender o código ao mesmo tempo em que se faz a refatoração não é uma boa ideia
• Isso pode criar bugs, degradar o desempenho e remover funcionalidades
• Antes de refatorar, é importante entender profundamente o código e melhorá-lo preservando o comportamento existente

5. Entender o contexto de negócio

• Fazer escolhas técnicas sem entender o negócio pode ser desastroso
• No caso de um site de e-commerce que depende fortemente de SEO, renderização no lado do cliente pode ser uma escolha ruim
• Abordagens de renderização no lado do servidor, como Next.js ou Remix, podem ser escolhas melhores em termos de SEO e desempenho

6. Consolidar código em excesso

• Não é bom consolidar código para deixá-lo "limpo" às custas da flexibilidade
• Ao abstrair, sempre é preciso considerar os casos de uso atendidos
• A abstração deve permitir todas as funcionalidades que a implementação original oferecia

Refatorando da maneira certa

• Refatorar código é necessário. Mas isso precisa ser feito da maneira certa
• Nosso código não é perfeito e precisa de organização, mas é preciso manter consistência com a base de código existente
• É preciso refatorar depois de entender bem o código, e as abstrações devem ser escolhidas com cuidado
• Dicas para uma refatoração bem-sucedida:
  • Avance de forma incremental: faça mudanças pequenas e gerenciáveis em vez de uma reescrita total
  • Entenda profundamente o código antes de introduzir refatorações importantes ou novas abstrações
  • Combine com o estilo de código existente: consistência é essencial para manutenção
  • Evite introduzir abstrações novas demais: mantenha a simplicidade, a menos que a complexidade seja realmente necessária
  • Evite adicionar novas bibliotecas com um estilo de programação muito diferente, especialmente sem o acordo da equipe
  • Escreva testes antes da refatoração e atualize os testes ao longo do processo. Isso ajuda a verificar se a funcionalidade original está sendo mantida
  • Colegas devem responsabilizar uns aos outros por seguir esses princípios

Ferramentas e técnicas para uma refatoração melhor

• Para melhorar a refatoração, considere usar as seguintes técnicas e ferramentas:

Ferramentas de linting

• Use ferramentas de linting para aplicar um estilo de código consistente e encontrar problemas potenciais
• Com Prettier, é possível fazer formatação automática em um estilo consistente
• Com Eslint, é possível realizar verificações de consistência mais detalhadas por meio de plugins personalizados

Code review

• Implemente code reviews rigorosos para receber feedback dos colegas antes de fazer merge do código refatorado
• Isso ajuda a identificar problemas potenciais cedo e a garantir que o código refatorado esteja alinhado aos padrões e expectativas da equipe

Testes

• Escreva e execute testes para garantir que o código refatorado não quebre a funcionalidade existente
• Vitest é um test runner especialmente rápido, robusto e fácil de usar, sem exigir configuração por padrão
• Considere usar Storybook para testes visuais
• React Testing Library é um bom conjunto de utilitários para testar componentes React (também há variantes para Angular e outros)

Ferramentas de IA (apropriadas)

• Apoie os esforços de refatoração com ferramentas de IA capazes de se adaptar ao estilo e às regras de código existentes
• Visual Copilot é uma ferramenta especialmente útil para manter a consistência ao escrever código frontend
  • Ela ajuda a converter design em código, combinando com o estilo de código existente e usando corretamente componentes e tokens do sistema de design

Conclusão

• Refatoração é uma parte necessária do desenvolvimento de software, mas deve ser feita com cuidado e considerando a base de código existente e a dinâmica da equipe
• O objetivo da refatoração é melhorar a estrutura interna do código sem mudar seu comportamento externo
• As melhores refatorações muitas vezes são invisíveis para o usuário final, mas tornam a vida do desenvolvedor muito mais fácil
• Elas melhoram legibilidade, manutenibilidade e eficiência, sem transformar o sistema inteiro em uma bagunça
• Quando você quiser fazer um "grande plano" para o código, dê um passo atrás, entenda o código a fundo, considere o impacto das mudanças e faça melhorias incrementais que a equipe possa apreciar
• Seu eu do futuro e seus colegas vão agradecer por uma abordagem cuidadosa para manter a base de código limpa e sustentável

[toaonly]

Às vezes também tem gente que já sai refatorando sem nem ter código de teste antes.
Quando vejo isso, parece que a pessoa está fazendo uma corda bamba perigosíssima, dá até um frio na barriga haha

[ahwjdekf]

O ponto 4, "não entender o código antes de refatorar", realmente me marcou bastante.

[bichi]

É uma fala muito óbvia, quase como algo básico mesmo rsrs. Ficou legal do jeito que foi organizado. Acho que, quando se faz refatoração, 100% das vezes sai um código melhor. Se não for assim, não quer dizer que minha habilidade piorou em relação a ontem?

Vendo esse resumo do óbvio, parece um texto escrito porque alguém fez uma bagunça monumental e isso realmente deixou a pessoa muito irritada kkkkk

[kandk]

Mais do que como refatorar bem, é sobre como programar bem na prática no trabalho..
(Parece um texto escrito de raiva porque um júnior apareceu dizendo que ia refatorar um projeto legado, complicou tudo aqui e ali e ainda criou bugs...)

[savvykang]

Quem não consegue distinguir ou acaba confundindo a unidade do trabalho com a unidade do código tende a fazer esse tipo de refatoração, independentemente de ter mais ou menos experiência. No fim, um código fácil de corrigir e de manter só atende de verdade a esse objetivo quando outra pessoa consegue chegar depois e entender o fluxo do negócio; às vezes até dá a impressão de que isso é algo que só se aprende quando se vivencia o trabalho real no dia a dia.

[savvykang]

Já passei por um caso que me pareceu um sinal de abstração excessiva em React: mesmo com o componente de tabela já abstraído pelo framework de UI, se os esquemas de duas tabelas parecem semelhantes, acho que se deve evitar usar inversão de controle para criar um novo componente que não tem função real nenhuma. Quando vi casos em que, em nome de aplicar Atomic Design, saíam criando aos montes componentes “vazios” de dez linhas, achei muito incômodo, porque era preciso olhar várias partes diferentes.

A ideia da regra DRY era não sair copiando e colando código exatamente igual, com o mesmo formato e a mesma função, mas parece inevitável que sempre apareçam pessoas que entendem isso da forma errada. Será que a recomendação de não idolatrar padrões de design vem desse contexto?