先说点什么吧

经过大半年的踟蹰，最终还是决定要写一点关于我所从事的职业的文章。但与以往的分享或文章不同，这次的内容无关任何具体的技术。我在“webpack指南”、“组件库开发”和“可视化页面编辑器”这三个选题中犹豫了很久，但最终是某次和同事们在楼下休息，听着同事们吐槽身边事情的时候确定的。那一刻我忽然不太想分享任何具体的前端技术经验，而是想泛泛地，随意地就这“前端开发”这个主题本身来聊一聊我个人的一些想法和认知。一方面对我自己来说是一次思维旅行和经验总结，另一方面也期望这些散碎的看法能对读者有益。

当然，还是要简要地介绍一下自己的从业经历。我是2015年开始从事前端开发工作，期间经历了唯品会、融数金服、火币、哗啦啦四家企业。除了日常的项目任务，还开发了一套在融数期间成型的UI组件库Admin UI。目前在哗啦啦负责商户中心前端组件化的相关工作，同时负责一个实验性质的低代码前端页面编辑器项目Primus。

前端开发工程师

在我们的职位名称中，“前端开发工程师”这个词中包含了我们这个群体主要的工作内容、范围，以及我们的职位。这里我使用了“表述”二字来拆解这个职位名称，但很多时候有意或无意地，我们会以此画地为牢，将自己牢牢地限定在这个范围内。

实际上可能很多时候你压根不知道或者根本没有思考过关于“前端”这个词的含义。对于Web开发者来说，多数时候这意味着一些HTML页面，包含着一些精心设计的结构、样式和交互逻辑。但从更广义地范围，“前端”指的是“面向用户的那一端”。这意味着作为前端开发工程师，你是那个最终需要为用户体验负责的人。

我曾听过同事抱怨由于后端同事提供的接口性能太差，过长的返回时间导致用户需要在前端等待很久。我问他你为什么不去解决这个问题？他的回答是“我前端页面的性能没问题，这是后端的锅”。这是个非常经典的回答，同时也是一个完美的牢笼！

事实是大部分用户根本不知道你这个页面体验这么糟糕到底是什么原因。他们不知道，不愿意知道，也不应该知道。他们是用户，而你是照顾他们的人。走出这个牢笼的唯一正确的信念只有一条：照顾好你的用户。

照顾好你的中间用户

既然要照顾用户，自然首先需要搞清楚你的用户到底是谁。常年在业务线的朋友可能不假思索就会回答，我的用户就是用我们产品的人。这当然是没有错的，但实际上，还有一些不太容易注意到的用户被我们忽略了。

假设你目前正作为前端工程师参与某个OA系统的开发。其中一个功能点是“用户能够在组织结构中准确查找到部门”。为此你和产品经理精心设计和实现了一个“部门筛选器”放在了页面中。之后你又注意到很多其他的模块也需要这个功能，于是你将它做成了项目内通用的“组件”供负责开发其它模块的同事使用。

在这件事上，我想问的是你真的清楚你的用户是谁吗？

毫无疑问你们整个OA项目所面向的用户肯定是你的用户，我习惯称之为“最终用户”。而使用了通用模块“部门筛选器”的那些同事们，实际上是你的“隐藏用户”，我习惯称之为“中间用户”。你可能对于如何照顾好“最终用户”已经驾轻就熟了然于胸了，但对于这些“中间用户”，你如何照顾到他们？你可能需要花心思做好下面的事情：

• 好好整理和设计“部门筛选器”组件本身的功能和接口，让组件本身心智模型尽可能简单；让接口命名极尽可读；让接口数量在满足功能和日后扩展性的前提下尽可能少
• 支持尽可能多的安装方式，并考虑各种安装方式下的异同，如果安装过程本身较为复杂，则应该尽可能帮助你的同事们做掉这方面的额外工作（比如提供CLI工具来进行安装）
• 在同事们很方便就能访问到的地方提供详细的组件使用文档，并开放QA，尽可能解答同事们的疑惑
• 尽量使用语义化的版本号，并尽可能在非大版本的升级上向前兼容

我只是拍脑袋列举了几条，实际上如果你正在开发一个组件库，则需要做的事情远不止这些。

