浅谈:前端如何赋能业务?

简介: 你是否头疼于,每天做不完的需求和改不完的bug?你是否发愁,每天撸业务代码,是否能获得技术成长?而追求成就感的你是否想过,你所编写的一行行代码,是在反复的变化中迅速成为遗留代码,还是助公司插上腾飞的翅膀,在你死我活的战场上脱颖而出?本文会将业务和前端关联起来讨论,探讨业务发展的不同时期,前端所能做的一些事情,既能解业务的困扰,也让前端同学们摆脱码工、切图仔的定位。

你是否头疼于,每天做不完的需求和改不完的bug?

你是否发愁,每天撸业务代码,是否能获得技术成长

而追求成就感的你是否想过,你所编写的一行行代码,是在反复的变化中迅速成为遗留代码,还是助公司插上腾飞的翅膀,在你死我活的战场上脱颖而出?

因此本文会将业务和前端关联起来讨论,探讨业务发展的不同时期,前端所能做的一些事情,既能解业务的困扰,也让前端同学们摆脱码工、切图仔的定位。

千言万语不如一张图,全文完。

大误,还是得详细说说。

一、初始阶段

在业务的初始阶段,在市场定位、用户诉求、产品逻辑已经明确的前提下,此时业务的核心诉求是 『尽快上线』,进行快速验证和产品迭代,当然,质量还得能过得去。
所以此时技术同学的方案侧重点是:

快、爽

先说『』,在这种情况下,什么vue/react都见鬼去,老夫只用jQuery一把梭!
这是反面案例,这样就只能重构火葬场了,项目上线完就打包行李滚蛋……

此时的,指的是 尽可能复用集团/业内成熟的方案、架构,按捺住自己重新造轮子的躁动不安的心情。
这又涉及到一个问题:如何选择一个靠谱的方案?这是一个可以另开文章的话题,但先在此简单说说
根据我个人的经验,主要从稳定性、可扩展性、性能去考虑。

稳定性 如何去评估?如果一个项目能做到这几项,我是比较放心的。

  1. 项目star数多
  2. 有单测,代码覆盖率90%~95%以上
  3. 文档完备,有常见Q&A
  4. issue有较快的处理流程和周期,3天内响应、1~4周内关闭。
  5. 有稳定的版本控制,不进行不兼容的升级,非要不兼容升级的话,将迁移工具做到极致。

可扩展性 如何评估?主要是指能否根据业务or已有技术方案,自定义部分内容。

  1. 例如组件库,是否能自定义主题、组件的事件回调等,因为有的需求,组件除了完成默认的行为,还需要执行其他逻辑如埋点;
  2. 例如单测工具,能否配置白名单,因为有一些代码是兼容特殊场景,编写用例模拟场景的成本实在比较高。这个主要是根据技术诉求和经验进行判断。

性能问题,短期容易被人忽视,因为能跑就行,但一旦埋下隐患,日后有坑就极难解决。容易出现性能问题的地方有:代码构建、长列表/表格滚动、大数据图表、复杂动画、3D全景渲染等,如果所做的业务涉及到这几个方面,选择方案的时候就要特别注意性能。

如果实在图省事儿,create-react-app、umi开箱即用来一套就完事儿了。

』 这个字我的理解是,一款新产品出现,一定需要在用户体验or交互上有绝对领先对手的地方。

一个我始终记忆犹新的例子,就是乔布斯发布第一款iPhone时,演示滑动列表时全场的惊呼,一个乔布斯的哥们说:当你滑动页面的时候我就湿了。

另一个前端领域的例子,就是Ant Design。AntD被广泛使用,很大一部分原因是其出色的视觉设计和动效。至今为止,AntD的官网介绍上仍然说这是一个设计体系。

所以我觉得,一款新产品,除了提供刚需价值,最好在美观和易用上领先对手一大步,虽然主要还是看设计师和产品的功底,但前端同学的实现上至少不能拖后腿,不能加载太慢、滚动太卡。

蓝海市场、刚需产品也许不那么看重这一点,但有的蓝海门槛较低,很快就会转变为红海。

还值得一提的是,账户体系的建设,包括打通三方登录、免登等(客户端登录态透传到h5),网上不少资料,我实在没这方面经验,就不在此多嘴了。

二、快速扩张

