微信扫描登录
或者
请输入您的邮件地址来登录或者创建帐号
提 交取 消
GITBOOK.CN需要您的浏览器打开cookies设置以支持登录功能

Rank:大前端的前进之路
作者:Chat 实录

11月30日周三晚8点30分,GitChat团队开启来自美团技术高级总监,大前端技术负责人Rank的直播交流,以下是主持人英子将交流过程重新整理,记录下的分享者和用户之间对管理前端到客户端的经验等话题问答的精彩片段。


问:RN的方案不用,你们现在用什么方案,还是没有特别统一的方案?会考虑weex不?

答:会考虑。有大型稳定的商业生产环境使用 weex,我们再用。对于轮子无明显倾向性。

现在我们用 css-layout 解决了客户端因样式(View)改变而需发版的问题,可用后端的活动与模板配置拼凑完成下发 DSL 就能出界面,相对轻量。做的出发点是我们使用过 RN 的实验后,不适用也不好用,最后基于当前业务形态的选型决策。


问:文中提到了要三端掌握精通一端,那么对前端来说最明显的应该是精通前端,熟练掌握安卓和iOS。这种情况,对安卓和iOS需要掌握到哪些程度,可以达到理想水平?

答:理想是都很精通,当然需要长时间。也与个人想达到的水平与目的有关。多数场景下能和 Android/iOS 一起讨论技术方案(非技术细节)并能理解各端不同领域方案原理,就已经不错了。

例如,PUSH(推送消息)是属于客户端的典型应用,iOS/Android 的不同。iOS 需先获 token,再通过 Apple 自建 apns 通知用户。这样的架构在于,问题容易出在「业务服务器」与 「apns」 连通状态。那需要了解如何优化。

Android 因为开放的问题各厂商的 PUSH 都不同,还有专门的进程在客户端用于推送。核心问题在于如何保活进程,与长链接稳定性与时效性。需要多精通,就按这样结构化的方式分析与理解,结构化,找重点,再深挖。


问:假设到达了理想水平,而目前不论是RN或者weex,都是前端主导开发,端上调试底层接口和前端联调。不过无论从文中还是自己体验,都觉得这种模式以后可能会挂掉,那样的话,精通三端的人工作重心应当放在哪儿?

答:在我理解来看,了解三端后,那一定不是孤立看技术问题了,那要求以业务角度去发挥前端技术价值的问题。

举个例子,客户端上很熟悉热补丁技术。如何将提升热补丁的到达率(即时性),并看到它是否补好?需要和前端监控一起讨论,还需要实时化,那是不是也可以给监控提些建议与要求,实时化监控,并且能做补丁到达率监测与效率评估。如果熟悉三端技术的话,自然从团队角度希望你一起负责热补丁以及数据监控了。

重心上就上面的问题,非新手不能选择;而高工可以选择做什么和怎么做。


问:我对游戏也挺感兴趣,如果Rank对游戏也有兴趣,可否从大前端角度,说说前端技术与游戏有什么融合点,毕竟走到最后技术都是相通的,可否能站在某种高度,可以同时掌握这两种开发技巧,而不是花两份功夫同时学习。

答:我对游戏领域关注并不多,但可以分享些信息。青瓷引擎国内来说做得不错(开源的),WebGL 相关的技术。我也和主程很多年朋友,是财富自由后去追求技术理想的一群人,技术特别出色,引擎性能也很出众,我认为是国内现在纯 Web 上做得最好的了。网址是:http://www.zuoyouxi.com/


问:问个别人经常问的,我初入前端,学得不太久,感觉CSS、JS、HTML还有各种框架信息量都很大,看知乎大神们对精通前端有不同的定义,Rank怎么定位精通前端的?

答:百科词条「精通」:透彻理解并能熟练掌握。

  1. 10000 小时定律的持之以恒;
  2. 有意识有方法「刻意」学习前端这个领域;
  3. 熟知前端技术历史、原理,并能自如应用在业务开发当中,有效提升工程效率与用户体验。

之前的回答如下:Implementers(按部就班执行任务)、Solvers(独立自主解决问题)、 Finders(自己发现问题)。

这也是从不了解到熟悉掌握之后的几种状态,也是我认为理解熟悉与精通的路径,最后的「发现问题」就是理解「为什么」(Why)的过程,Why 是个哲学问题,有时一辈子也想不清楚,也是「比较作死」自己的事,看苏格拉底就知道了 。


问:老师作为大前端Leader,日常主要关注什么呢,工作内容有哪几块?