我们来看看另一种场景，假设你正在为一个新的项目做一些初始化工作。确定技术选型、选择组件库，制定各种项目约定、划分路由和业务模块等等这些前端架构师的日常工作，除了面向最终用户，更多时候是面向项目组内的其它前端甚至后端伙伴。他们是你作为架构师的中间用户，照顾好他们意味着你需要这些事情：

• 编写一个完善的README文档，这个文档应该让新进的同事在不问你任何问题的情况下即可开始项目的开发工作，这是所有架构师应该完成的基本工作
• 不要过度设计，很多时候过度设计会带来沉重的心智负担，给你的团队造成巨大困扰。合理的程度应该是“刚好能用”，比如在业务模块的层面实际上可以不再进行代码复用，那些看起来一样的样式、逻辑和交互就让它们在模块层面重复编写即可。业务模块层面进行代码复用的后果很可能是你的伙伴们根本记不住都有哪些东西被提取出来了，久而久之那些被提取出来的东西就被遗忘了。另一方面业务模块的频繁变动通常会让原本可复用的代码失效，得不偿失
• 没有特殊需求的情况下，技术选型、项目内的约定应该尽肯能照顾到你的团队的大部分人。选型方面应该尽可能使用他们最熟悉的技术和库，项目内的约定应该尽可能符合大多数人的编码习惯

所以广义上来看，除了你的最终用户们，整个公司内甚至整个行业内（开源事业）对你有依赖的同事和朋友们，实际上都是你的用户。而面对所有这些用户唯一正确的信念真的只有一条：照顾好他们。对于一个优秀的前端开发者来说，无论面对的用户是“最终用户”还是“中间用户”，一切挡在你和用户之间的障碍，清除他们就是你的工作职责。

不只是写代码

想要成为一个优秀的前端开发工程师，你的工作可远不止是写代码而已。

我曾经听过一句话“技术解决不了任何问题”。这当然是一句极端的断言，但并不全无道理。随着工龄的增长，你是否曾发现工作中遇到的大量问题实际上根本不能或者不应该靠技术来解决？《程序员的思维修炼》一书中讲过一个故事，大意是某航空公司召集了大量技术人员，希望设计一种新型超音速客机来替代现有的亚音速客机。当时正好有相关的领域专家在场，然而他并没有立刻提出自己的技术方案，而是追问航空公司为什么需要超音速客机？航空公司答曰需要提高客运速度。大部分技术专家估计会止步于此不再追问，然而该领域专家却继续追问：“为什么要提高客运速度？”航空公司答曰希望借此缩短旅客的旅程时间，提高旅客的用户体验。专家又追问：“旅客从家出发到目的地安顿好的这段时间中，在飞机上的时间占其中的多大比例？”

最后的结果是航空公司放弃了需要巨大研发成本和实际上乘坐体验很差的超音速飞机方案，转而着手优化旅客从家到目的地的整个旅程上的各个其它部分的体验，反而达到了更好的效果。

这意味着照顾用户，很多时候技术解决不了太多问题。作为前端开发工程师，开发只是你的工作的一小部分。有时候你需要站在产品经理的角度和他们一起去思考，帮助产品经理设计出更合理的产品。有时候你也需要站在美术设计的角度上，帮助设计出更统一更漂亮的界面。还有些时候，你需要站在行业的山顶，俯瞰和审视你所开发的产品及其价值，帮助你的领导甚至公司纠正可能会发生的产品定位上的偏航。

为什么需要做这么多的事情？答案很简单：你所有的工作价值，都是建立在用户价值之上的。帮助用户实现他们的价值应该是你和你团队所有人的最终目标。做出所有决定以及确定工作职责的时候，如果你正盯着这个最终目标，那么你甚至会觉得我上面说的内容少得可怜。至于前面提到的关于接口性能的事，我想读到这里，你应该有自己的想法了。

面对你的伙伴们

帮助你的伙伴做好他的工作，并不是说要越俎代庖。我们来稍微讨论一下流水线上的不同职位。

国内大部分公司的前端工程师们面对的工作流程通常是这样的：产品经理 -> 美术设计 -> 前端/后端 -> 测试 -> 运维 -> 用户。

