开发工程师该深耕还是全栈？先算变更半径：4 类路线、7 个指标和 1 周自测步骤
先说个得罪人的结论：大部分开发工程师问“深耕还是全栈”，问的其实是“我该学什么框架”。我 2023 年在一家 80 人 SaaS 公司做后端，团队把 Java 单体拆成 6 个服务后，QPS 峰值 1800 没崩，p99 从 420ms 降到 260ms，但线上事故从每月 0.7 次变成 2.3 次。后来复盘才发现，问题不在 Java 还是 Go，而在每个人的“变更半径”被拉大了：你改一个接口，要碰 3 个仓库、2 个数据库、1 个 Kafka topic，还要等 4 个人 review。全栈和深耕不是道德选择，是两种压缩半径的方式。下面这块不是标准答案，是我自己踩坑后还在用的土办法。
1. 别按前端/后端/全栈分，按“变更半径”分
我见过太多 JD 把开发工程师写成“精通 Java、Spring Cloud、MySQL、Redis、Kafka、Vue、K8s”，像超市清单。但真到线上，决定你痛不痛的是：你一次变更要跨多少服务、多少环境、多少数据表、多少团队。我的粗糙公式是：变更半径 = 服务数 × 部署环境数 × 数据表数 ÷ 自动化测试覆盖率。上周我拿 2024 年 4 月到 7 月的 90 天数据算自己：5 个服务、3 套环境、21 张表、自动化覆盖率 0.63，分数 5×3×21÷0.63≈500。这个数没有绝对值，但和同事对比很扎心：做 BFF 的同事分数只有 90 左右，做基础库的同事分数 60 左右。分数越高，不代表你越强，代表你每次上线要欠更多人。
2. 四类开发工程师对比：后端纵深、全栈、平台工程、业务工程
下面这张表是我 2024 年 5 月翻招聘平台和问前同事攒的，薪资是一线城市主观感受，不是精确统计。真正要看的是“线上责任”和“变更半径”两列，那才是每天折磨你的东西。
| 路线 | 典型技术栈 | 招聘关键词 | 上手时间 | 线上责任 | 薪资带宽（2024 一线感受） | 被 AI 冲击 | 35+ 路径 | 适合谁 |
|---|---|---|---|---|---|---|---|---|
| 后端纵深 | Java 21、Spring Boot 3.3、PostgreSQL 16、Redis 7.2、Kafka 3.7 | 高并发、分布式、JVM、MySQL | 6-12 个月 | 接口、DB、缓存、消息 | 20-45K | 中，CRUD 被压，调优和故障难替 | 架构、技术专家、中间件 | 能坐住看 GC 日志的人 |
| 全栈/BFF | React 18、Next 14、Node 20、TypeScript、GraphQL | 全栈、BFF、Node、React | 3-6 个月能干活 | 页面、BFF、接口聚合 | 15-35K | 高，页面和简单接口生成快 | 产品工程、技术负责人 | 喜欢把事推完的人 |
| 平台工程 | K8s 1.29、Argo CD 2.10、Terraform 1.8、Prometheus 2.50、OpenTelemetry 1.24 | DevOps、SRE、平台、云原生 | 6-18 个月 | 集群、CI/CD、可观测性 | 25-50K | 低，事故现场需要人 | SRE、平台负责人、云方案 | 对系统和自动化上瘾的人 |
| 业务工程 | 低代码、CRM、ERP、SQL、报表 | 实施、业务开发、数字化 | 1-3 个月 | 流程、报表、集成 | 12-25K | 很高，规则明确的部分先没 | 业务架构、产品经理 | 懂业务比懂框架多的人 |
我自己是从后端纵深切到 BFF，再补了一点平台工具链。最大的感受：全栈不是前端+后端都写，而是你能独立把一个小需求的“变更半径”压到 1 个仓库、1 套环境、0 个跨团队评审。深耕也不是背八股，而是当数据库连接池从 20 调到 50 后 p99 反而涨了，你能在 30 分钟内看出是锁等待还是 GC。两条路都能活，但别把简历写成“精通 12 个框架”，那东西现在连 AI 都懒得看。
3. 一周自测：你的变更半径到底多大
别急着报课。拿 7 天，每天 40 分钟，把下面几步跑一遍。你需要 GitHub CLI、jq、kubectl、psql 这几个工具，没有就先装。
Day1：拉最近 90 天你合并的 PR。运行 gh pr list --state merged --limit 200 --json number,title,mergedAt,files,reviews > prs.json，然后 jq '.[] | .files | length' prs.json | awk '{s+=$1} END {print s/NR}'，得到平均每个 PR 改几个文件。超过 8 个，说明你的变更已经不小。
Day2：统计你碰过的服务数。运行 git log --since='90 days ago' --name-only --pretty=format: | cut -d/ -f1-2 | sort | uniq -c | sort -nr | head -20。看前 5 个目录，如果跨了 3 个以上服务，记 3 分；跨 6 个以上，记 6 分。别骗自己，临时改一行也算。
Day3：看部署环境。运行 kubectl config get-contexts | wc -l 看你有几个集群上下文，再运行 kubectl get applications -n argocd -o json | jq '.items | length' 看 Argo CD 里有多少应用。应用数超过 20 个，说明部署链路很碎，变更半径天然大。
Day4：数数据表。运行 psql -h localhost -U app -d appdb -c 'SELECT count(*) FROM pg_stat_user_tables;'，把 public schema 的表数量记下来。如果你经常改的表超过 10 张，而且没有迁移工具，比如 Flyway 9 或 Liquibase 4.25，那你的回滚大概率靠手写 SQL。
Day5：算分。用公式：服务数 × 环境数 × 表数 ÷ 自动化测试覆盖率。覆盖率可以用 JaCoCo 0.8.11 或 Istanbul 跑出来。我的土阈值：低于 80 算低，80-300 算中，高于 300 算高。高于 300 还天天催你“快一点”的团队，不是不重视质量，是没算过这笔账。
Day6：选路线。分数高于 300，且你烦跨团队沟通，优先补 BFF、API 聚合、TypeScript，把前端到接口这一段收进自己手里；分数低于 80，但故障影响钱和用户，优先补 PostgreSQL 执行计划、JVM 调优、Kafka 积压处理。分数高且事故多，别学新语言了，先学 Terraform、Argo CD、OpenTelemetry，把部署和观测补齐。
Day7：做 30 天实验。记录 DORA 四项：部署频率、变更前置时间、变更失败率、恢复时间。目标可以定成：部署频率 > 每周 1 次/人，变更失败率 < 15%，MTTR < 1 小时。达不到就继续拆：CI 从 18 分钟压到 8 分钟，单测覆盖率从 0.4 拉到 0.65，回滚脚本从 6 步压到 2 步。这些比“学完 Spring Cloud 全家桶”更影响你下班时间。
4. 我的独立观点：开发工程师的深度是可逆性
我现在判断一个开发工程师，不太看他会不会写红黑树，也不看他有没有全栈标签。我问他三个问题：你最近一次变更跨了几个服务？回滚用了多久？出事后你怎么知道是哪个版本的问题？答得清楚的人，通常差不到哪去。答不清楚的人，框架背得再熟，我也不敢把支付链路给他。
所以“深耕还是全栈”是个假选择题。真正的选择是：你要压缩哪一段半径？全栈压缩沟通半径，后端纵深压缩故障半径，平台工程压缩部署半径，业务工程压缩需求翻译半径。四类都能到 35+，但路径不同。我的建议有点土：25-30 岁先做 2 年后端纵深，再花 1 年做 BFF/全栈，最后用半年碰平台工具链。别在简历上集邮，要在生产环境留下 3 个数字：p99 降 30%、变更失败率降 50%、MTTR 从 2 小时降到 40 分钟。这些数字比“精通”两个字值钱，也比任何路线图都更像你的护城河。