Ler 50 linhas de código ou usar a refatoração Extract Method? - Insights de Derek Comartin

Exemplo: Cadastro de usuário em um sistema de bate-papo

No início do vídeo, Derek apresenta um exemplo: uma funcionalidade de inscrição para um sistema de chat. Trata-se de um bloco de código compacto, porém realista, com cerca de 50 linhas, que executa diversas tarefas:

• Verifica se o nome de usuário não está em branco

• Verifica se o nome de usuário já está em uso

• Gerencia canais com restrição de idade

• Salva o novo objeto de usuário

• Envia um e-mail com um link de ativação

Esse código reside em uma única função e, à primeira vista, pode parecer um ótimo candidato para refatoração por extração de método. Mas, como Derek alerta, refatorar cegamente sem entender o impacto pode, na verdade, prejudicar a clareza.

Começando com a refatoração: selecione Extrair método

Derek começa onde muitos desenvolvedores começam: dividindo o fragmento de código em partes menores. Ele mostra como selecionar "Extrair Método" através do menu de contexto ou de um atalho de teclado na maioria das IDEs ou editores de código.

Ele extrai:

• Valide o nome de usuário para verificar se ele não está em branco.

• existingSignUpNotActivated para verificar se há uma conta não ativada

• validateExistingUser para lidar com todas as verificações de usuários existentes

• filterAgeRestrictedChannels para processar canais destinados a usuários menores de 18 anos

• enviar e-mail para enviar o e-mail de boas-vindas

Ele atribui um nome significativo a cada nova função, o que é uma das principais dicas frequentemente promovidas nas práticas de código limpo. Mas, à medida que analisa essas versões modificadas, Derek começa a apontar as falhas na lógica — não na funcionalidade, mas na legibilidade e no fluxo de controle.

Problema 1: Detalhes ocultos de implementação

Um dos primeiros sinais de alerta que Derek destaca é que os detalhes de implementação agora estão ocultos por trás de métodos extraídos.

Por exemplo, os métodos validateUsername e validateExistingUser lançam exceções. Mas, como desenvolvedor lendo o código refatorado, você não teria ideia, a menos que tivesse acesso ao seu funcionamento interno.

Esse tipo de refatoração pode ocultar a lógica de controle, levando a erros ou falhas de validação. O escopo e o fluxo já não são óbvios. Em vez de tornar o código mais claro, você está criando um labirinto de abstrações onde efeitos colaterais como exceções ou variáveis ​​modificadas não são mais visíveis no formato em que a lógica foi originalmente escrita.

Edição 2: Indireção e Extrações Encadeadas

Em seguida, Derek destaca a questão da indireção — quando um método de extração chama outro, e assim por diante. Ele demonstra como o método validateExistingUser é composto, em si, por existingSignUpNotActivated.

Você não está mais lendo um bloco de código simples, de cima para baixo. Você fica alternando entre métodos, arquivos e classes apenas para rastrear o que acontece. E embora o editor possa ajudar a navegar por esse fluxo, isso se torna um fardo para a carga cognitiva do leitor.

Isso se torna ainda mais problemático em sistemas maiores, onde a refatoração abrange vários arquivos ou componentes. De repente, seu "código limpo" parece mais difícil de acompanhar do que as 50 linhas "bagunçadas" originais.

Questão 3: Variáveis ​​Locais e Estado Mutável

Uma das lições mais importantes deste vídeo vem do tratamento de variáveis ​​locais e da mutação de estado.

Derek destaca o método filterAgeRestrictedChannels. Não retorna um resultado — modifica diretamente a lista de canais que foi passada como parâmetro. Isso significa que você está modificando o estado local de dentro de um método diferente e, a menos que inspecione o método cuidadosamente, essa alteração ficará oculta.

Isso quebra a expectativa de que uma função seja uma operação pura ou que sinalize claramente quando está alterando algo. Ao substituir a lógica por um novo método que não retorna valores, mas os altera internamente, você está introduzindo riscos e confusão.

Alternativa Refatorada de Derek

Então, como Derek realmente refatora seu código antigo?

Ele propõe uma abordagem muito mais simples:

1. Mantenha a lógica autoexplicativa em linha. A verificação inicial de um nome de usuário vazio permanece no método principal, pois é fácil de entender e não sobrecarrega o código.

2. Retorne os resultados em vez de causar mutações. Em vez de modificar a lista de canais, a função filterAgeAppropriateChannels agora retorna uma lista filtrada. Isso torna o fluxo de dados mais claro e evita efeitos colaterais inesperados.

3. Utilize métodos de extração simples e previsíveis. O único outro método extraído é isExistingUserAlreadyActivated, que claramente retorna um valor booleano sem lançar exceções. Ela encapsula a lógica sem ocultar detalhes.

4. Evite efeitos colaterais embutidos, como o envio de e-mails. Derek mantém a lógica de e-mail para fins de demonstração, mas sugere que, em um sistema real, isso deveria ser tratado por meio de um evento em um processo ou thread separada — e não algo diretamente vinculado ao envio do formulário do usuário.

No total, Derek usa apenas dois métodos de extração e deixa o restante da lógica embutida — porque é mais fácil de ler, entender e controlar.

Dicas finais sobre refatoração de métodos de extração

O vídeo de Derek nos oferece algumas diretrizes práticas para usar a refatoração de extração de métodos de forma eficaz:

• Use nomes significativos que descrevam exatamente o que o método faz.

• Evite efeitos colaterais como mutação de estado ou lançamento de exceções, a menos que sejam óbvios.

• Retornar valores em vez de modificar os parâmetros de entrada.

• Não oculte a lógica por trás de múltiplas camadas de abstração.

• Se um método parecer legível em sua forma original, não o force a se tornar várias funções apenas para fins de refatoração.

Às vezes, a melhor abstração é nenhuma abstração — especialmente quando isso implica em perda de clareza e noção do escopo.

Conclusão

A abordagem de Derek Comartin questiona a noção de que a refatoração sempre melhora o código. No caso da refatoração de métodos de extração, menos costuma ser mais. Em vez de usar excessivamente o comando select Extract Method para fragmentar sua lógica, avalie o que agrega valor, o que torna seu código mais fácil de entender e o que oculta detalhes importantes.

Com exemplos claros e análises diretas de código do mundo real, Derek mostra em seu vídeo que, às vezes, 50 linhas em um único método, lidas de cima para baixo como uma história, são melhores do que dez métodos menores espalhados por toda a sua base de código.

Se você já recorreu a um atalho de teclado para criar um novo método, lembre-se do conselho de Derek: pause, avalie e certifique-se de que a refatoração seja útil para o leitor, e não apenas para a IDE.