产品经理通常负责研究用户需求，并根据用户需求确定和设计产品功能。对于他后面的同事来说，他应该只负责提出功能要求，这也应该是大部分人的期望。虽然有时候产品经理们会负责设计一部分交互形式，但我认为这实际上并不应该由他们来负责。在一个没有专门的交互设计师的团队中，交互形式的设计通常会由美术设计来完成。很多时候的实际情况是无论是产品经理还是美术设计来负责，最终设计出来的交互形式从实现成本和易用性上看往往差强人意。关键的原因是如果没有经过专门的交互设计训练，产品经理和美术设计，很多时候并不清楚不同的交互形式的优缺点，以及实现它们大概的成本。而作为常年开发交互界面的前端工程师则恰恰相反，经验丰富的前端工程师往往把玩过极多的交互形式，也很清楚实现这些交互大概的技术成本，他们能够找到平衡点。

美术设计在实际的工作中往往被称为“UI设计”（交互界面设计），但基于上面的原因我并未使用“UI设计”一词。美术设计决定了产品的颜值，如果说产品经理提出的是“功能要求”，那美术设计提出的则是“视觉要求”。如果产品各部分的交互形式由前端工程师最终来决定，那么美术设计提出的“视觉要求”可能就需要基于前端工程师的交互形式来产生。但本质上，对于后一个节点上的“前端/后端”来说，前面两个节点产生的都是“要求”。这两份“要求”就是工程师们的具体工作内容了。

如果项目中前端和后端是分离的两个项目，并且前端并不负责展示层的接口（在有些项目中会存在Node/Python/Go等语言编写的面向展示层的中间层，而这些中间层很可能也是由前端工程师们自己负责的），那么前端对后端就会存在“接口要求”。在后端工程师需要完全对展示层接口负责的前提下，接口的字段应该由前端来设计。实际工作中虽然不会这么绝对，往往是后端提供一份“接口文档”来列出接口的字段，但至少这份“接口文档”应该需要被前端认可。而这份“接口文档”实际上就是前端向后端提出的“接口要求”。可能后端工程师会需要前端在提出“接口需求”时稍微照顾到他们的模型设计，但原则上，前端工程师是要求的提出者，不应存在太多的妥协。从这个角度上看前文的接口性能问题，“接口要求”中也应该对后端工程师提供的接口性能提出具体要求。实际上接口性能要求的源头是来自于最初产品提出的“功能要求”中的，因为产品经理们在“功能要求”中大可以提出某些关键性能的要求。

大部分公司的测试们正在做着一份伟大的工作：为开发们擦屁股。通常测试需要负责每个迭代开发产物的各种测试工作，找出开发者们埋下的雷并反馈给开发者们让其修复。在大部分公司中，测试是产品上线前的最后一道关口，如果出现线上BUG，测试往往需要对此负责。我曾经遇到这样的场景：测试在群里告诉某开发者他的模块测出了几十个BUG，但他并未录入官方记录，只是善意提醒其注意代码质量并尽快修复，结果该开发者反过来讥讽测试是在拿BUG数量耀武扬威，认为其侮辱了测试这一职位。个人品性先放到一边，我对这种认为测试就应该是给开发者擦屁股背锅的认知是极端鄙视的。测试们工作的职责是保障产品质量，难道开发者们不应该承担这一责任么？你的良心不会痛么？很长时间我所在的团队都没有这里说的这些传统意义上的“测试”岗位。我们仅仅通过单元测试、自测和“集中测试”（我自己造的词，团队所有人停下来，一起测试某个迭代结果）来保证开发质量。而原本“应该”做这些事的测试们，去做测试平台了。产品在上线之前，需要通过测试平台的各种自动化测试才能继续部署，我认为这才是真正的“测试”。

