2018年的前端架构师都在干嘛?
前言:本文整理自自己在知乎问题《2018年的前端是否有『架构』可言?》的回答。据说是有掘金限量笔记本可以拿,于是很没骨气地整理成文章发出来。如果大家也喜欢掘金的笔记本,也来发文章哦。
皮一下
一,明确下架构的定义,在知乎的这个问题中,题主说“整个后端的架构是非常复杂和庞大的,一个好的架构师需要在数不清的方案组合中进行架构选择”。看起来架构似乎是一个在无数方案组件中做选择的问题。
所以,如果回答“前端的方案组合很多,所以架构也很麻烦”,是否就可以回应这个问题了。那么,前端方案组合多吗?确实是多如牛毛吧,比后端多很多很多吧。
以上是牛角尖。
一、关注点
后端架构的目标,题主也说到了,高性能、高可用、可扩展、安全。
至于后面说的那么多知识点,虽然都是有用的,但是不免有些掉书袋了。高可用有各种难点,有各个方面的高可用需要关注,但事实上,后端经过这么多年的发展,尤其是海量用户场景大量出现以后,这些问题的解决方案也都非常明确了。如果不明确的也是业界公认暂时无解的问题,例如分布式CAP等。至于其中碰到的具体问题的的具体技术上的策略,如果还需要自己从头去想,那这个后端工程师(还不叫架构师)应该是不合格的。我理解,做后端的架构其实基本上是在前人整理过的各种场景的解决方案中做选择。
那么前端呢?目标也是高性能、高可用、可扩展、安全吗?所以只要数据库不用选,语言不用选,框架三选一,架构就简单了?我认为这是对前端的关注点理解不到位的体现。
二、前端的核心关注点——用户
作为前端工程师,关注点是什么呢?首先就是用户,包括用户侧的操作和用户体验。
例如一个界面给到用户,比如报错是红色文字还是输入框变红?Loading放顶上还是页面中间?用户点击提交后按钮显示Loading还是灰掉?转菊花还是骨架屏?先显示占位图还是先白屏?
再比如用户访问我的网站快不快,用起来爽不爽,会不会觉得卡,会不会觉得low。这些东西会决定你的页面是单页面还是多页面,URL如何设计,加载策略是什么?
我认为这些才是前端最该关注的东西。
所以我做的架构一点都不高大上。仅仅是决定如何让网站加载更快,如何不引入不必要的代码,把不必要的代码干掉,如何让用户加载最少的内容,如何让用户最快看到效果,前端渲染还是后端渲染,同步输出还是异步输出等等。
是不是觉得一点都不是架构师干的事?但前端构架师确实就是在干这些事。所以,你要说前端架构师是一个技术上的架构师,倒还不如说是更关注用户的体验架构师。从这个角度来说,前端架构师和跟后端架构师的关注点不在一个维度上。
三、工程难度
题主说,“最多算上错误监控、埋点方案、缓存策略等偏运维的决策”,仿佛这些是一句话可以搞定的很简单的事情。
是,后端错误监控不难,无非try..catch
嘛,再不济进程挂了还有各种运维工具可以救人于水火。但是前端呢?一个ajax
加载失败了怎么监控,一个css
加载失败了怎么监控,再极端一点,浏览器卡死了怎么监控,页面崩溃了怎么监控?
至于埋点,能做得好的我都非常佩服。连用户关闭了你的页面都监控不到,还想通过埋点来获取业务和技术数据?
至于缓存就更奇葩了,到底有没有缓存,到底是200
还是304
还是没有请求了,到底版本对不对,到底有没有被代理瞎搞,到底这个神奇的浏览器是怎么处理缓存的……别以为说一句“加个缓存”,就这么轻轻松松地搞定了。每一个把缓存玩好的前端工程师都值得尊敬。就不说更多的什么localStorage
/serviceWorker
之类的了。
说这一大段,并不是要说前端架构师搞这些很苦很累,你们要尊重我们。而是想说,这些不起眼的事情,不如想象的那么容易,很多时候架构师是在帮助工程师探路或者踩坑,把这些东西的技术方案搞定。
四、面向团队
现阶段的前端工程化还不成熟,这是个切实的情况。架构师在项目选型的同时,有相当部分的精力会放到工程化方案的选型上。是否用webpack
,是否用npm
,是否用TypeScript
,是否用ES6/7/8
,是否要babel
,是否用PostCSS
。是否要CI,是否要自动打包发布。是否要分包加载,是否要抽取CSS文件……
这些事,在后端可能不存在,在客户端可能也不存在,或者即使存在,也被IDE悄悄地代劳了。作为项目的选型者,写几个依赖,install
一下就开工了。但是前端不行,前端这里有大量的工程化选型或者配置/开发的任务。
作为架构师,如何选择一套好用的、没有坑的语言/构建工具,也不容易。
我举个例子吧,大家可能觉得TypeScript很好,直接用不就好了吗?殊不知,TypeScript需要配置tsc
或者webpack
的ts-loader
(现在babel
也可以了),还有tsconfig
文件,以及各种.d.ts
文件。当然,即使这样,也有可能在写代码的时候报一堆无法解决的错误,需要你花大量的时间去研究为什么有这个做,怎样可以不报错(也可能根本就不能不报错)。当你在Vue中使用TypeScript
时,你需要研究怎样让它识别Vue Component的类型,怎样做自动提示和类型检查。当你在ajax
使用时会发现你要研究怎样将服务端返回的数据与某个类型映射起来(然后发现在runtime时毛用都没有)。
前端架构师,也有相当多的精力在这上面。
这是一个好的现状吗?未必,但现状确实如此,这个锅架构师不背谁来背?
五、小结
所谓架构,我理解是综合考虑目标、业界和团队,作为合理的方案选择,既能支撑业务的发展,又能令团队满意。如果能达到这个目标,自然就是一个好的架构。目前来看,前端要做到一个好的架构不容易,做的事情并不比后端少。
至于说前端架构师做的所谓的这些架构的事情是否高大上,那是另一个没有答案的问题。
作者:TooBug
链接:https://juejin.im/post/5b10b00de51d45069f5e0110
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?
1、前言 在IM这种讲究高并发、高消息吞吐的互联网场景下,MQ消息中间件是个很重要的基础设施,它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色,当然MQ消息中间件的作用远不止于此,它的价值不仅仅存在于技术上,更重要的是改变了以往同步处理消息的思路(比如进行IM消息历史存储时,传统的信息系统作法可能是收到一条消息就马上同步存入数据库,这种作法在小并发量的情况下可以很好的工作,但互联网大并发环境下就是灾难)。 MQ消息中间件可以理解一个水池,水池的这头是消息生产者,水池的那头是消息消费者,生产者和消息者无需直接对接,这将带来很多好处:业务解耦、架构分布式化等,生产者和消费者互相完全透明。 但市面上的MQ消息中间件产品很多,作为IM系统中必不可少的一环,我们该如何选型?那么请继续阅读本文。 学习交流: - 即时通讯开发交流3群:185926912[推荐] - 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》 (本文同步发布于:http://www.52im.net/thread-1647-1-1.html) 2、关于作者 朱忠华:主要从事消息中间件相关...
-
下一篇
蚂蚁金服与天津银行达成战略合作,金融科技开放势头迅速延伸
前言 2018年6月12日,蚂蚁金服与天津银行签署战略合作协议,根据协议,双方将在移动智惠银行、互联网金融平台、互联网金融核心系统、大数据平台、分布式架构与技术的建设等银行数字化转型领域展开紧密合作。 这是继华夏银行、光大银行、浦发银行、中信银行之后,蚂蚁金服与金融机构开放合作的又一践行案例。而与上述几家股份制银行不同,天津银行还是继南京银行后,蚂蚁金服的另一家城商行战略合作伙伴。 在最近短短一个月内,蚂蚁金服相继与5家银行建立战略合作关系,并且已经快速扩展至全国不同的区域不同类型的金融机构,金融科技开放势头可谓迅速延伸。蚂蚁金服称,近期还将有更多战略合作陆续浮出水面。 为不同银行定制最佳数字化实践路径,蚂蚁金服金融科技开放迅速延伸 “融则两利,合则共赢。天津银行和蚂蚁金服的合作必然是一个多赢的结果。”天津银行行长孙利国表示,随着金融科技和
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker容器配置,解决镜像无法拉取问题
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- 2048小游戏-低调大师作品
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- MySQL数据库在高并发下的优化方案
- Dcoker安装(在线仓库),最新的服务器搭配容器使用
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题