快手大佬讲述:怎么看前端的定位与价值?

242 阅读7分钟

背景

伴随着各大互联网公司的“降本增效”“去肥增瘦”,技术人的发展也逐渐从原有的技术领域,延伸到要去应对更复杂的场景;公司层面上不断要求技术人们要有更多的业务视角,工程阶段上,也要有更多的探索和突破,进一步的提升质效,作为一个技术人,我们要何去何从?

技术 vs 管理

首先天翔介绍了自己不是那么寻常的发展路径:

2017 年加入快手后,先后负责了游戏直播,业务中台、小程序平台、CNY 春晚活动、激励、PC 站、容器建设等等一系列业务。对于业务架构,工程架构、性能优化、全栈、跨端等角度有着较多的探索和实践。

天翔应该算是比较少的从纯管理主动回到了技术管理岗位的同学,他主要是通过了对于自己优势的思考、个人价值所在来明确了自己的定位,最终做出的选择。

他认为这样的调整让个人与公司和团队实现了共赢,技术 or 管理是个人发展到一定阶段实现自己价值的表现方式,不能是一个定式。而随时的思考,去发挥自己的优势,思考真正适合自己的定位是更重要的。这能在我们在当前的生态下获得持续的正反馈,让自己的价值得以体现。工作也顺心、有获得感;对于公司而言你的价值又优于同水平基线,激励少不了;对团队来说也能更融洽快速的发展。

简而言之,通过俯瞰自身做出变化,从而去适应环境。

前端的定位与价值

国内终端方向同学的发展有这样一些特点:

  • 业务场景多,需要支持的方向较多,对应到的就是期望你掌握的技能点较多,且部分业务比较短平快,做事可以说相对是比较琐碎的,也是期望你可以进行一个持续学习吧。
  • 随着个人能力的增强、行业经验的积累,不少人都是从纯技术走向技术管理再走向纯管理,客观的来看高级的纯技术研发同学占比是比较低的,这也算是研发最终需要服务于业务,并在业务发展中体现价值的一种表现。

前端,不仅仅是画个页面,天翔以自己的发展路径为例,介绍了前段工程化方向的发展:

定位:工程化能力的建设者,设计架构基建能力的开发。

价值:业务上,辅助业务持续快速落地,降本增效。技术上,提高开发者的工作效率,降低项目维护成本。

天翔认为工程师最大的目的还是效率的提升,个人价值的最终的表现可以狭义的说是在某个方向上,突出了自己的专业性与不可替代性。

小程序平台建设

小程序的出现有着明显的商业诉求,因为马太效应,一些超大流量的App诞生了。这些大流量App集成了许多功能,但显然公司再多员工,也无法所有功能全是自己弄,于是产生小程序这种“外包”的手段。

小程序算是国内前端技术的一次厚积薄发吧。一开始底层运行的迷你React的虚拟DOM, 内置组件是使用Web Component,API来源于Hybird的桥方法,打包使用webpack,调试台是Chrome console的简化版, WXML、WXSS的语法高亮也应该是webpack或VS Code的插件, 模块机制是Node.js的CommonJS……其中最值得一提的是微信开发者工具,以后开发者工具成了各种小程序/快应用的标配。

而技术上大多是需要考虑以下方面的问题:

最终,会形成一个很庞大的架构全景。

这个全景,其实一开始就是把各家的能力做填空题放到了这里。当时团队的规模只有12个人,怎么完成这么大全景的研发呢?

Follow! 抄!一开始去对齐wx平台的能力。

深入理解小程序的定位,目的就是减少工作量。

关于运行时的开发

小程序像是类似于RN/Weex这样的一种跨端形式,在语言层面大家都可以是类似的,主要不同在于底下渲染实际发生的位置不同、通信方式不同。如果能找到一个机制,使得能复用当前RN|Weex的设计的话,就可以大量降低开发成本,最终他们觉得,从语言表达能力对等上来看,Vue是能cover住小程序的,他们的设计就是将小程序的DSL翻译成VUE的DSL,再将微信小程序的api与Vue的进行对等操作,通过自己再实现一些方法来磨平差异。接下来将组件树同时注入JS虚拟机和WebView里,再通过通信的上的时序保证,使得能在当前运行时里去维护双组件树。那就只需要去关心双组件树之间的逻辑,也使得Vue下Compiler、SFC,Volar这些开源能力可以被直接使用。

关于编译器的开发

关于编辑器:最低优先级,抄抄就好,能不太投入就不投入。

关于模拟器:需要在electron中找到方法对等小程序、native渲染,没有作业可以抄。

关于调试器:早期微信调试器是自建协议的(...没抄明白)。后面调研了chrome开源了自己的cdp协议,通过各种dom的标记位来实现,这里最终调研后返现只需在最终渲染的dom结构上进行对应的各种标记就可以复用cdp协议,从而进行了二次开发。

最终,只花了一年半的时间,大体对齐了小程序的生态能力。

大型活动建设

关于活动建设与开发思路上如何去做?

  • 人力较为紧缺,每个会场只有3-4个前端人力
  • 不可避免的产品需求变更
  • 产品要求高,要把所有能看到的玩法进行整合。
  • 交互视觉同学,既要又要还要

总结了两点:

  1. 如何对工程能力进行约束,沉淀出解决方案(动效平台、组件市场、渲染器、场景编辑器)、类型约束。

  2. 如何对业务上游协作方进行约束,节点从多到少、流程自动化。

团队建设与未来发展

最大的挑战不来自技术本身,而是来自该如何通过更加高效的组织力来进行业务的交付。

  • 员工思维:这个事应不应该做

  • 员工能力:这个事能不能做,怎么做

  • 员工治理:做了事后思考其价值

管理是没法去推翻人性的,人利己是很正常的,希望在利他的基础上从而利己,这些需要在管理手段上做出引导。

  • 纵向职能视角:业务理解,需要了解上下游的痛点,理解他们的诉求,在开发中花时间最多和最有收益的部分是去当业务的翻译官。
  • 横向职能视角:具备跨领域知识,具备更大的技术储备。当机会来到你面前的时候能把握得住。

随着职级的上升,技术能力的占比逐渐下降,但是技术能力要求的绝对值依然是单调上升的,只是说其他方面的提升速度更快(管理能力,产品scene),要求更高。(1和0的关系)。