最有意思的是运维同学。往往只有项目需要部署发布，开发者们才能感知到运维的存在。我观察到一个有意思的现象：很多公司的运维在做着原本应该是业务线的开发者们应该做的部署工作，并且以此为荣。在这个背景下，业务线想要部署发布时，气氛就变得很微妙了：运维觉得你们这些开发者什么都不懂，但真的需要打包发布的时候却不得不反过来询问开发者你这个项目应该怎么打包，怎么发布...真是耐人寻味。除了运维们的小心思，这里的问题跟测试非常类似，运维应该提供运维工具或平台，业务运维应当由业务开发者自己来完成。肯能你所在的公司目前还不具备这种条件，但当你面对运维时，你应该有这样清醒的认识。

Leader

实际工作中除了与你通力合作的伙伴们，你往往还需要面对你的领导。我想稍微讨论一种在面对领导时很有意思的态度：唯命是从，领导说的都是对的，无条件服从。这一态度有两种表现：其一是从最一线的员工到中层到高层，层层对上负责，所做的一切，只为得到领导的认可；其二是将所有细节都暴露给领导，所有需要决策的地方都让领导来进行。

对于第一种表现，实际上单独拿出来说并没有意义，出现在这里只是明确表现出了这些人对自己工作的认知和态度。想要升职加薪无可厚非，但工作的意义本身似乎对他们来说无足轻重。我并不想讨论工作的意义这种过于深刻的问题，但我认为大家都应该要思考这个问题。但凡是思考过这一问题，就几乎不会出现“单纯讨好”领导这种表现。

我想仔细讨论一下第二种表现，这也是我最近观察到的最多的情况。我经常看到同事们跑去找公司的SVP级领导，讨论各种产品的具体问题，并讨要解决方案这种迷惑的行为。甚至好几次我观察到某些一线产品经理去找他讨论按钮应该摆在哪里这种蠢问题。一个典型的情形是：产品经理跑去找领导，从领导那里获得了一个某按钮应该放在某位置的方案，执行下去后，用户反馈抱怨说该按钮放的层级太深特别不好用。这时产品经理根本不需要承担责任，至少不会被领导责难，因为这是领导决定的。

问题在哪里？问题出在迷一般的工作职责和范围。SVP应该关心技术方案细节和产品细节吗？产品经理或开发者应该让SVP关心具体细节吗？SVP不应该是只关心方向和结果吗？下属们不应该是只对结果负责吗？出现这一情况的原因我认为一样来自双方：大佬的问题是太过和善，每次都能满足他们；而下属的问题则是不愿担责。

一个正常的上下级交互模式是这样的：领导只关心整体目标以及达成该目标的大致方向，而下属工作范围内的所有决策应该由下属自己进行，并对决策结果负责；团队以此模式层层向下。这种模式实际上与OKR的思想不谋而合。一个典型的假想的例子：

• 公司：在移动办公领域发力，对标其它移动办公OA产品在该领域分一杯羹，并最终做到行业前三
• 技术中心VP：上线一款类钉钉的应用“听听”，并覆盖Web，iOS，安卓、各大小程序
• 产品中心副VP：组织“听听”Web端及小程序端的研发，并在三个月内上线1.0版本
• 前端架构：“听听”Web端项目技术选项、架构设计...
• 前端开发：开发“用户详情”页面

在这个至上而下的过程中，产品中心副VP根本不应该关心前端Leader在技术选项上的决策，他只应该关心是否能在三个月内上线；而前端Leader原则上不应该向副VP暴露他工作范围内的细节。当然，不是说不能和你的上级讨论一些有意思的工作内容，你的上级也不是说不能给你一些合理的意见或建议，而是本质上你需要对你工作范围内的所有决策负责。比如副VP建议前端架构可以使用React作为框架，前端架构基于各种原因，可能是团队、工期或成本等等，最终是可以决定使用Vue的。这时候架构师只需要对产品中心副VP的目标，也就是他的工作结果负责：在三个月内上线。

最后对于Leader这个话题，我想以我对Leader的认知结尾：作为一线的兵，我对Leader的目标负责，冲锋陷阵苦活累活甚至骂街掀桌，我来；作为后方的将领，Leader对我的后勤及保障负责，争取奖金保障调休甚至背锅扣帽，他来。

Mentor

很多外企都有Mentor制度，新进的同事在第一年都会有一个负责指引他的导师。国内的公司则大多没有这么明确的制度，但我建议或多或少要有这个意识。

