PHP项目中“老将经验价值”的观察维度
在PHP项目里评估一位资深工程师（老将）的经验价值，不能只看代码量或工龄，而要看他在决策质量和风险规避上留下的痕迹，以下是可观察的具体维度：
看代码里“没写什么”
老将的价值往往体现在克制：
- 不过度抽象：不会为了“设计模式”硬造三层继承，简单问题用简单解法
- 不滥用框架特性：知道哪些魔术方法、ORM关联会在复杂查询时埋雷
- 异常处理有边界：不是到处 try-catch 吞异常，也不是让错误裸奔，而是区分“可恢复/不可恢复”
- SQL写法保守：避免 SELECT *、注意索引命中、分页不用大 offset——这些都是踩过坑的痕迹
看架构决策的“反直觉”之处
- 为什么这个模块不上微服务/不上消息队列：老将常能说清“当前量级上这套东西的运维成本 > 收益”
- 为什么这里用原生SQL而那里用ORM：能给出性能/可维护性的具体权衡理由
- 为什么缓存策略设成这个粒度：能讲出缓存穿透、雪崩的实际教训
看故障处理与运维痕迹
- 日志分级是否合理：老将的日志能直接用于排障，而不是满屏
error_log('here') - 配置与代码分离：环境变量、密钥管理是否规范，是否有“本地能跑线上炸”的隐患
- 数据库迁移/回滚脚本：是否有可逆的 migration，而不是手工改表
- 监控埋点：关键业务是否有耗时、失败率上报
看代码可读性与“交接友好度”
- 变量/函数命名是否表达意图而非表达实现
- 复杂业务是否有注释说明为什么（而非说明做什么）
- 是否有文档化的约定：目录结构、异常码、接口规范
- 新人接手时,老将的代码是“读得懂”还是“猜得到”
看技术债的态度
- 是否在关键路径上主动重构，在边缘路径上容忍技术债
- 是否能区分“必须现在修”和“记下来以后修”，而不是全修或全不修
- 是否有技术债清单和优先级判断
看团队协作中的“隐性输出”
- Code Review 意见是指出风险还是争论风格
- 是否能把踩过的坑沉淀成团队规范/工具/脚手架
- 面对新需求时,能否快速判断“这个我们三年前试过，坑在哪”
量化观察（如果能拿到数据）
| 指标 | 老将特征 |
|---|---|
| 线上事故率 | 其负责模块显著低 |
| 代码返工率 | PR 被要求大改的比例低 |
| 排障时长 | 平均 MTTR 短 |
| 新人上手时间 | 其模块交接快 |
| 依赖升级/漏洞修复 | 响应及时且有预案 |
核心判断
老将的经验价值 = 用更少的代码、更低的运维成本、更少的线上事故，解决同等复杂度的业务问题，并能把这种判断力传递给团队。
如果只看“写了多少行、用了多新的框架”，反而容易误判——真正的老将常常是那个说服团队不要上某个新技术的人。
