Refatoração de Código PHP: Quando Fazer e Como Evitar Erros

Refatoração de Código PHP: Quando Fazer e Como Evitar Erros

Todo desenvolvedor PHP, mais cedo ou mais tarde, se depara com um código que dá vontade de reescrever. Projetos legados em PHP estão cheios de "números mágicos" (magic numbers), funções que ocupam a tela inteira e classes que fazem de tudo. A tentação de organizar tudo é grande. Mas será que vale a pena? E se sim, como fazer a refatoração de código PHP de forma segura e eficiente?

Neste artigo, vamos analisar quando a refatoração é realmente necessária e quando é melhor deixar tudo como está. Você verá exemplos reais de código ruim e bom em PHP, receberá um checklist de ações e entenderá como não transformar a melhoria do código em um desastre.

Quando a Refatoração de Código PHP é Justificada?

Refatoração é a alteração da estrutura interna do código sem modificar seu comportamento externo. Parece simples, mas na prática é uma das tarefas mais arriscadas no desenvolvimento. Aqui estão os sinais de que é hora de pensar em melhorar o código PHP:

\n
• O código "fede" (code smells). Métodos longos, duplicação, classes-deus (God objects), nomes de variáveis incompreensíveis.
\n
• Adicionar novas funcionalidades se torna um tormento. Se cada pull request quebra três outros lugares, é um sinal de alerta.
\n
• Você não entende o que um método faz uma semana depois de escrevê-lo. Código ruim é aquele que exige comentários em cada linha.
\n
• O princípio da responsabilidade única (SRP) é violado. Uma classe UserManager que cria usuários, envia e-mails e gera relatórios é um candidato clássico para refatoração.
\n

Mas existem situações em que a refatoração de código PHP pode ser prejudicial:

\n
• O prazo é amanhã e o código funciona.
\n
• Não há testes. Sem eles, qualquer alteração é um jogo de roleta-russa.
\n
• O código foi escrito "nas coxas" para um protótipo que será descartado amanhã.
\n

Regras para uma Refatoração Segura

Antes de começar a refatorar código PHP, lembre-se de três regras de ouro:

\n
1. Cubra o código com testes. Pelo menos testes de integração. Se não houver testes, escreva-os para as partes críticas.
\n
2. Refatore em pequenos passos. Um método de cada vez. Commit, teste, e siga em frente.
\n
3. Não misture refatoração com adição de funcionalidades. São duas tarefas diferentes. Faça-as em commits separados.
\n

Exemplos de Refatoração de Código PHP: Do Ruim ao Bom

Vamos ver exemplos reais. Suponha que temos uma função para calcular descontos. Veja como ela é em um projeto legado típico:

Antes da Refatoração (Código Ruim)

function calculateDiscount($user, $order) {\n    $discount = 0;\n    if ($user->isVip()) {\n        $discount = 10;\n        if ($order->getTotal() > 1000) {\n            $discount = 15;\n        }\n    }\n    if (date('Y-m-d') == '2025-12-31') {\n        $discount = $discount + 5;\n    }\n    if ($order->getItemsCount() > 5) {\n        $discount = $discount + 3;\n    }\n    return $discount;\n}

Problemas: datas mágicas, números constantes, mistura de lógicas (usuário, pedido, data). Se uma nova promoção surgir amanhã, a função ficará ainda maior.

Após a Refatoração PHP (Código Bom)

class DiscountCalculator {\n    private const NEW_YEAR_DATE = '2025-12-31';\n    \n    public function calculate(User $user, Order $order): int {\n        $discount = $this->getBaseDiscount($user) \n                  + $this->getHolidayBonus() \n                  + $this->getVolumeBonus($order);\n        \n        return min($discount, 50); // no máximo 50%\n    }\n    \n    private function getBaseDiscount(User $user): int {\n        if ($user->isVip() && $user->getTotalSpent() > 1000) {\n            return 15;\n        }\n        return $user->isVip() ? 10 : 0;\n    }\n    \n    private function getHolidayBonus(): int {\n        retu