岳渊 2019-04-17 20:27:08 浏览 161 评论 0
前端与交互设计
JavaScript
性能
电商
运营
web 开发
摘要: 你是否头疼于, 每天做不完的需求和改不完的 bug? 你是否发愁, 每天撸业务代码, 是否能获得技术成长? 而追求成就感的你是否想过, 你所编写的一行行代码, 是在反复的变化中迅速成为遗留代码, 还是助公司插上腾飞的翅膀, 在你死我活的战场上脱颖而出? 本文会将业务和前端关联起来讨论, 探讨业务发展的不同时期, 前端所能做的一些事情, 既能解业务的困扰, 也让前端同学们摆脱码工, 切图仔的定位.
你是否头疼于, 每天做不完的需求和改不完的 bug?
你是否发愁, 每天撸业务代码, 是否能获得技术成长?
而追求成就感的你是否想过, 你所编写的一行行代码, 是在反复的变化中迅速成为遗留代码, 还是助公司插上腾飞的翅膀, 在你死我活的战场上脱颖而出?
因此本文会将业务和前端关联起来讨论, 探讨业务发展的不同时期, 前端所能做的一些事情, 既能解业务的困扰, 也让前端同学们摆脱码工, 切图仔的定位.
千言万语不如一张图, 全文完.
大误, 还是得详细说说.
一, 初始阶段
在业务的初始阶段, 在市场定位, 用户诉求, 产品逻辑已经明确的前提下, 此时业务的核心诉求是 『尽快上线』, 进行快速验证和产品迭代, 当然, 质量还得能过得去.
所以此时技术同学的方案侧重点是:
快, 爽
先说『快』, 在这种情况下, 什么 vue/react 都见鬼去, 老夫只用 jQuery 一把梭!
这是反面案例, 这样就只能重构火葬场了, 项目上线完就打包行李滚蛋......
此时的快, 指的是 尽可能复用集团 / 业内成熟的方案, 架构, 按捺住自己重新造轮子的躁动不安的心情.
这又涉及到一个问题: 如何选择一个靠谱的方案? 这是一个可以另开文章的话题, 但先在此简单说说
根据我个人的经验, 主要从稳定性, 可扩展性, 性能去考虑.
稳定性 如何去评估? 如果一个项目能做到这几项, 我是比较放心的.
项目 star 数多
有单测, 代码覆盖率 90%~95% 以上
文档完备, 有常见 Q&A
issue 有较快的处理流程和周期, 3 天内响应, 1~4 周内关闭.
有稳定的版本控制, 不进行不兼容的升级, 非要不兼容升级的话, 将迁移工具做到极致.
可扩展性 如何评估? 主要是指能否根据业务 or 已有技术方案, 自定义部分内容.
例如组件库, 是否能自定义主题, 组件的事件回调等, 因为有的需求, 组件除了完成默认的行为, 还需要执行其他逻辑如埋点;
例如单测工具, 能否配置白名单, 因为有一些代码是兼容特殊场景, 编写用例模拟场景的成本实在比较高. 这个主要是根据技术诉求和经验进行判断.
性能问题, 短期容易被人忽视, 因为能跑就行, 但一旦埋下隐患, 日后有坑就极难解决. 容易出现性能问题的地方有: 代码构建, 长列表 / 表格滚动, 大数据图表, 复杂动画, 3D 全景渲染等, 如果所做的业务涉及到这几个方面, 选择方案的时候就要特别注意性能.
如果实在图省事儿, create-react-App,umi 开箱即用来一套就完事儿了.
『爽』 这个字我的理解是, 一款新产品出现, 一定需要在用户体验 or 交互上有绝对领先对手的地方.
一个我始终记忆犹新的例子, 就是乔布斯发布第一款 iPhone 时, 演示滑动列表时全场的惊呼, 一个乔布斯的哥们说: 当你滑动页面的时候我就湿了.
另一个前端领域的例子, 就是 Ant Design.AntD 被广泛使用, 很大一部分原因是其出色的视觉设计和动效. 至今为止, AntD 的官网介绍上仍然说这是一个设计体系.
所以我觉得, 一款新产品, 除了提供刚需价值, 最好在美观和易用上领先对手一大步, 虽然主要还是看设计师和产品的功底, 但前端同学的实现上至少不能拖后腿, 不能加载太慢, 滚动太卡.
蓝海市场, 刚需产品也许不那么看重这一点, 但有的蓝海门槛较低, 很快就会转变为红海.
还值得一提的是, 账户体系的建设, 包括打通三方登录, 免登等(客户端登录态透传到 h5), 网上不少资料, 我实在没这方面经验, 就不在此多嘴了.
二, 快速扩张
OK, 假设产品如期上线, 数据蹭蹭上涨, 看起来一切都很完美.
然后问题就来了, 业务开始扩张, 公司新招了 100 个运营和 10 个 PD, 你会发现需求突然就翻了 10 倍. 这个时候我们怎么办?
答案只有一个: 提 (jia) 效(ren). 所以这个时期的核心是:
快, 稳
提效最简单的办法是加人, 但问题是, 100 个运营好找, 100 个能写出靠谱代码的前端不好找, 有的时候改别人的代码, 比重写一遍更麻烦. 看过《人月神话》的同学都知道, 加人带来的效率提升是有瓶颈的, 人平均效率会随着人数增加而下降.
此时就需要考虑通过技术手段提效, 沉淀基础研发体系, 包括:
基础工具库 + 业务工具库, 避免重复写一些简单但是容易出 bug 的业务逻辑.
UI 规范 + 组件体系. UI 规范很重要, 如果设计师不能达成一致, 那出来的视觉稿必然是千差万别的, 你的公共组件也就难以沉淀了.
研发工具升级. 主要有 构建性能优化, 数据 mock 工具, 环境切换工具, 线上问题排查工具等.
除了技术手段, 人员的技术成长也很重要, 毕竟技术方案是由人来执行的, 个人觉得常用的方式有:
CodeReview, 帮助新人快速成长到一定水平, 保证新人开发代码的可维护性.
内部分享. 分享好用工具以提升研发效率, 分享底层原理避免踩更深的坑浪费大量时间, 也可以分享一些编码, 调试小技巧.
当然, 还有一个提效的神技, 就是 -- 砍需求.
砍需求也是一门技术活儿, 有的高级工程师用嘴就将需求解了. 但不是每个团队都采用放权式管理(此处感谢我的历任老板们), 给你足够的权力自己砍需求和排期; 有的公司采用的是集权式管理, 只有前端 leader 能够砍需求和进行任务分配, 也使得不少同学这方面能力没成长起来.
那么需求到底怎么砍? 听我简单说一下, 欢迎更好的套路.
首先, 端正心态. 你砍需求不是为了自己偷懒要早下班, 你砍需求是为了业务整体效率的提升. 你要砍的是无效需求, 重复需求, 公司业务的核心需求不能砍. 不然你把公司业务都砍死了, 自己喝西北风去? 公司如果运气好 IPO 了, 你不也爽一波?
其次, 先问问需求解决的业务问题是什么? 搞清楚这一点, 就能判断: 这个需求的优先级多高, 是不是伪 / 重复需求, 是否有其他方式替代解决. 此处的伪需求, 是指不能实际解决用户问题的需求.
再其次, 数据说话. 相关的数据是怎么样的? 如何推导出业务的问题所在? 做完这个需求数据会变成什么样?
最后, 这个需求可能需要哪些上下游合作. 涉及其他环节的需求, 一定要将上下游拉到一起, 考虑到所有可能的问题, 统一一个方案, 才能客观评估工作量.
最后的最后, 也是最重要的, 将共性的需求沉淀, 构建组件体系 or 业务模块体系. 有这个沉淀, 才能更进一步, 对需求做收敛, 例如总不能说, 已经有一个 slider 模块了, 你还要再做一个类似的吧, 对业务的提升到底在哪?
一般一个重要的, 合理的需求都能比较好回答上面这些的问题. 其中第三点, 数据说话, 也对公司的数据化能力提出了要求.
最基本的 pv/uv,uv 点击率, 停留时长, 这是和前端页面相关的指标.
模块热度, 功能使用情况, 这是用来和业务方撕逼的时候使用的.(上次做的功能你们又不用!)
还有业务指标, 例如电商的 gmv, 售罄率, 但这些和前端没直接关系.
高级一点可以玩 GrowthHack, 全链路监控细分用户群的使用情况, 比较适合业务已经增长到一定体量, 精细化运营的场景.
大数据分析 + 洞察 + 数据可视化. 会在第三部分讲述.
另一个不能忽视的是, 如何变得更『稳』, 因为大家都很急, 一急就容易出线上故障, 然后时间都花在处理故障上了, 然后时间就更急, 一个快速腐化的死循环, 然后你能怎么办呢? 只能以猝死明志啊...... 常见的有以下几种方法:
研发流程管控. 不经测试不允许上线, 这也是阿里的研发红线, 看起来是效率降低的, 但其实只是把处理线上问题的时间用来测试了而已.
基础库, 基础组件 上单元测试, 代码覆盖率 90%
监控. 线上 404, 页面白屏, JS / 接口报错等.
安全. 最基本的 xss,csrf 做一下, 再整体升一下 https
问题复盘, 沉淀机制. 避免再出同样的问题.
以上这些问题解决了, 前端同学也就算是又快又稳地帮业务度过了快速发展期, 迎来业务的精耕细作期.
三, 精耕细作
俗话说得好: 攻城容易守成难, 但现在攻城也不那么容易了. 现在新兴的独角兽, 背后都有 AT 的影子, 例如 ofo 和摩拜, 双方都极难一下子摁死对方. 而是互拼内力, 最后很可能落得两败俱伤. 这个时候我们就需要稳中求快.
前两个阶段的 C 端场景看起来和前端关系更加紧密, 那么这个阶段和前端有什么关系呢? 我觉得能做的事情有:
中后台系统的构建. 将运营们的工作线上化, 同时减少部分手工操作, 达到效率的提升.
虽然说运营们通常 Excel 用得虎虎生风, 但有容易出错, 贪腐较多的问题, 想想 ofo 被曝贪腐严重的新闻.
在不少缺前端的公司, 这部分通常也由后端用 jQuery 一把梭. 但后端撸出来系统, 通常都欠缺交互意识(无导航, 报错信息等设计), 撸不出稍微复杂的布局(见过被 float 和 flex 难住的), 缺少动效, SPA 等, 做出来的系统真的差不少, 都 9012 年了, 还是让专人来干这活吧. 记得加上水印, 包括明水印和暗水印, 便于公司时候追责, 间接防止公司机密外泄.
大数据可视化. 不仅仅是消费者端页面的访问数据, 还有更深层次的公司运营数据. 例如 ofo 可以实时跟踪自行车的损坏率, 监控车辆密集程度等, 从而指挥调度车的调度, 达到车辆投放和使用率的最佳匹配. 虽然这事儿吧, 核心还是数据同学产出数据的准确性, 但前端同学的配合是不可或缺的.
常见的可以用来做这事儿的有 Echarts,HighCharts,G2 等等, 虽然我们基本不可能再重复自研一套, 但取其精华, 快速赋能业务, 就是业务前端的价值所在.
平台化.
此处其实指的是大中台, 小前台的概念. 因为我们往往已经积累了一批中后台系统, 但如何使同一个系统更快支撑新的业务, 砍掉 / 合并重复功能的中后台系统, 也是辅助业务的一种手段.
ABTest.
根据之前的经验, 电商不同行业的不同人群, 对于交互设计的偏好真的就不一样, 有的喜欢大图, 有的喜欢小图. 因此通过 ABTest 方案, 对人群进行千人千面的细分展现, 对业务也是可以稍微有一定的提升.
容器技术(hybrid & 内核)& 极致性能.
其实也就这么提一下, 因为对于大多数公司, 真没有深入追求浏览器内核提升的价值和可能性.
hybrid 方案是有必要的, 但应该在急剧扩张时期就做得差不多了.
极致性能也属于比较炫技的东西了(已经做到 1~2s 页面可交互的前提下), 短期内没有特别大的必要, 但在追求极致性能的过程中, 迫使相关同学深入了解容器技术, 服务端, 网关, cdn 等底层, 并推动相关方升级, 经过长时间的积累, 带来人力储备和技术储备的提升.
四, 新赛道, 新增量时期
基本上做完上面那些东西, 公司的业务进入一个稳定的时期, 就是到处看看有什么新的东西可以做了.(当然还是可能有各种各样蛋碎的改版)
核心
端的扩展:
包括各类小程序. 名义上是便于管控第三方, 提供更好的体验, 其实就是人为割裂出一个端, 同时用流量把这个端喂起来. 不过没办法, 谁让爸爸们有流量呢. 但注意一点, 扩展一个端是有维护成本的, 且并不会直接带来流量收益, 需要配套的运营计划.
3D, 全景, VR / AR . 有可能带来交互根本变化的东西, 唯一的缺点是科技还不够先进, 做全景素材成本很高, VR/AR 的应用场景也不够多.
Flutter.
智能化:
业务的智能化. 例如活动界面的千人千面, 根据算法计算出最佳界面元素组合方式等.
研发的智能化. 例如 FB 的 Aroma, 之前业内的 psd2html, 但这个算法和普通的电商推荐算法相比, 最大的区别在于容错率极低, 你推荐错了一个商品大不了不买看下一个, 但你自动生成错了一句代码, 整个系统就跑不起来.
实在不知道前端还有什么新的东西好关注的了, 硬掰不出来, 就这样吧, 欢迎指点.
五, 最后
读完本文, 相信你已经找到了前面三个问题的答案, 能够不再被一堆需求推着走, 也能够不再只撸业务代码, 孕育出属于你们团队的技术方案而获得技术上的提升, 最重要的是找到自己的一身本领在这个商业世界中的价值, 不忘极客梦, 技术改变世界, rock the world.
免责免撕声明: 本文是个人的一些总结和思考, 笔者的业务经验有大流量产品, 大型营销活动, 各类中后台项目, 基础技术产品也搞过, 但终究经验有限, 难免有错漏, 欢迎指正和补充.
来源: https://yq.aliyun.com/articles/698685