OK,假设产品如期上线,数据蹭蹭上涨,看起来一切都很完美。
然后问题就来了,业务开始扩张,公司新招了100个运营和10个PD,你会发现需求突然就翻了10倍。这个时候我们怎么办?

答案只有一个:提(jia)效(ren)。所以这个时期的核心是:

快、稳

提效最简单的办法是加人,但问题是,100个运营好找,100个能写出靠谱代码的前端不好找,有的时候改别人的代码,比重写一遍更麻烦。看过《人月神话》的同学都知道,加人带来的效率提升是有瓶颈的,人平均效率会随着人数增加而下降。

此时就需要考虑通过技术手段提效,沉淀基础研发体系,包括:

  1. 基础工具库+ 业务工具库,避免重复写一些简单但是容易出bug的业务逻辑。
  2. UI规范 + 组件体系。UI规范很重要,如果设计师不能达成一致,那出来的视觉稿必然是千差万别的,你的公共组件也就难以沉淀了。
  3. 研发工具升级。主要有 构建性能优化、数据mock工具、环境切换工具、线上问题排查工具等。

除了技术手段,人员的技术成长也很重要,毕竟技术方案是由人来执行的,个人觉得常用的方式有:

  1. CodeReview,帮助新人快速成长到一定水平,保证新人开发代码的可维护性。
  2. 内部分享。分享好用工具以提升研发效率,分享底层原理避免踩更深的坑浪费大量时间,也可以分享一些编码、调试小技巧。

当然,还有一个提效的神技,就是——砍需求。

砍需求也是一门技术活儿,有的高级工程师用嘴就将需求解了。但不是每个团队都采用放权式管理(此处感谢我的历任老板们),给你足够的权力自己砍需求和排期; 有的公司采用的是集权式管理,只有前端leader能够砍需求和进行任务分配,也使得不少同学这方面能力没成长起来。

那么需求到底怎么砍?听我简单说一下,欢迎更好的套路。

  1. 首先,端正心态。 你砍需求不是为了自己偷懒要早下班,你砍需求是为了业务整体效率的提升。你要砍的是无效需求、重复需求,公司业务的核心需求不能砍。不然你把公司业务都砍死了,自己喝西北风去?公司如果运气好IPO了,你不也爽一波?
  2. 其次,先问问需求解决的业务问题是什么? 搞清楚这一点,就能判断:这个需求的优先级多高、是不是伪/重复需求、是否有其他方式替代解决。此处的伪需求,是指不能实际解决用户问题的需求。
  3. 再其次,数据说话。 相关的数据是怎么样的?如何推导出业务的问题所在?做完这个需求数据会变成什么样?
  4. 最后,这个需求可能需要哪些上下游合作。涉及其他环节的需求,一定要将上下游拉到一起,考虑到所有可能的问题,统一一个方案,才能客观评估工作量。
  5. 最后的最后,也是最重要的,将共性的需求沉淀,构建组件体系or业务模块体系。有这个沉淀,才能更进一步,对需求做收敛,例如总不能说,已经有一个slider模块了,你还要再做一个类似的吧,对业务的提升到底在哪?

一般一个重要的、合理的需求都能比较好回答上面这些的问题。其中第三点,数据说话,也对公司的数据化能力提出了要求。

  1. 最基本的pv/uv、uv点击率、停留时长,这是和前端页面相关的指标。
  2. 模块热度、功能使用情况,这是用来和业务方撕逼的时候使用的。(上次做的功能你们又不用!)
  3. 还有业务指标,例如电商的gmv、售罄率,但这些和前端没直接关系。
  4. 高级一点可以玩GrowthHack,全链路监控细分用户群的使用情况,比较适合业务已经增长到一定体量,精细化运营的场景。
  5. 大数据分析+洞察+数据可视化。会在第三部分讲述。

另一个不能忽视的是,如何变得更『』,因为大家都很急,一急就容易出线上故障,然后时间都花在处理故障上了,然后时间就更急,一个快速腐化的死循环,然后你能怎么办呢?只能以猝死明志啊……常见的有以下几种方法:

  1. 研发流程管控。不经测试不允许上线,这也是阿里的研发红线,看起来是效率降低的,但其实只是把处理线上问题的时间用来测试了而已。
  2. 基础库、基础组件 上单元测试,代码覆盖率90%+
  3. 监控。线上404、页面白屏、js/接口报错等。
  4. 安全。最基本的xss、csrf做一下,再整体升一下https
  5. 问题复盘、沉淀机制。避免再出同样的问题。

