如何成为前端架构师?

从一个前端工程师,如何根据目标,制定计划,前端架构师需要涉及哪些知识点,还有哪些知识点是前端工程师所不具备的。希望知友提点。
关注者
933
被浏览
319,937

31 个回答

随便说说,我也不知道自己算不算架构师,不过公司开新项目都会叫上我参与前期的一些基础工作,指定一些规范之类的事情,不过前端的项目做过的大的小的,半路接手的,从头开发的也有少说10几个了,我聊聊我眼中的前端架构师。

1,知乎有很多标准的前端架构师,他们身上你如果细心是能够发现共性的,我比较认同的有winter和贺师俊还有张云龙这三位。其他没提到的可能我不太关注,知乎高手很多,但是能达到架构师的其实不多,最多算是高工,或者某一领域专业的牛人,我觉得就像前3位提到的大神,他们的编码能力过硬,算法能力,计算机基础知识都没的说,许多回答都是干货,有理有据,show me code风格的,而且解答不会模糊,直接简要,能做到这些必须是肚子里有货,我觉得这算是硬件基础。

2,编码能力好,熟悉各项标准,算法好,API熟练,就能成为前端架构师了么?不不,这些只能说你是个高工,你说你自己写了许多框架和开源包,各种功能,前后端都有?no no no,也是最多算是高工而已。至少我是这样认为,为什么呢?因为你踩的坑决定了你架构的能力,你的硬件基础只决定了你遇坑之后的解决能力。

打个比方,前端工作3年,一直在电商领域,或者一直在做sns,或者一直在做webview里的开发,这种经验是不具备前端架构能力的,什么?都是写js?没区别?错了,你让一个写了3年电商框架的人去写一个斗鱼tv或者搜狐视频试试,写是能写出来,但是选型问题真不会是最佳,因为他踩的坑一定没有专注这个领域的人多。什么是架构能力?其实说白了就是帮助最后项目顺利开发完成,易扩展,好维护,有规范,能解决一些刚开始人看不到的麻烦。这些能力都是从一个一个真实得项目中锻炼出来的,而不是说只做了一家公司的一个项目之后就可以说自己是前端架构师了。。

说的比较乱,其实简单比方就是个经验包的问题,你的经验比你的技能更大的决定了你的架构能力。

3,沟通表达能力,这个其实不是特别重要,但是单独拿出来说,就是因为如果你的想法不能在团队有效的执行下去是不行的,你必须也一定是最后说服团队使用你的方案的人。

所以最后,回到up主问的问题上来。

从一个前端工程师,如何根据目标,制定计划,前端架构师需要涉及哪些知识点,还有哪些知识点是前端工程师所不具备的。希望知友提点。

没什么知识点,你必须对你要做的东西有经验,至少是做过1-2次(公司级项目),这才是架构师的价值,如果你根本没做过同类的工程,你有什么资格去架构他呢?现学现研究那只是高工而已。

至于题目问的如何成为一个前端架构师,我觉得那些已经被很多人叫成前端架构师的人,自己都不觉得自己算是吧,只是入行久一点,活的长一点,经验多一点,做的项目杂一点,跳槽次数猛一点,比你努力一点而已。

^_^

首先,前端架构师肯定是掌握好基本的前端技术基础的,正所谓一转多长,首先你得先精通一门,其次,掌握前端技术的同时,还要了解前端技术之外的技能。跳出前端这个思维,才能看到的更多。总结起来有以下几点:

跨界

如果你只会写前端页面,那么无论你的功力练到多么炉火纯青的地步,那么也只能称为你是一个HTML高手?。

真正的架构师是需要有跨界的能力的,随着技术的持续完善,这种通过岗位变迁实现技术架构升级的情况会越来越少。而架构层面新的变化将来自于岗位自发的对自身工作内容、职责的重新定义,也就是这里说的边界。所以说并不是你作为一个前端开发岗位,你就不能干前端之外的事了,要尝试跳出边界来思考和解决问题。

页面的秒开是衡量一个前端优化的重要指标,我们以这个优化点来总结一下从哪些方面跨:

  1. 提升速度,从服务端渲染着手,可以利用Node.js往后端跨。
  2. 提升移动web的H5页面的启动耗时,从webview着手,利用iOS和Android技能往客户端跨。

用户交互操作体验,也是衡量前端优化的重要指标,我们以这个优化点来总结一下从哪些方面跨:

  1. 提升用户交互体验,尝试将web页面客户端化,基于React Native或者Weex,也可以往客户端跨。
  2. 提升页面动画效果,编写高性能的前端动画,也可以往UI动效设计跨。

合理的跨界,可以让架构师对于业务的整体有深层次的认识,针对各种问题可以提出非前端之外的解决方案。

尝鲜

技术是不断发展的,作为一个架构师,不断学习新的技术是非常重要的,这里所说的尝鲜,就是要对技术保持一定的热情,不能只满足于现状,说白了讲就是要不断的学。

  1. 习惯了jQuery开发页面,不妨试试Vue,React。
  2. 写了很久的ES5代码,学学ES6也不错。
  3. 沉醉在HTML,CSS,JavaScript开发页面,不妨学学Flutter。
  4. 打造高性能的Web App,试试Service Worker。
  5. 从HTTP协议触发,改造升级spdy和HTTP2,尝试一下HTTP3。

上面列举的尝鲜技能,是完全可以从一个前端的角度触发,来不断深入的,保持对每一个新技术的求知欲,是一名架构师必不可少的。

工具和平台化建设

