PHP 代码审查：检查什么以及如何提供反馈

引言：为什么代码审查不只是"找Bug"

代码审查是提升软件产品质量最有效的工具之一。在PHP社区中，遗留的"意大利面条式代码"以及过程式与面向对象风格混杂的情况很常见，此时有水平的审查就显得尤为重要。然而，许多开发者将其视为"抓虫行动"，更糟的是，把它当作彰显自我的方式。实际上，代码审查的目标是知识传递、确保代码库一致性，并在潜在问题进入生产环境之前将其预防。

在本文中，我们将详细解析审查PHP代码时具体需要关注什么，以及如何提出反馈，既能增强团队力量，又不会冒犯他人。

1. PHP代码审查清单：审查者该查什么

为了使审查系统化而非杂乱无章，请使用以下清单。它按关键类别进行了划分。

1.1. 安全性

PHP是一种安全失误代价高昂的语言。检查以下内容：

• SQL注入：是否使用了预处理语句（PDO或MySQLi）？严禁在查询中使用字符串拼接。
• 跨站脚本攻击（XSS）：是否使用htmlspecialchars()或模板引擎（Twig、Blade）对所有用户输出进行了转义？
• 跨站请求伪造（CSRF）保护：表单中是否包含令牌？
• 服务器端验证：不能仅依赖客户端验证。

<?php// 错误做法：SQL注入$query = "SELECT * FROM users WHERE id = " . $_GET['id'];

// 正确做法：使用PDO预处理语句$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");$stmt->execute(['id' => $_GET['id']]);?>

1.2. 遵循PSR标准

PHP-FIG（框架互操作小组）制定了大多数现代项目遵循的标准。检查以下内容：

• PSR-12：缩进（4个空格）、花括号、命名规范（方法使用camelCase，变量使用snake_case）。
• PSR-4：类的自动加载与命名空间。

使用自动化工具（PHP CodeSniffer、PHP-CS-Fixer）以避免在手动格式化上浪费时间。

1.3. 架构与SOLID原则

即使在小项目中，SOLID原则也有助于避免"大泥球"架构。注意以下几点：

• 单一职责：一个方法/类——一个任务。如果一个方法做了三件事，这就是重构的理由。
• 依赖注入：不要在类内部使用new；通过构造函数传递依赖。
• 避免"上帝对象"：一个类不应该知晓系统的一切。

1.4. 性能

不要过早优化，但明显的反模式应当被指出：

• 循环内的查询（N+1问题）。
• 使用mysql_*函数（这些函数在PHP 7+中已被移除）。
• 对频繁查询缺少数据库索引。

2. 如何提出反馈：建设性批评的艺术

如果反馈听起来像"这代码太烂了，重写吧"，哪怕是最正确的评论列表也没有用。以下是几条规则。

2.1. "三明治"法则

先肯定，再提意见，最后给予支持。

• 肯定："接口用得很好，代码变得更灵活了。"
• 意见："但这里存在潜在的XSS漏洞——让我们对输出进行转义。"
• 支持："除此之外逻辑正确。修复后就可以合并了。"

2.2. 用提问代替命令

与其说"换个方式做"，不如问："如果我们把这个逻辑提取出来怎么样？"