Code Review em PHP: o que um sênior diz e como não passar vergonha

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

Você escreveu o código. Ele funciona. Você está orgulhoso. Mas chega o code review, e o desenvolvedor sênior deixa 15 comentários, metade começando com "E se..." ou "Vamos reescrever isso usando...". Familiar?

O code review em PHP não é sobre implicância. É sobre a sobrevivência do projeto. Seniors não olham apenas para "funciona/não funciona", mas sim como o código se comportará sob carga, como outro desenvolvedor o manterá e quanto tempo você gastará caçando um bug daqui a seis meses.

Neste artigo, vamos analisar os comentários mais frequentes que você ouvirá em um code review de um desenvolvedor PHP experiente. Mostrarei exemplos reais de código e explicarei como corrigi-los. Após a leitura, você conseguirá antecipar 80% dos comentários e escrever um código que não dá vergonha de mostrar.

1. "Números mágicos" e strings: o código deve falar por si

A primeira coisa que um sênior notará são números e strings sem sentido espalhados pelo código. Números mágicos são um antipadrão que destrói a legibilidade.

Exemplo ruim

if ($user->getAge() > 18) {\n    $discount = $price * 0.1;\n}

O que o sênior dirá?

\n
• Por que exatamente 18? É a maioridade ou o limite para desconto?
\n
• Por que 0.1? São 10%? E se o desconto mudar?
\n

Exemplo bom

const ADULT_AGE = 18;\nconst DISCOUNT_RATE = 0.1; // 10%\n\nif ($user->getAge() > ADULT_AGE) {\n    $discount = $price * DISCOUNT_RATE;\n}

Agora o código conta a história sozinho. O sênior aprovará: constantes podem ser reutilizadas, alteradas em um só lugar e não exigem comentários.

2. Falta de tipos: PHP 8 não é desculpa para tipagem dinâmica

PHP é uma linguagem de tipagem fraca, mas isso não significa que você deve escrever como em 2005. Tipagem estrita salva de bugs difíceis de detectar.

Exemplo ruim

function calculateTotal($items, $tax) {\n    $total = 0;\n    foreach ($items as $item) {\n        $total += $item['price'] * $item['quantity'];\n    }\n    return $total * (1 + $tax);\n}

Comentários do sênior

\n
• O que é $items? Um array? Um objeto? Uma coleção?
\n
• Qual a estrutura do elemento? Por que não usar um DTO?
\n
• E se $tax for passada como string "0.2"? Vai concatenar?
\n

Exemplo bom

declare(strict_types=1);\n\nclass OrderItem {\n    public function __construct(\n        public readonly float $price,\n        public readonly int $quantity\n    ) {}\n}\n\nfunction calculateTotal(array $items, float $taxRate): float {\n    $total = 0.0;\n    foreach ($items as $item) {\n        if (!$item instanceof OrderItem) {\n            throw new InvalidArgumentException('Expected OrderItem');\n        }\n        $total += $item->price * $item->quantity;\n    }\n    return $total * (1 + $taxRate);\n}

O sênior dirá: "Mandou bem, usando DTO, propriedades readonly e tipagem estrita. Código previsível." Isso é boas práticas PHP 8+.

3. Aninhamentos profundos e Early Return

Quando você vê 5 níveis de if...else dentro de um único método, o sênior segura a cabeça. Esse código é impossível de ler, testar e debugar.

Exemplo ruim

public function processOrder($order) {\n    if ($order->isPaid()) {\n        if ($order->hasStock()) {\n            if ($order->isShippable()) {\n                // 50 linhas de lógica\n                return $this->ship($order);\n            } else {\n                throw new \\Exception('Order cannot be shipped');\n            }\n        } else {\n            throw new \\Exception('Out of stock');\n        }\n    } else {\n        throw new \\Exception('Order not paid');\n    }\