Code review em PHP: o que verificar e como dar feedback

Introdução: por que code review não é sobre "encontrar bugs"

Code review (revisão de código) é uma das ferramentas mais eficazes para melhorar a qualidade de um produto de software. Na comunidade PHP, onde frequentemente encontramos legados de "código espaguete" e uma mistura de estilos procedural e OOP, uma revisão bem feita se torna especialmente importante. No entanto, muitos desenvolvedores a percebem como uma "caça a erros" ou, pior, como uma forma de se autoafirmar. Na verdade, o objetivo do code review é transmitir conhecimento, garantir a uniformidade da base de código e prevenir problemas potenciais antes que eles cheguem à produção.

Neste artigo, vamos analisar exatamente no que prestar atenção ao revisar código PHP e como dar feedback de forma que a equipe se fortaleça, em vez de se sentir ofendida.

1. O que verificar no código PHP: checklist do revisor

Para que a revisão seja sistemática e não caótica, use o seguinte checklist. Ele está dividido em categorias-chave.

1.1. Segurança (Security)

PHP é uma linguagem onde erros de segurança custam caro. Verifique:

• Injeção de SQL: consultas preparadas (PDO ou MySQLi) estão sendo usadas? Concatenação de strings em consultas é proibida.
• XSS (Cross-Site Scripting): toda saída do usuário é escapada com htmlspecialchars() ou template engines (Twig, Blade).
• Proteção CSRF: existem tokens nos formulários?
• Validação no servidor: não confie apenas na validação do lado do cliente.

<?php// RUIM: Injeção de SQL$query = "SELECT * FROM users WHERE id = " . $_GET['id'];

// BOM: PDO com prepared statement$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");$stmt->execute(['id' => $_GET['id']]);?>

1.2. Conformidade com os padrões PSR

O PHP-FIG (Framework Interop Group) desenvolveu padrões que a maioria dos projetos modernos segue. Verifique:

• PSR-12: indentação (4 espaços), chaves, nomenclatura (camelCase para métodos, snake_case para variáveis).
• PSR-4: autoloading de classes e namespaces.

Use ferramentas automáticas (PHP CodeSniffer, PHP-CS-Fixer) para não perder tempo com formatação manual.

1.3. Arquitetura e SOLID

Mesmo em um projeto pequeno, os princípios SOLID ajudam a evitar uma "grande bola de lama". Preste atenção a:

• Responsabilidade Única: um método/classe — uma tarefa. Se um método faz 3 coisas, é motivo para refatoração.
• Injeção de Dependência: não use new dentro de classes; passe as dependências pelo construtor.
• Ausência de "objetos divindade": uma classe não deve saber tudo sobre o sistema.

1.4. Performance

Não otimize prematuramente, mas antipadrões evidentes devem ser destacados:

• Consultas em loop (problema N+1).
• Uso de funções mysql_* (foram removidas no PHP 7+).
• Falta de índices no banco de dados para consultas frequentes.

2. Como dar feedback: a arte da crítica construtiva

Mesmo a lista de observações mais correta não trará benefício se o feedback soar como "este código é horrível, reescreva". Aqui estão algumas regras.

2.1. Regra do "sanduíche"

Comece com o positivo, depois a observação, depois o apoio.

• Positivo: "Ótimo uso de interfaces, o código ficou mais flexível."
• Observação: "Mas aqui há uma potencial vulnerabilidade XSS — vamos escapar a saída."
• Apoio: "No resto, a lógica está correta, após a correção pode fazer o merge."

2.2. Perguntas em vez de ordens

Em vez de "Faça de outro jeito", pergunte: "E se extrairmos essa lógica"