全栈开发的价值不在"全"，在"通"

一、一个常见的误解

一提全栈，大家想到的是"前端会写、后端也会写"。但市场上会写两端的人不少，真正稀缺的不是会写两端的劳动力，而是能在两端之间做出一致决策的人。

后端把字段设计成嵌套对象，前端就得在渲染层拆一遍；接口分页用 offset，列表页做无限滚动就会遇到重复数据；鉴权逻辑放中间件还是放路由里，决定了前端错误提示能不能区分"没登录"和"没权限"。这些问题，每一处单看都是小事，串起来就是无数次的返工和扯皮。

二、"通"体现在哪

我们内部评价一个人的全栈能力，看三个问题他答不答得上来：

数据从哪来到哪去。 一个页面显示的数字，能一路追溯到它在哪张表、经过哪几层转换、缓存在哪里、什么时候会过期。答不上来的人，改需求时只能碰运气。

边界在哪。 一个功能放前端做还是后端做，能说出理由：校验放后端是安全，交互预检放前端是体验，重计算放后端是省流量——而不是"以前都这么写"。

坏了怪谁。 线上出了问题，能独立判断是数据层、服务层还是渲染层的事，并且知道去哪一层取证。全栈的价值在排障时最明显：不需要在三个团队之间传话等结论。

三、对小团队意味着什么

小团队请不起每个环节一个专家，但也不需要。一个"通"的人加两个"专"的人，通常比三个各管一段的团队交付得更快，因为沟通成本从跨人变成了跨层，而层的边界是清楚的。

对个人的建议是：别急着"全"，先把自己那段上下游打通。前端先把接口设计和数据库读明白，后端把渲染和状态管理摸清楚。"全"是结果，"通"是路径。

撰稿：邓湘雷