答:我现在的工作内容有点杂。工作是个大 T 字型,横向是技术的大前端,纵向是个垂直业务负责人,团队也都有一定规模。即除了大前端的 Leader 之外,还要管业务的(产品、前后端,包括测试等技术、运营),所以一周工作时间五天对我来说时间很紧。需要动态 cosplay 切换各种不同的角度理解,并针对性地提出问题讨论。

因为时间相对没这么宽裕,所以我在大前端的主要工作是:

  • 技术规划、Review、分析重点技术项目;
  • 在每周都有例会看进展,识别关键环节与问题;
  • 针对具体项目展开讨论会与 Reivew 设计;
  • 参与到产品讨论会,判断业务趋势,提前看技术做哪些工作能加快迭代效率与质量,并如何驱动业务的发展。

还有很重要的一点,要不断学习新的技术与读书(这里感谢图灵每月赠予新书)。


问:最近在调研三端统一的问题,比方说RN,感觉最难处理的还是CSS这块,RN的样式这块较之CSS只能算一个很小的子集,所以不论是有Web先行,还是Native先行,CSS都会是一个无法绕开的大坑,有何建议?

答:不管是 RN 还是 Weex,一定会对布局有所折衷,是必要条件。简而言之:有硬伤,动画及复杂布局不要简化。


问:后端在前端的道路上走得很辛苦, 前端技术栈非常多,而Bootstrap做出来的没有那美。有什么好的建议吗?

答:我的经验是,后端转前端最痛苦的不是 JS,是 CSS。结合个人特点,如果对体验上还没有那么敏锐也可以前期重在 JS 栈上。先在React/Vue/Angular 「基于业务场景」里先选一个去实践比较重要。


问:Web端转大前端管理,如何平定Android和iOS的老人(包括:原来平级别的管理者,如果有),与之建立良好关系?

答:我理解是升职之后管理原来平级的问题。建议是,尊重所有历史的成果(不充分了解上下文与历史前,不评价不批判,先肯定)。

管理原则:有情、有义、有道理。对所有团队的产出负责(这很重要)。

不管大公司(BAT)还是小团队,结论是管理风格不是关键问题。特别宽容特别 nice 的人,应该很会「和稀泥」,团队成员很舒服。(Family 型)像我这种要求团队严格,平行团队宽容的也一样有空间(工作要求专业型)。

实在的一点就是,要替别人考虑这些:职称(成长),没天花板(空间)和钱(加薪)。怎么做,关键在带团队有结果(技术产出,团队影响力,业务配合的认可度)以及对团队真诚,对事不对人。

月影:有情有义有道理挺好,管理很多时候也归结为四个字“将心比心”。


问:你好,我也问个问题:开始Android开发一段时间了,想往中高级进阶,可以从您自身的进阶过程或招人所需要的技能,谈谈Android或大前端该如何进阶中高级开发吗?

答:

enter image description here

我给团队内部都会采用这个图。

上面更细点的我先找找,有可能找不到,所以先可以讲的就是(有过一个最能体现技术价值和难度的项目,比如模块化的dex加载之类应用,越细越好,Hotpatch使用与分析,也是越细越好)。


问:现在前端技术更新如此快,如何把握核心技术,或者说前端的核心是什么?

答:前端的核心我也一直在思考,可以一起讨论,我认为三点:资源管理、团队协作、用户体验。

例:Web 端就一直在做资源管理的工作,缓存,差异化更新,都是这个。团队协作,MVVM,前后端分离,我认为本质也是这个事,愿景与目标是希望业务上加越多的人,就能做更多的事。

玉伯王保平(阿里前端技术负责人):前端的核心是对人机交互的理解与技术实现能力。

答:玉伯提得很对哈~,我统一认为是在用户体验这块的理解与实现上了 。

玉伯王保平:尽量不要提前后端分离,更合适的说法是前后端分层,软件工程就是不断分层合理化的协作过程。

月影(360前端技术负责人):我认为是前端长期的发展中总结出一套处理用户UI和人机交互的方法论,并且这套方法论也在不断进化。然后这套方法论其实不止可以用在前端。前端领域也不等于可用前端思想解决问题的全部领域。


问:对于现在前端技术栈,是全家桶好,还是一个框架解决问题?

答:小团队我建议全家桶就行了,高效、可控。像分BG、BU的,Web 端发展很难全家桶。客户端相对更容易全家桶,并且我也倾向于全家桶。原因是Web 端更轻,客户端更重。