以上这些问题解决了,前端同学也就算是又快又稳地帮业务度过了快速发展期,迎来业务的精耕细作期。

三、精耕细作

俗话说得好:攻城容易守成难,但现在攻城也不那么容易了。现在新兴的独角兽,背后都有AT的影子,例如ofo和摩拜,双方都极难一下子摁死对方。而是互拼内力,最后很可能落得两败俱伤。这个时候我们就需要稳中求快。

前两个阶段的C端场景看起来和前端关系更加紧密,那么这个阶段和前端有什么关系呢?我觉得能做的事情有:

  1. 中后台系统的构建。 将运营们的工作线上化,同时减少部分手工操作,达到效率的提升。
    虽然说运营们通常excel用得虎虎生风,但有容易出错、贪腐较多的问题,想想ofo被曝贪腐严重的新闻

在不少缺前端的公司,这部分通常也由后端用jQuery一把梭。但后端撸出来系统,通常都欠缺交互意识(无导航、报错信息等设计)、撸不出稍微复杂的布局(见过被float和flex难住的)、缺少动效、SPA 等,做出来的系统真的差不少,都9012年了,还是让专人来干这活吧。记得加上水印,包括明水印和暗水印,便于公司时候追责,间接防止公司机密外泄。

  1. 大数据可视化。 不仅仅是消费者端页面的访问数据,还有更深层次的公司运营数据。例如ofo可以实时跟踪自行车的损坏率、监控车辆密集程度等,从而指挥调度车的调度,达到车辆投放和使用率的最佳匹配。虽然这事儿吧,核心还是数据同学产出数据的准确性,但前端同学的配合是不可或缺的。
    常见的可以用来做这事儿的有Echarts、HighCharts、G2等等,虽然我们基本不可能再重复自研一套,但取其精华,快速赋能业务,就是业务前端的价值所在。
  2. 平台化
    此处其实指的是大中台、小前台的概念。因为我们往往已经积累了一批中后台系统,但如何使同一个系统更快支撑新的业务、砍掉/合并重复功能的中后台系统,也是辅助业务的一种手段。
  3. ABTest
    根据之前的经验,电商不同行业的不同人群,对于交互设计的偏好真的就不一样,有的喜欢大图,有的喜欢小图。因此通过ABTest方案,对人群进行千人千面的细分展现,对业务也是可以稍微有一定的提升。
  4. 容器技术(hybrid & 内核)& 极致性能
    其实也就这么提一下,因为对于大多数公司,真没有深入追求浏览器内核提升的价值和可能性。

hybrid方案是有必要的,但应该在急剧扩张时期就做得差不多了。
极致性能也属于比较炫技的东西了(已经做到1~2s页面可交互的前提下),短期内没有特别大的必要,但在追求极致性能的过程中,迫使相关同学深入了解容器技术、服务端、网关、cdn等底层,并推动相关方升级,经过长时间的积累,带来人力储备和技术储备的提升。

四、新赛道、新增量时期

基本上做完上面那些东西,公司的业务进入一个稳定的时期,就是到处看看有什么新的东西可以做了。(当然还是可能有各种各样蛋碎的改版)
核心

  1. 端的扩展:

    1. 包括各类小程序。 名义上是便于管控第三方,提供更好的体验,其实就是人为割裂出一个端,同时用流量把这个端喂起来。不过没办法,谁让爸爸们有流量呢。但注意一点,扩展一个端是有维护成本的,且并不会直接带来流量收益,需要配套的运营计划。
    2. 3D、全景、VR / AR 。有可能带来交互根本变化的东西,唯一的缺点是科技还不够先进,做全景素材成本很高,VR/AR的应用场景也不够多。
    3. Flutter。
  2. 智能化:

    1. 业务的智能化。例如活动界面的千人千面,根据算法计算出最佳界面元素组合方式等。
    2. 研发的智能化。例如FB的Aroma、之前业内的psd2html,但这个算法和普通的电商推荐算法相比,最大的区别在于容错率极低,你推荐错了一个商品大不了不买看下一个,但你自动生成错了一句代码,整个系统就跑不起来。