作为新进的或低等级的萌新开发者，不要羞于寻找你的Mentor。一个好的老师胜过十本书，一个好的指引者对被指引者的影响是巨大而深远的。不仅仅是技术上的指导，Mentor更多的时候是在价值观、思维方式、工作态度和做事方法上起到指引和示范作用。我本人就是一个活生生的例子，我开始从事开发工作后不久，遇到了第一位老师。当时他也是我的上级，虽然他并不是前端开发者，甚至基本上他已经不写代码了，但进入他的部门后，他主动承担起了Mentor的工作，言传身教，向我打开了新世界的大门。到今天虽然我和他已经不在一个公司，但在我作为一个萌新时他所展现的那些价值观、思维方式和做事方法，直到现在还在深深影响着我。虽然他不是前端开发，但却正是基于他的引导和培养，我的前端技术才能得以突破，迅速成长到架构师的程度。

我的第二位老师，后来一直是我的领导。虽然他从来没说过是我的Mentor之类的话，但我一直将其看成是Mentor，他也一直在扮演着Mentor的角色，引导和培养着我和我的那些伙伴们。我是幸运的，工作中能遇到这两位老师。但同时我也是精明的，我知道遇到好的Mentor很难，一旦遇到，应该珍惜。

而当你成长到一定程度，你要有作为Mentor的觉悟。从技术等级上说，高等级的开发者应该主动承担起对低等级的开发者的指引工作，这是大部分公司技术分级中的实际要求。作为Mentor去指引他人对自己也是有好处的：一方面教学相长，你在指引的过程中自己肯定也会需要进一步思考提升，；另一方面这也是你对你所在团队的贡献，因为你肯定不希望新来的同事是猪队友。这里涉及了另一个话题：主动性。

主观能动性

环境和个体是相互作用的：你所处的团队影响着你，你也可以反过来影响你的团队。除了主动承担新进成员的Mentor工作以外，更重要的是，作为团队的成员需要有主观能动性，主动地去影响你所处的团队。

我听过太多类似的抱怨：工作不顺利，因为所处的团队太糟糕。当团队出现或者存在问题时，我们当然可以抱怨，但仅仅抱怨是没有用的。我认知中的主观能动性，实际上有三个方面的表现：

• 以身作则，自我管理：不管所处的团队或环境有多么糟糕，出现了多少问题，这不能成为你放低对自己要求的理由。比如你的团队没有人写单元测试，但这不能成为你不写单元测试的理由
• 发现问题，解决问题：主动去解决或者帮助、推动解决你看到的那些问题，而不是去关心这个问题你有没有责任，或者是不是在你的工作范围内
• 正向引导，改变团队：尽可能去向团队其他成员传递正确的价值观和做事方法，帮助他们改善和纠正自身问题，帮助他们提升自己，进而提升整个团队

你可能会发现，这些事情应该是一个团队的Leader应该做的事情，作为团队成员你好像有些越俎代庖。我认为担心完全是多余的：其一是不想当将军的士兵不是好士兵，这是应有的想要进步的表现；其二是你对团队做出的这些贡献，在KPI层面将全部算到你的团队Leader的身上，聪明的Leader应该为有这样的团队成员而感到兴奋。

关于范式、语言、框架、库和工具

我并不想列举前端领域那些常见的编程模型、语言或者框架、库和工具。如果读者对这方面内容有兴趣可以留言，我择日另开文章再行分享。这个话题下我想聊的是作为一名开发者我们应该如何看待这些东西。我经常能在网上看到类似这样的评论：“求不要更新了，学不动了”。虽然是一句玩笑话，但实际上的确有不少开发者是有类似的心态的。我们不能说这种心态有什么不对，只是这种心态会给我们自己造成困扰。

实际上我们对新技术的恐惧是由不恰当的认知造成的。很多朋友看到一门新的技术、框架等，往往只是看到了其是什么，比如说大部分人聊到Vue，可能顺嘴就把官网的介绍说出来了：“渐进式JavaScript框架”。的确，官方介绍准确描述了这门技术，但这句官方介绍并未传递一个非常重要的信息：它解决了什么问题。