问:请问,随着设备的性能逐渐提高,对基于Cordova的WebApp的未来如何看待,是始终只能做一些简单功能,还是说可以逐渐替代世面上的大部分APP。另外对于Google的PWA技术如何看待(Progressive Web Apps),会是移动设备上WebApp的一个重大方向吗,特别是在安卓设备上?

答:如果 Cordova 想替代 App,那在目前看还太早了,只是个愿景。

各大厂不用它做容器,但都有自己的 Web 容器与类似 Cordova 的混合方案,因为 Web 内容在客户端都起到非常重要的作用。就我经验看,现在电商客户端里约 20%~30% 用 Web。

PWA 是否成熟与趋势问题,从另个一个角度看:为什么苹果不做类似的事。我个人认为是 Google 是基于 Web 起家,对 Web 一直有历史基因与情怀(其实百度也是如此,像轻应用)。所以有点一厢情愿的意思,技术上也还为时过早。Web 垄断思想就像跨端思想一样,会不停地创新和试错,但我认为不会一统天下的。


问:关于对大前端的技术栈,您觉得是大统一好还是百家争鸣比较好?对于文章中讲到的T型人才,应该就是团队培养人才的目标,那么有对这个培养路线做过规划吗?具体的路线想了解一下。

答:我的观点是垄断是创新的杀手,对业界来说百家争鸣挺好的。对公司来说需要做到平衡。3人团队一个技术栈就吃不消了,2个BG 部分差异化就很正常了。大一些的团队如何判断呢?技术是否可控。用了这些技术是否能掌控好(能学好用好);能持续跟进升级和持续维护;不适用时有能力更替到其他同类技术。


问:文中说到团队抛弃了RN,那么还将RN作为关注的技术栈方向吗?毕竟我觉得这种跨端技术是未来的趋势!

答:会持续关注这些技术,也持续关注国内外最新跨端技术。也会经常与其他团队进行交流。现在不用 RN,是不适用和不好用。


问:可能这个问题有点儿脱离文章,加入咱们团队后,一直觉得自己在时间管理方面很弱,感觉每天去推动,去沟通浪费了不少时间,请问一下在业务需求多的情况下,如何有效管理自己的时间,有没有什么诀窍经验传授给新人,这个问题一直想问大牛们,谢谢。

答:管理时间有太多的技巧和工具,但我觉得大多数时间管理的根本问题不在方法,而在于如何「能识别」重要的事。其次是如何将把重要紧急变成重要不紧急,让自己更从容应对工作。最后对自己的要求是:「自律」、「专注」还有「习惯」。一天少刷微博和朋友圈可以省出不少时间;信息爆炸的时代选择不看什么比看什么更重要,专注在真正重要的事上;每个周期时间点学习很重要,不管有多忙。

与其说管理时间,不如说是管理自己。


问:从技术转管理的话,因为一开始管的人不多,所以技术和管理要一起做,但是一开始管理没有经验,花费了很多精力,但是又怕技术方面拉下,如果管理方面投入精力不够,这方面进步有很慢,请问这两方面如何进行平衡?

答:技术和管理都是需要在「积累」之后才能融会贯通的,但这需要时间。又想技术继续深挖,又想把管理工作做好,还能出成绩。唯有一条路:只能是你比其他人更忙,更高效,不断总结属于自己的高效方法,做重要的事,这是我认为最笨也是有效的路。

那些比我们聪明得多的互联网,管与 CEO 都是早上上班比咱们早,下班比咱们晚的。


问:Rank能展望一下几年以后前端的工作方式和需要客服的挑战吗?

答:客户端如果不用 Web 是否还有更快的迭代方案。

业务迭代越来越快,框架会越来越重,人越来越多有没有更好的框架来解决大规模前端团队的复杂交互与界面开发问题。


问:Rank对现在部门内的前端人员是怎么样的一个要求,业务方面和知识栈方面?

答:高工我本人提倡 T 字:有专业领域积累与判断力,还能学习并结合其他领域的知识,发挥前端技术价值。

新人就具体技术方面,可视化技术、React、语言基础知识(OC Java JS)、操作系统、数据结构。

软素质与做事方法上要求高工做事有规划、有逻辑、有重点、有落地产出。 新人做事认真、踏实、正能量、专注。


问:对于手机端软件的持续集成工具你们主要用的什么?

答:现在主要用 Jekins 系统集成,也有人做了一个类似 travis CI 一样的项目,后期可能会迁到后者上来。


