PHP 项目里怎么看出"老将"的经验价值？
这是个挺实在的问题,在 PHP 项目里，老将（资深工程师）的价值往往不是靠写更多代码体现的，而是体现在一些"减法"和"防御性设计"上，可以从以下几个维度观察：
代码层面的"隐性经验"
对边界条件的敏感度
- 新手：
$data['name']直接用 - 老将：
$data['name'] ?? null、isset()、类型校验、filter_var - 看
if分支的密度——老将的代码往往"看起来啰嗦"，但线上事故率低
错误处理的层次感
- 新手：
try { ... } catch (Exception $e) { echo $e->getMessage(); } - 老将：区分业务异常 / 系统异常 / 可恢复 / 不可恢复，日志分级，
finally清理资源，异常不吞不裸奔
对 PHP 语言特性的克制使用
- 知道
extract()、$$var、 抑制符的坑 - 用
declare(strict_types=1)、类型声明、readonly - 但也不滥用魔术方法、反射——老将懂"什么不该用"
SQL 与 ORM 的边界感
- 知道什么时候用 Query Builder、什么时候手写 SQL、什么时候用原生 PDO
- 关注 N+1、索引、
EXPLAIN，不只是"能跑"
架构与工程化层面
依赖管理的洁癖
composer.json版本约束合理（ vs vs 精确版本）- 依赖树不臃肿,能说出每个包的用途
- 知道
composer.lock该不该进版本库
配置与环境隔离
.env不硬编码，敏感信息不进代码- 开发/测试/生产配置分离，有合理的默认值兜底
可观测性意识
- 日志结构化（JSON 而非
echo） - 关键路径有 metrics / trace
- 异常有上下文（请求 ID、用户 ID、入参快照）
迁移与兼容性思维
- 数据库迁移脚本可回滚
- API 变更考虑旧客户端（版本化、灰度）
- 升级 PHP 版本时知道哪些扩展会挂
协作与流程层面
Code Review 的"毒性"
- 老将的 review 会指出设计问题（耦合、边界、失败模式），而不只是格式
- 会问"如果这里超时/并发/数据为空会怎样"
测试策略
- 不是覆盖率崇拜,而是关键路径有测试、边界有测试
- 知道哪些代码值得测、哪些不值得（比如纯模板）
文档与"未来自己"
- 复杂逻辑有注释说明为什么（不是做什么）
- 有 CHANGELOG、部署说明、故障预案
怎么"量化"观察？
| 维度 | 新手表现 | 老将表现 |
|---|---|---|
| 线上事故率 | 高 | 低（预防性设计多） |
| 排障时间 | 长 | 短（日志/监控到位） |
| 代码改动影响面 | 大 | 小（解耦好） |
| 技术选型 | 追新 | 权衡后选稳 |
| 对"坑"的预判 | 事后 | 事前 |
一个反直觉的点
老将的价值有时体现在"少写代码"：
- 能用一个现成库就不自己造轮子
- 能不加的需求就推动删掉
- 能不用框架特性就保持简单
所以看一个 PHP 项目，不要只看代码量和复杂度，要看：线上稳定性、故障恢复速度、新人上手成本、技术债增长曲线——这些才是老将经验的真实投影。