这实际上是我个人非常推荐的看待各类范式、框架、语言等等的方法。还拿Vue举例，如果是刚刚上手，一定要带着这个问题去看官方文档：它解决了什么问题？这个问题背后隐藏了很多信息：

• 相对于vanilla JS，Vue解决了什么问题
• 相对于React、Angular这类同类型的框架，Vue又解决了什么问题
• 你期望Vue解决你的什么问题

我并不想展开这些点去讨论，而是希望你能带着这些问题去看待一个新的技术。

你会发现实际上“解决了什么问题”几乎可以用来看待一切技术的更迭：

• 面向对象范式解决了什么问题？响应式编程解决了什么问题？MVC/MVVM/MVI这些范式又解决了什么问题？这个框架解决了什么问题？这个库解决了什么问题？这个工具解决了什么问题？
• 这次升级解决了什么问题？这个选型解决了什么问题？这个架构解决了什么问题？这个约定解决了什么问题？
• ...

为什么这副“解决了什么问题”的眼镜，可以拿来看待所有的技术？因为这是技术的本质：任何技术的出现都是为了解决已经存在的问题。只有存在需求，新的技术才能出现。你会发现透过这幅眼镜，大部分的技术都不新鲜。人类的本质需求实际上是非常固定的，而作为技术需要服务的对象，只要需求没有变更，任何将该需求作为目标的技术本质上都不是真正的“新”技术。React相对于Angular是新技术吗？不是，因为它们本质上在解决同一个问题。Vue是新技术吗？不是，因为它甚至跟React用了类似的方式来解决同一个问题。

面向对象是新技术吗？不是，因为即使没有面向对象，你写几十年代码，自然而然也会为了省事写成面向对象的样子，因为不管有没有面向对象这种范式，你都要做抽象。响应式函数式编程是新技术吗？不是，因为它实际上也是在解决“抽象”的问题。

所以你看，戴着这副“它解决了什么问题”的眼镜，你将从各个方向审视一门技术：

• 横向：同当前市面上解决该问题的其它技术进行比较
• 纵向：不同时间段上（或各版本间）该技术的各次迭代的比较
• 时间线：在人类最早开始解决该问题到现在，使用过的所有技术与该技术的比较？
• 递归：该技术各个部分分别解决了什么问题，该问题的横向、纵向和时间线的比较

思考完这些问题，就只剩下一件事了，面对某个具体问题，这个技术是怎么解决的。这时候去看官方文档，它们的文档要是写的稍微好点，你会发现你甚至轻易就能背下来。

至此，妈妈再也不用担心我学不动了。

路的尽头

最后一个话题是前端开发这个职业，未来会是什么样子？

我前段时间有一年多把大量时间花在了一个叫做“Primus”的项目上。这个项目是一个类似阿里“云凤蝶”的项目，一个前端低代码开发平台。目的是希望产品经理、后端、实施等非前端人员也能很方便创建前端项目和页面。我认为这是前端开发未来一个重要的方向。

从技术更迭上讲，微软很早就在.net上几乎完成了这种更迭，从写代码到低代码最后甚至到无代码。从目前常见的流程来看，开发后面的两块已经有很多公司出现了“平台化”的做法，也就是测试平台和运维平台。接下来一定是开发平台化，产品经理和设计师在开发平台上就能开发产品了。

再往远看，平台化之后一定就是智能化。目前已经有大厂们在尝试了，比如淘宝的智能切图。未来的前端开发很有可能会被AI所取代，我们的出路很可能是作为前端专家去开发和维护某个智能平台。

这只是我一些美好的愿景和幻想而已，但路漫漫其修远兮，诸君共勉吧。

截止到当前的行文时间，“云凤蝶”目前只支持创建移动端运营页面，还不支持创建PC端的管理页面，但他们闷头做了很久了，相关文章也出了很多，就是不开放出来让我抄一下...

结束语

好了，终于结束这篇没有任何干货的文章了。这些观点实际上并没有任何依据，我也不善于引经据典。也请一定不要认为我的这些观点就一定是对的或者合适的。我只是期望通过这种漫无目的的探讨，能够引起读者的思考。如果能对读者有任何微小的帮助或启发，我将不胜荣幸。感谢！