聊聊“前端开发“到底是在做什么

聊聊"前端开发"到底是在做什么

做了这么些年前端，偶尔还是会被人问到："你们前端到底是干嘛的？写页面的吗？"每次听到这个问题，我都想认真解释一下，但又不知道从哪说起。最近正好有空，就把自己的理解整理一下，也算是对这个职业做一个阶段性的梳理。

先说一个最朴素的理解

我认为从比较宽泛的概念上来说，前端开发解决的是人与机器交互过程中，关于 UI 界面的展现和交互功能的实现。说白了，前端工程师干的事情就是通过编码，让用户在屏幕上看到该看到的东西，并且能顺畅地完成他想做的操作。

这个理解对不对？我觉得大方向是没问题的。但是做得越久，越觉得这个定义只说了表面上最显眼的那一层，底下还有很多东西没有被覆盖到。

"展现和交互"只是冰山露出水面的部分

用户打开一个页面，看到的是界面，感受到的是交互。但是为了让这个界面出现在他眼前，前端工程师实际上要处理的事情远不止"把设计稿还原出来"这么简单。

举个例子，同样一个列表页，你要考虑的可能包括：数据从哪来、怎么请求、请求失败了怎么办、数据量大了怎么分页或者虚拟滚动、不同设备上怎么适配、加载过程中用户看到的是什么、操作之后状态怎么更新……这些东西用户是感知不到的，但少了任何一环，体验就会出问题。

所以我后来倾向于一个更完整一点的说法：前端开发是在客户端环境中，把产品需求、视觉设计和后端数据整合为用户可感知、可交互的界面，并且在性能、体验和工程质量之间做平衡的一项工作。

这里面有几个点我觉得值得展开说说。

"客户端环境"这个前提很重要

前端代码不是跑在你自己可控的服务器上的，它跑在用户的浏览器里、手机里。这意味着什么呢？意味着你面对的运行环境是千差万别的。用户的设备可能很好也可能很差，网络可能是 WiFi 也可能是地铁里时断时续的 4G，浏览器版本可能是最新的 Chrome 也可能是某个你从没听说过的国产浏览器。

这种不可控性是前端开发的一大特点，也是很多技术决策的出发点。为什么要做性能优化？为什么要做兼容性处理？为什么要做渐进增强？根源都在这里。

不只是"实现设计稿"

我见过不少人对前端的理解停留在"设计师出图，前端切图"这个层面。早些年或许确实是这样，但现在的前端开发远不止于此。

一个前端工程师日常打交道的东西，大致可以分这么几层：

最表层的是 UI 和交互，这是用户直接能看到和摸到的部分，也是大多数人对前端的第一印象。

往下一层是数据和状态。页面上展示的数据从哪来，用户操作之后数据怎么变化，组件之间怎么共享状态，这些问题的处理方式直接决定了应用的复杂度和可维护性。

再往下是工程化。模块怎么拆分，代码怎么组织，构建流程怎么设计，怎么做持续集成和部署。项目小的时候可能感受不明显，但项目一旦上了规模、团队一旦多了几个人，工程化的好坏就是决定性的了。

还有一层容易被忽视的是可访问性。你的页面能不能被屏幕阅读器正确解读？键盘能不能完成所有操作？色彩对比度够不够？这些事情很多团队不重视，但它关系到一部分用户能不能用你的产品。

体验是手段，业务价值才是目的

我们经常说前端要追求"用户体验良好"，这没错，但我觉得需要再想深一步。体验好不好，最终是为业务服务的。一个按钮做得再精致、动画再流畅，如果它没有帮用户完成任务、没有为业务带来转化，那也只是自嗨。

前端工程师不应该只关注"这个页面好不好看、交互顺不顺滑"，还应该去理解"为什么要做这个功能、用户在什么场景下会用到它、它要解决的问题到底是什么"。好的前端工程师一定是对业务有感知的，而不仅仅是一个接收需求、还原设计稿的执行者。

从这个角度说，前端其实是产品、设计、后端之间的一个连接者和翻译者。你要把产品经理的需求、设计师的视觉方案、后端提供的数据接口，整合到一起变成一个可用的产品。这中间需要的不只是技术能力，还有沟通和理解能力。

写在最后

回到最开始的问题：前端开发到底是做什么的？

如果用一句大白话来说，就是让用户看到该看到的，做到想做的。

但要把这件看似简单的事情做好，背后涉及的东西比表面上看起来多得多。这也是我觉得前端有意思的地方——它不是一个纯粹的技术活，也不是一个纯粹的设计活，而是一个需要你同时理解技术、理解用户、理解业务的综合性工种。

如果你正在考虑要不要做前端，或者刚入行还在迷茫，希望这篇文章能给你一点参考。前端这条路，越往深走，你会发现要学的东西越多，但也正因为如此，它才不容易让人觉得无聊。