Code review em PHP: o que verificar e como dar feedback na prática

Introdução: por que code review não é sobre controle, mas sobre crescimento

Code review (revisão de código) em PHP não é um procedimento arcaico de controle do chefe sobre o subordinado. É um diálogo profissional entre desenvolvedores, visando melhorar a qualidade do código, disseminar conhecimento dentro da equipe e prevenir erros em estágios iniciais. No entanto, como a prática mostra, muitos desenvolvedores PHP (especialmente no início) ou temem a revisão, ou a transformam em uma formalidade vazia.

Neste artigo, vamos abordar exatamente o que observar ao fazer code review de código PHP, como formular observações para não ofender um colega e como extrair o máximo de benefício desse processo. O material é baseado em experiência real com projetos em PHP 7.4+ e frameworks como Laravel e Symfony.

1. O que verificar no código PHP: um checklist prático

Não existe uma lista universal, mas para projetos PHP podemos destacar 5 áreas-chave que devem ser analisadas sob a ótica da revisão.

1.1. Segurança (Security)

PHP é uma linguagem onde é fácil introduzir vulnerabilidades. Primeiramente, verificamos:

\n
• Injeção SQL: consultas preparadas (PDO / prepared statements) estão sendo usadas em vez de concatenação de strings?
\n
• XSS (Cross-Site Scripting): a saída é escapada com htmlspecialchars() ou templates (Blade, Twig)?
\n
• Proteção CSRF: existem tokens em formulários que alteram o estado?
\n
• Validação de entrada: o tipo e o comprimento dos dados são verificados no lado do servidor?
\n

// Ruim: concatenação em SQL\n$query = "SELECT * FROM users WHERE id = " . $_GET['id'];\n\n// Bom: consulta preparada com PDO\n$stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');\n$stmt->execute(['id' => $_GET['id']]);\n

1.2. Arquitetura e SOLID

Mesmo que o projeto não seja enterprise, os princípios básicos devem ser seguidos:

\n
• Responsabilidade única: a classe/método não está fazendo demais?
\n
• Inversão de dependência: o código usa interfaces em vez de classes concretas?
\n
• Ausência de objetos divinos: não há classes com mais de 1000 linhas?
\n

1.3. Estilo e padrões PSR

Para PHP, isso é crítico. Verificamos a conformidade com PSR-12 (estilo de codificação):

\n
• Indentação — 4 espaços, não tabulação.
\n
• Chaves em nova linha para classes e métodos.
\n
• Nomenclatura correta: camelCase para métodos, snake_case para variáveis (a menos que o projeto adote outra convenção).
\n

1.4. Performance

Em PHP, é fácil escrever código lento. Procuramos:

\n
• Consultas em loop (problema N+1) — em vez disso, use carregamento antecipado (Eager Loading) na ORM.
\n
• Ignorar cache: recálculos repetidos dos mesmos dados.
\n
• Funções ineficientes: por exemplo, in_array() em um array grande é melhor substituído por isset($hash[$key]).
\n

// Ruim: consulta em loop\nforeach ($users as $user) {\n    $posts = DB::table('posts')->where('user_id', $user->id)->get();\n}\n\n// Bom: uma única consulta com carregamento antecipado\n$users = User::with('posts')->get();\n

1.5. Tratamento de erros e tipagem

\n
• Existe strict_types no início do arquivo?
\n
• Tipos são usados para argumentos e valores de retorno?
\n
• As exceções são tratadas, e não silenciadas com um try-catch vazio?
\n

2. Como dar feedback: de "isso é ruim" para "vamos melhorar"

A habilidade mais difícil no code review não é encontrar um erro, mas apresentá-lo corretamente. Feedback ruim mata a motivação. Feedback bom ensina e aproxima a equipe.

2.1. A regra do "Sanduíche"

Recheio