Revisão de código em PHP: 10 erros que irritam os seniores

Introdução: Por que seu código PHP é mandado reescrever?

Você enviou um Pull Request, cheio de confiança de que escreveu um código perfeito. Passa uma hora, e você vê 15 comentários de um desenvolvedor sênior. Familiar? Code review em PHP não é apenas uma formalidade, mas um verdadeiro exame de maturidade. Os seniores não veem o código como um conjunto de instruções, mas como um sistema que viverá e evoluirá.

Neste artigo, vamos analisar os comentários mais comuns que você recebe nas revisões. Não vamos ensinar sintaxe — você já sabe como declarar uma variável. Vamos falar sobre cultura de código, arquitetura e armadilhas que transformam código funcional em um pesadelo de manutenção. Prepare-se: vai doer, mas será útil.

1. Números e strings mágicos: "O que significa 42?"

O erro mais comum e mais irritante. Um sênior vê no código if ($status == 3) e já dá um ponto negativo. O número 3 é uma constante mágica. Em um mês, você mesmo não lembrará o que significa. E um novo desenvolvedor vai ficar imaginando: é o status "Publicado", "Rascunho" ou "Excluído"?

Ruim:

if ($order->getStatus() == 3) {\n    $order->sendNotification();\n}

Bom:

class OrderStatus {\n    const PENDING = 1;\n    const CONFIRMED = 2;\n    const SHIPPED = 3;\n    const DELIVERED = 4;\n}\n\nif ($order->getStatus() === OrderStatus::SHIPPED) {\n    $order->sendNotification();\n}

Usar constantes nomeadas torna o código autodocumentável. Você não está apenas escrevendo código — está contando uma história. Esta é uma das principais php best practices que os juniores frequentemente ignoram.

2. God-objects e monstros de 500 linhas

"Esta classe faz tudo!" — uma frase que faz qualquer sênior tremer. Quando uma única classe é responsável por enviar e-mail, gerar PDF e trabalhar com o banco de dados, isso viola o princípio da responsabilidade única (SRP). Essa classe é impossível de testar, difícil de modificar e certamente quebrará ao menor refatoramento.

Sinais de um God-object:

\n
• A classe tem mais de 200-300 linhas
\n
• O método tem mais de 20-30 linhas
\n
• O nome da classe termina com "Manager" ou "Helper"
\n
• Os métodos aceitam 5+ parâmetros
\n

A solução é simples: divida! Extraia a lógica para serviços, repositórios, handlers. A refatoração PHP começa com algo pequeno — crie uma classe que faz apenas uma coisa, mas a faz bem.

3. Trabalho "cru" com SQL via PDO

Sim, o PDO protege contra injeções se você usar prepared statements. Mas um sênior quer ver não SQL bruto no controller, mas uma abstração. ORMs como Eloquent ou Doctrine são o padrão. Se o projeto for pequeno, use pelo menos um Query Builder.

Antipadrão:

$pdo = new PDO('mysql:host=localhost;dbname=test', 'user', 'pass');\n$stmt = $pdo->prepare('SELECT * FROM users WHERE email = ?');\n$stmt->execute([$email]);\n$user = $stmt->fetch();

Abordagem correta:

class UserRepository {\n    public function findByEmail(string $email): ?User {\n        return User::where('email', $email)->first();\n    }\n}

Trabalhar através de um repositório permite trocar facilmente a fonte de dados (por exemplo, migrar para cache Redis) sem reescrever todo o projeto. Esta é a qualidade de código PHP que vale ouro.

4. Ignorar strict_types

PHP é uma linguagem de tipagem dinâmica, mas isso não é desculpa para escrever código como em 2005. Declarar declare(strict_types=1); no início de cada arquivo é um sinal de profissionalismo. Um sênior odeia quando uma função espera um int, mas recebe a string "42" e a converte silenciosamente.

declare(strict_types=1);\n\nfunction calculateTotal(int $price, int $quantity): int {\n    return $price * $quantity;\n}\n\n// Isso causará um TypeError, não uma conversão silenciosa\necho calculateTotal('100', 2); /