只会写代码的程序员只能叫码农。

当技术达到一定的高度时,能够为业务再次提升的能力就会逐渐变少,那么我们不如跳出技术本身,来改善业务周边的工具平台,同样来为业务服务。作为一名架构师,要有这种能力。

提到工具平台,大家很快就能跟自己的团队里面的一些工具联系起来。这里主要跟大家探讨一下,我们的工具体系要用什么的思路去规划和review,也看一下我们还有那些可以进一步去完善的点。

为了通俗一点,同样举几个工具平台的例子:

  1. 针对开发调试,需要有一些提升开发效率的工具,例如移动web常用的Fiddler,或者是小程序模拟器。
  2. 针对性能检测,需要有一些能够进行压力测试,发布后线上回归测试的工具,例如腾讯wetest等。
  3. 针对统计分析,每个业务都需要能够提供给产品人员观察数据的工具,当然由于数据敏感性,这里一般每个团队有内部的工具,对外的类似工具例如Google分析等。

可以看出来工具平台主要就是围绕我们的研发流程中的每一步关键节点去建设起来的,结合起来说,我们可以称之为工程化。工程化是这几年非常热门的概念,对前端来讲也是一个很明确的前端发展方向,其实工具平台的完善过程就是架构工程化的推进过程。

身为一名架构师,你需要有敏锐的嗅觉来洞悉这些节点。并且在适当的时机能够做出对业务有提升的工具平台,要做到遇到重复性的问题时,想想是不是开发出一款自动化工具平台来处理,这才是代码之外对业务提升解决方案。

流程和规范化

身为一名架构师,对流程的制定和规范,是非常重要的。不要小瞧规范的威力,可以极大的提升开发效率,真正优秀的规范不会让使用者感到约束,而是能帮助他们快速定位问题,提升效率。

这里的规范,总结起来可以分为成:

  1. 结构的规范:对项目的代码结构,不管前后端,合理的分层和组件化是非常必要的。
  2. 编码的规范:这里主要就是代码codereview了,定期的进行codeview的同时,最好可以使用一些自动化工具。
  3. 流程的规范:项目的评审,研发,测试,发布这些阶段都需要有流程来约束,这些需要结合自身团队的实际情况来制定。
  4. 规范的落地:对于规范来说最关键的是执行落地,在制定完规范的同事,要不时的回顾是否切实的落地,这个应该是团队里每个成员坚持的基本准则。

方法论

所谓方法论,可能单单说起来是比较抽象的,这里的方法论,主要是指在完成一项小的需求,或者是承接一个重大的项目,在具体的实施过程中,要有一定的方法和技巧,相信大家都看过《穹顶之下》这个视频,就是很强的方法论体现。其实说白了将就是做事要有套路。

在性能优化时,我们如何证明优化是有效果的,可以采用“三明治法则”(自己起的名字?):

  1. 首先优化前,我们需要找到问题的现状,并且要有数据能够佐证优化前的状态。所以就要学会去收集数据。
  2. 有了数据之后,我们在进行对数据分析的同时,就需要找到问题出现的原因,并且付诸实施解决。这个阶段,就需要记录具体的优化原理。
  3. 优化之后,就要想方设法去验证,并且在验证过程中,同样需要收集数据。

到此,我们就有了 优化前数据,优化的原理,优化后的数据。通过数据对比,我们就可以很轻易的去佐证我们这次优化是有成效的,并且可以做出一份很漂亮的总结,作为一名架构师而言,这是一个很好的树立威信的场景体现。

我们可以在发散开来,上面的三步骤可以再次迭代,也就是说,第一次优化,我们达到了效果,但是深究之后,还可以再次进行优化,每次优化都有数据佐证,这就是性能优化的方法论。

安全意识

这里为什么要把安全单独拿出来说呢,因为对于一个业务而言,安全是第一要素,就好比一个国家,安全稳定才是发展一切的前提,一旦业务出现安全问题,就可能瞬间损失掉全部,代价是非常惨重的。所以作为一名架构师,必须要保证业务的稳定性,可以总结以下几点:

  1. 对低级的的代码安全问题,要坚决说不,例如前端里面的xss,csrf这些问题。
  2. 对大型运营类活动需求,要有容灾意识和备份,例如在准备了一套方案的同时,要有可选的备用方案。
  3. 尝试使用工具化来解决和预防安全问题,例如BAT这种大型企业,在运维和代码层面,都有一层保障机制,如腾讯的门神系统等。

团队合作

没有完美的个人,却有完美的团队。

即使是一名架构师,我相信他也不是一直在一个人战斗,一个优秀的产品业务,总是诞生于团队,所以时刻保持和团队人员的沟通是必不可少的,这些沟通不限于日常的文字,或者会议,甚至私下的团建活动,都是可以相互了解的。

所以团队合作的目的就是让团队中的每个人都能明确自己的职责,并发挥出最大的价值,架构师有义务来维护这种合作关系。并且对你的认同,也是团队成员赋予你的,维护良好的氛围,才能让团队成员信服。

最后,总结一下,对前端架构师理解的一些误区:

  1. 架构师并不等于全栈工程师。
  2. 架构师切记完全脱离代码,但是也不要一直闷着头写代码。
  3. 架构师应当跳出技术本身,从全局的角度来看的业务,发现并解决问题。
  4. 任何项目的架构都不是一开始制定好就是一成不变的,他应该是不断迭代和演进的,架构师有义务来保证架构的创新性。


愿各位在成为架构师的道路上一帆风顺!