Web 前端的困局与突破

Question

每个 Web 前端都会不时思考自身对于团队的价值和在团队中的话语权，这类思考背后存在困局和突破。

困局

困局必然是负能量，耐下心来了解困局后再看突破。

价值

在团队中前端的职责是实现原型和设计工作中的客户端部分，是实现者。很少参与功能/程序设计。极少数业务场景下是重前端的。需要前端实现可视化编辑组件（可视化创建页面/Web 编辑器)。这样的团队少之又少。大部分情况下前端的职责就只是实现产品设计。

前端巧妙的程序设计，优秀的页面大部分情况下与商业逻辑是无关的。技术是依附于商业生存的。在客观的管理者视角看，前端是有价值的，但在技术团队中前端的价值不重要。只要把活干好了，别出错就可以了。也不需要维护管理公司命脉数据库。

价值的意义：收入，市场竞争力都是基于价值的

话语权

从项目管理的角度看:

岗位	职责	分工
产品经理	基于市场需求表达产品界面和功能逻辑	需求与业务逻辑设计
UI 设计	基于产品表达的界面进行界面设计	基于原型 UI 交互设计
前端	基于产品原型与 UI 设计完成客户端的实现	实现客户端
后端	数据结构与程序的设计和实现	程序设计与实现

产品同事对项目有绝对的话语权，设计同事是产品同事的下游，是基于产品同事的要求完成界面设计工作。后端同事看似也是实现者，实则是后端是程序设计者

当前端遇到上下游意见相左时，因为前端的分工是实现者，所以往往前端是没有话语权的。有些人常说的用户体验，实际上这个活是 UI 设计干的活，前端只需要做到快速的基于设计完成客户端开发。并保证客户端的加载性能。

高流量多信息聚合的页面需要基于前端的专业意见去协作开发，不过这种情况太少了

话语权的意义：决定项目中与前端相关的问题能用你的专业想法解决，而不是由 外行 解决。

恶劣的的工作环境

1. 没有产品原型
2. 没有设计稿
3. 没有后端接口文档
4. 联调阶段扯皮

以上问题在很多小团队出现的特别频繁，严重影响了工作进度。

前端是实现者，要基于设计去实现，基于实现去"消费"接口。

3 4 问题是出现的最频繁的，扯皮无止境，不停的内耗。

天花板

随着三大剑客(react vue ng) 的流行，基于成熟的组件库能极大的提高前端开发效率。大部分团队不需要再造适合公司业务场景的组件轮子。从业两三年就可以达到日常 90%的页面开发工作是"机械化"的。大量的时间反而是解决上节说到的恶劣的工作环境

前端工程管理，前端开发流程的制定，前端架构设计这些都是由前端话事人去设计和执行的。在技能水平+经验+对团队的了解程度+话语权上都应该由前端话事人去解决。大部分前端只需要遵循团队流程规范即可。

JavaScript 与 Node

JavaScript 是困局这一点是很多人没有意识到，也不认同的。

JavaScript 过于灵活宽松让代码不易于维护。动态语言在大型项目会降低可维护性。 TypeScript 的类型系统需要对 JavaScript 妥协。始终让前端在语言层面无法使用类型系统方便的写出分层明确和易于维护的代码。

这点不深入讨论，了解过其他强类型系统语言再来使用 TypeScript 写非常严谨容错率低的代码自然就能明白。很多团队希望使用 Node 去提升自己的话语权，殊不知必须 Node 与公司所遇到的场景和问题契合才能解决问题。

不要把自己限死在 JavaScript ，前端掌握当前团队的后端语言不是啥坏事。不是每个项目都需要要 SSR。都需要使用 Node 进行前后端分离。

容我吐槽一番

Web 前端难以 100%利用机器，这里的"利用"指的并不是编写高性能代码。而是无法控制代码运行环境。

App 前端相对于 Web 前端，能利用的机器资源更多一点。可以在 App 开发大型游戏。这能扩展程序员的边界。

后端相对于 Web 前端，对机器的利用能达到主宰的程度，语言不顺手直接换个编程语言。数据库不适合目前业务场景直接换一种类型的数据库。某个库或服务器有 Bug 直接升级解决。

而 Web 前端很容易搞来搞去都在 JavaScript 的世界，要内卷到熟读 ECMA 规范。在运行环境层面要被小程序动不动的运营规则改版折磨的发版前一晚改代码，

突破

困局有:

1. 价值
2. 话语权
3. 恶劣的工作环境
4. 天花板
5. JavaScript

一句话就能说明白如何突破:

不要把自己限制在客户端的实现者，让自己参与产品程序设计，精前端，懂业务，懂后端。

恶劣的工作环境

当没有产品原型和设计的情况下，正确更多的时间，去了解产品需求，使用前端界面作为"原型"。完成部分产品没时间或者认为不重要的产品设计工作。没有设计的情况下基于成熟的 UI 组件，antd element 完成表单类的开发，一些交互设计自己做主设计交互细节并实现。没有设计的情况下大概率你能做主。

当后端给不到接口时，在前端角度维护接口文档，通过接口更深入的理解程序设计。有理有据的要求后端同时配合你给到接口让你使用，因为客户端是接口消费方。如果后端给不到接口就自行模拟接口，再联调的时候再修改也无妨，这样单前端定义接口的过程就是在进行程序设计。基于客观接口进行联调，避免主观争论。

善于使用错误追踪系统记录错误，例如 Sentry 。 有理有据的去排查问题，定位问题，给出问题修复报告。防止莫名其妙背锅。

愿你不遇到恶劣的工作环境，遇到相互配合的好同事

天花板与 JavaScript

在前端角度不要局限于 Web 前端，在吃透当前工作环境时去了解其他客户端技术，比如各类小程序， IOS Android。

Swift Kotlin Java 都是不错的语言，了解他们后再回头写 TypeScript 会对编程有新的认识和理解。

不要局限于前端，在项目中了解目前团队的后端语言和后端知识。参与后端提供的接口中数据类型的定义，(类似 TypeScript 中的 interface)。了解后端语言(PHP 就算了)，对项目后端的程序设计有足够了解。必要时尝试参与后端开发，先完成一些简单不重要的后端工作。

大部分情况下足够努力的前端做个三五年很容易在小团队做到天花板。不考虑换工作的情况下，去向全栈发展是个很好的选择。只有掌握了程序设计才能掌握话语权。

现在很多人错误的理解了全栈，认为会 node 写个编译工具就是全栈，不要局限于掌握的后端语言是 Node 。 使用 Node 能免去学习一门新语言的好处没有那么重要，反而会将你局限在 JavaScript。

了解一门强类型语言，了解各种后端技术。了解其他前端领域。

价值与话语权

吃透目前工作环境所需要使用的前端技术后，由实现者变为程序设计者不要将自己局限于"页面仔"。去理解了解业务才能提升自身价值。

总结

始于前端，不局限于前端。不要把自己限制在客户端的实现者，让自己参与产品程序设计，精前端，懂业务，懂后端。