实在不知道前端还有什么新的东西好关注的了,硬掰不出来,就这样吧,欢迎指点。

五、最后

读完本文,相信你已经找到了前面三个问题的答案,能够不再被一堆需求推着走,也能够不再只撸业务代码,孕育出属于你们团队的技术方案而获得技术上的提升,最重要的是找到自己的一身本领在这个商业世界中的价值,不忘极客梦,技术改变世界,rock the world。

免责免撕声明:本文是个人的一些总结和思考,笔者的业务经验有大流量产品、大型营销活动、各类中后台项目,基础技术产品也搞过,但终究经验有限,难免有错漏,欢迎指正和补充。

目录
相关文章
|
前端开发 数据库 数据安全/隐私保护
【项目实战】登录与注册业务的实现(前端+后端+数据库)
【项目实战】登录与注册业务的实现(前端+后端+数据库)
2162 0
【项目实战】登录与注册业务的实现(前端+后端+数据库)
|
前端开发
「前端经验总结」大型业务项目中,前端如何撰写设计文档
设计文档可以帮助开发梳理业务功能,呈现优质的开发思维的载体。另外,当开发思路逐渐丰富,开发速度也就提上来了。所以本篇分享笔者前端的开发中尤其是大型业务项目,是如何撰写设计文档的。
1374 1
|
人工智能 监控 前端开发
业务线前端 7 年之 “感”
每天进步一点点,追上心中的太阳。
业务线前端 7 年之 “感”
|
前端开发 开发者
「前端工作小记」关于业务组件的思考
用技术实现梦想,用梦想打开前端技术之门。分享我在日常开发中关于业务组件的思考。
356 1
「前端工作小记」关于业务组件的思考
|
缓存 前端开发 数据可视化
前端同学在可观测性的启蒙与初试探--快速实现根因分析/业务大盘
前端同学在可观测性的启蒙与初试探--快速实现根因分析/业务大盘
290 0
前端同学在可观测性的启蒙与初试探--快速实现根因分析/业务大盘
|
存储 弹性计算 运维
serverless 学习 | QCon2022-深圳: 美团基于 Serverless 的前端研发体系建设和业务实践
serverless 学习 | QCon2022-深圳: 美团基于 Serverless 的前端研发体系建设和业务实践
285 0
serverless 学习 | QCon2022-深圳: 美团基于 Serverless 的前端研发体系建设和业务实践
|
分布式计算 监控 前端开发
拍卖前端质量之 基于业务驱动的前端性能监控的有效实践
前端的本质价值是什么? 我认为是 给用户创造良好的交互体验。 前端性能对用户体验、对业务跳失率的影响,在业界已有共识,不言而喻。 以下详述测试视角,前端性能优化的解法,简言之即:从发现、分析、验证3方面驱动推进页面性能优化 并通过实际案例更生动描述。
392 1
|
移动开发 前端开发 小程序
DingTalk「开发者说」第7期 钉钉前端开放及其业务思考
DingTalk「开发者说」是钉钉开发者最新上线的开发者栏目,联合阿里云ACE团队,分享钉应用开发解决方案、技术更新、实战技巧,致力于成为钉钉与开发者的桥梁与纽带,让更多的钉钉开发者传播技术、提升技能、分享观点。在数字化变革的时代,“云钉一体”“钉钉全面开放”战略之后,希望钉钉技术可以持续激发开发者的创造力,为组织数字化赋能。 本篇介绍了钉钉前端开放的概况及其对开发者的业务价值思考,最后从高级技术专家视角,为大家讲解前端团队如何在业务中取得突破
DingTalk「开发者说」第7期 钉钉前端开放及其业务思考
|
缓存 网络协议 前端开发
业务前端界面报错504排查思路和解决办法
业务前端界面报错504排查思路和解决办法
业务前端界面报错504排查思路和解决办法
|
设计模式 XML 数据可视化
降低前端业务复杂度新视角:状态机范式
无论做业务需求还是做平台需求的同学,随着需求的不断迭代,通常都会出现逻辑复杂、状态混乱的现象,维护和新增功能的成本也变的十分巨大,苦不堪言。下图用需求、业务代码、测试代码做对比:
335 0
降低前端业务复杂度新视角:状态机范式