问:我看到文章中有说到前端在客户端Crash的时候无能为力,只能供工程角度上查问题。因为最近也遇到过前端页面导致App Crash的问题,但是前端常用的查看内存,CPU等方法,看不出任何问题。客户端也无法排查出问题的所在。您能分享下前端在客户端Crash的时候能采取哪些措施排查和解决问题吗?

答:没有具体的 case。能复现,二分法 debug;不可复现,通过现象与聚类分析出来的内容,根据既有知识经验来分析逻辑和诱因;就客户端 Crash 一般是线程与内存问题,Webview crash 更复杂一些,除非超负荷大面积用 Webview,否则不会成为主要 Crash 的问题,一般用 Webview 比较多的电商业务中因 Webview 出现的 Crash,不在 TOP 20,如果有大面积用在 Android,建议统一换 Webview(例如 X5内核) 也是解决问题思路之一,像目前我们有些业务已经直接用 X5 了。


问:从前端Leader到负责整个大平台的工作转变过程中,就自身而言,您觉得最难的是什么?同时,我作为一个初级纯技术如果转变为管理者后,对于满怀技术信仰的我,还是想要把更多的时间放在技术研究上,对于我这种看法,您有什么建议或者意见呢?

答:敢问。对于不了解的领域敢于承认不懂,也敢于问(这不是谦虚,是真不懂)。当在原来专业领域有影响力时,拉不下面子显得自己傻逼,需要自己过自己那关。学习这事要敢于厚脸皮,也需要自己恶补,到目前为止我平常也都还在补看一下客户端方面的知识。

我认为应该在码了五六年再考虑管理团队的问题。在这期间可以指导人,但不以管理团队为主线。初级纯技术转管理,一般是业务或团队需要,但被「催熟」后遗症很多,典型的问题就是后期技术缺乏判断力,需要专门配一个这个领域的技术负责人的角色。

国外很多管理者都是做了将近六七年的技术,也做过很多业务才转管理的,管理也在业务与技术的洗礼中累积起来了,对技术都有相当好的技术判断力。


问:想问下平川老师,从管理一个端的团队到管理一个业务团队,有什么要注意的点?

答:首先要承认,业务负责人这事比技术复杂很多。业务像个魔方,光一面拼好是远远不够的,往往拼好之后还需要打乱原来整齐的部分再来过,最后才能达成目标。

从决策方向的重要性来看,业务负责人是车头,技术是引擎。车头方向错了引擎怎么卖力怎么牛逼,对业务结果相当于无用功。

从技术人员到业务负责人,遇到的问题一定会特别多。在公司里转型最难的是,如何从零到一理解「业务」,理解用户,理解需求,从而能做到决策方向与制定策略。这时还需要有快速学习能力,提升自己的产品能力,像信息化解构、竞品分析、行业信息获取与分析、数据指标理解分析、综合多职能管理能力,一开始让人使不上劲,有点懵逼。如果还有销售环节,那更是两眼一抹黑,种子客户是哪类人,从哪个渠道来,怎么触碰到这些渠道的资源,怎么卖,怎么面试销售?

此外,要领着业务往前跑,业务没有增长点和起色,所有团队的活力值就会下降,研发可以阶段歇一会,业务负责人不行。在外部创业更复杂,除了找人找方向还要找钱。变数多,有可能你融资到了,晚了几天,团队坚持不了散伙的。

总之,作为业务负责人,要有坚强的小心脏。会常伴随危机感与焦虑。在不确定性的情况下能找到并满怀希望,心情像过山车,今晚感觉业务可能快黄了,明天某件事又让它你充满信心。


问:我想请平川老师再谈一下所谓的 T 型人才,往往针对的业务会比较专,如何培养发展成 T 型人才?T型人才在大公司里面是否有真正的独特价值?

答:业务专指的是没有太多的机会接触其他端的技术吧。前几年新参加工作就自己领域的内容就够消化的了。所以先在自己的圈子里做好,除此之外,工作之中太多机会接触自己领域之外的技术了。比如说最常见的 DNS 劫持大家都遇到过吧,稍微想一下怎么快速识别是 DNS 劫持,这样就可以了解运维和端到端监控方面的内容;而客户端可以做 HTTP DNS 来解决劫持的问题;这就了解客户端的实现解决方案。大意就是不仅要闷头拉车做业务,也需要主动思考看路。

T 型人材独特价值指的意思不是特别能理解,我说的现代 T 型人材,不是价值和钱的问题,是有钱都找不到的问题,这样的人是高潜......

Chat实录:从前端 Leader 到客户端 Leader


在此感谢图灵,为本场Chat的获奖读者提供了以下书籍。

enter image description here


enter image description here

enter image description here