你的位置:首页 > 网页设计

[网页设计]小公司的前端应该怎么做?


前言

近期工作生活比较漂泊,从上海换到了成都,这个是以家庭为单位的重大决定,离开一线城市对于职业生涯和技术前沿来说是有一定问题的,但是出于房价考虑(主要是买不起房子)与生活舒适度来说,回蓉似乎是一个比较好的选择,何况成都的互联网也还行。

随着能力的提升,负责的工作种类会逐渐增多,考虑的方向也会有所不同,这个时候不太会有太多单独的知识点成为阻碍了,工作中碰到的问题要么太“大”,总结起来费力,要么太“小”,不适合单独整理成文,这种现象反而造成了一段时期的博客空白期,总的来说就是又开始懒了,思维又开始懈怠,人又开始想待在安逸区了。

因为开始懒了,所以没能学习到新知识,自然出不了新文;因为开始懒了不愿意再对工作中的问题一个个深入研究、深入挖掘自然出不了新文。

所以人还是得不停的鞭笞自己啊,不能让自己陷入“瞎忙”的境地,得有效的利用时间,才能走的更远!!!

现在我在一家小公司做前端,因为公司以及职位的变化,对于在小公司如何做前端有一些心得,拿出来与各位做个分享,希望对处于小公司的前端有一定用处,也鞭笞自己重新学习总结。

什么是优秀的前端团队?

团队初期缺什么

在公司中,层级越高对业务关注比例越高,反而不太关注个人成长,所以评价一个leader是以团队为单位,团队成员比他强是应该的;对于个人来说的话,要多关注自身能力成长,然后能力匹配自己的职位,甚至超出自己的职位,这样的团队的话,战斗力是比较强的。

主管(包括前端主管)设定目标必须可量化 ,比如你做一个业务,kpi是多少,那么技术就需要考虑如何才能达成,细化到研发甚至前端层级,就是所谓技术kpi了。

比如,今年H5站想达到一亿的流量,那么这个就是业务目标,需要消化分到各个业务团队,可以是:

① SEO优化

② SEM优化

③ 营销广告

......

以上当然只能解决部分问题,具体到前端,可能我们就要从页面转换率入手,建立订单漏斗模型,做性能优化,做交互优化,每一个具体的层面都需要转化目标。

这些都是直接可量化的东西,因为当前业务已经到了一个瓶颈,或者公司已经到了一个瓶颈,业务上就需要做不停的尝试,对应到技术就是需要你快速迭代,低成本迭代,不断的容错试错。

这个时候就会提出很多问题:

第一是你的团队在类似高压下会不会主动加班去实现公司的目标、个人的kpi。

第二是你的团队在这轮高压拼搏后有没有留下什么东西?

根据之前经验,没有团队可以无休止的承受高压加班的压力

以之前携程无线高压迭代的经历来说,就算是那么优秀的团队事实上到后期也是疲惫不堪,疲惫的时候容易犯错,亢龙有悔,盈不可久。

第三是如何帮助新人快速的融入团队,如何让1+1=2。

我们都清楚,好的项目绝不是堆人可以堆出来的,如何让一个项目可以分解到各个人手中,如何让良莠不齐的同事可以更好的协作,这个是我们需要考虑的。

要解决这些问题是要靠平时的积累,具体体现到前端是:

1 在不停的迭代中,你的业务流程是不是最优(产品到设计到前端到最终上线流程)2 在不停的迭代中,是否沉淀出来了公共服务与工具化服务

好的前端是什么样的

首先,好的前端是一定愿意加班的,同时,好的前端是会找办法让团队少加班的。

和一些朋友做过交流,很多好的点子,改善工作效率的点子都是几个人讨论后私下晚上搞出来,然后反复实践用于生产的。

一般来说业务kpi对于能力强的朋友来说不会太难,所以对他们的期待也会更多:

有强烈的意识,能深刻了解到当前项目性能的缺陷,开发效率低下的原因,并会找寻处理办法

很多团队在快速迭代中会开始“欠账”,时间久了就不愿意还,问题的存在搁置需要想办法去解决,团队成员是看得到问题的,没人说,没人做是因为知道那是坑,你如果能解决的话,一到二次便能提升自己在团队中的位置。

好的前端应该有良好的架构设计能力

首先,好的前端能向人清晰有条理的描述自己的技术方案,并且让人听得懂!

然后架构设计能满足长久的需求发展,就算业务频道扩大了10倍,用户量增加了100倍,也不会有根本的变动。

好的前端应该具有良好的交流能力

对内,好的前端需要了解团队成员的性格与能力,做出适当的任务分配分解;对外,需要抢占业务还不能产生利益冲突,这类人是项目推进的主力。

小公司的前端应该怎么做

不是所有的小公司都这样,但是我见过的小公司的前端都在扑业务,并且疲于奔命,这个是个恶性循环,第一次做业务:

加班赶业务-业务结束轻松一周-加班赶迭代-业务结束轻松一周-加班新业务-业务结束轻松下......

偶尔你会问这些朋友为什么没有什么积累,得到的答案基本是一致的,忙啊!他们忙起来的时候是真的很忙,但是第二次如果依旧这么忙的话就有问题,第三次还这样就是团队不健康了,一个好的做法是:

① 完成前后分离,这步做不到,后面也不用做了② 形成几套UI库③ 根据业务形态,形成公共业务④ 前端重复工作工具化⑤ 形成优化体系⑥ 形成统计体系⑦ 建立页面转化漏斗模型⑧ 做ABTesting方案......

首先,无论出于什么考虑,前后一定要做分离,如果有SEO需求,那么再后续推进nodeJS方案,毕竟现在不给钱想排前面还是很难,SEO基本没意义。

其实,小公司有很多坑可以占住,这个会帮助你建立团队威望,下面我举几个细节点说一说。

UI库

UI库的形成与UI库的多少将决定你后续项目重复工作量的多少,这个UI库需要注意几点:

① UI是否可重用

② UI是否可定制

比如让很多朋友去做这个时间选择器,做出来就真的是时间选择器,如果让他换成城市选择器,就全傻眼了:

③ UI是否可拆分,可聚合

还是以上面UI为例,这个组件事实上是一个聚合组件,由一个select组件与一个弹出层组件组成,你的UI是不是可拆分是评价他质量的一个很大考虑点。

......

公共服务

公共服务可以说成一个大一点的“UI组件”,但是他是与业务相关的,UI来说一般不会与业务产生耦合,以上面的日期选择器来说,无论他装的是日期还是区域都是可以的,并且不应该请求服务,他是纯净的UI组件。

而公共服务是不纯净的是一定与业务相关的,移动端比较常见的公共服务是:

passport

包含登录注册、个人资料管理,甚至包含一些认证相关的,与公司账号相关的操作,登录注册是各种活动,各种业务频道都可能会使用的业务,这种东西是必须服务化的,但是很多小公司都没做。

因为公共的特点,页面设计最好中性一点,其中几个常用的页面,比如登录需要包含以下设计

① 样式可定制化(弹出层、独立页面什么的都是常事)

② 回退可定制,其实所有的公共服务回退按钮都是需要定制的,登录成功去哪个URL登录失败去哪个URL,点击浏览器回退去哪个URL都得约定,少一个都不是公共服务

③ 单点登录,事实上初期根本用不到什么单点登录,甚至大家都不是跨域的,所以后续需要再支持即可

还有很多与passport一样的公共业务,比如:

① 钱包服务,包括用户支付订单相关管理

② 城市列表,这个要考虑参数如何传递

③ 反馈系统

④ 公司介绍

除了面向C端的公共页面服务,还会有面向B端的统计平台相关。

前端工具化 

静态资源处理

评价一个前端团队是否优秀成熟的评判多以团队工具化的程度,一个简单的例子是:

① 你们前端静态资源是如何组织的、如何打包的

② 你们前端静态资源是如何解决缓存的(比较好的方案是MD5)

上面两点可以使用grunt/gulp一类的构建工具轻松做到,如果有公共框架文件还会需要引入种子文件的概念

跨域问题

另外,所有前端团队都会遇到跨域问题,特别是前后分离后,服务器端只提供API接口,前端代码随便在哪都能运行,那么这个时候你是怎么做呢?

① 使用fiddler&charles做代理

② 提供测试服务器

③ 支持jsonp跨域

④ 支持cors跨域

那么这些方案,哪种最适合团队,哪种成本最低(一般来说是代理),是我们需要考虑的

tips:我之前使用fiddler,现在换mac了使用charles,两款工具十分优秀,正则一块的处理很好,推荐使用

移动端适配

从后端转到前端的同学一般在业务逻辑上有一些天生的优势,但是往往在CSS一块比较弱,如何在开发人员无感的情况下引入rem,如何与现有机制无缝的使用less,如何处理单页应用中css的污染,这个是框架底层需要考虑的。

模块化&组件化开发

团队上规模后,如何使用模块化开发处理协作问题;业务代码复杂度上升后,如何使用组件化编程思维简单开发复杂度,这些需要应用到项目实践中,并且路径是可复制的;

一些优化手段,也需要工具化,框架化,让开发人员无感。

前后端协作

前端与服务器端,开发速度未必同步,事实上很多时候都不是同步的,在已经约定了接口格式的情况下,接口还没有写好,但是前端依然能写交互,团队是如何写这种假数据,这个方面实现会大大的提升工作效率。

订单下降分析

如果在某一个时间段,全站的流量或者全站的订单量下降了,你如何跟踪这次下降的原因,如何最大程度上避免下次出现类似的现象,这个时候数据统计会避免我们成为瞎子,所以得尽快建立统计平台,转换率模型。

快速迭代,通过迭代来优化产品,但是如果每一个迭代都完全颠覆了之前的设计,很多时候公司就是原地踏步,每迈出一步你要清晰的知道前一个版本哪里出了问题,针对问题做优化,而不是频繁改版。

这次改版后,你如何知道这次优化就比上一次的好,而不是其它因素造成,ABTesting方案应该是每一个成熟团队必须的,持续优化这些都是建立在有效的数据监控与意见反馈机制上的,我们不能做完网站变成瞎子。

结语

因为很久没有写博客了,又因为最近刚好来到了小团队,有一些想法以水文的形式发出来与各位讨论,希望对各位有用。

诚然,对于一个前端来说,要推动上述工作还是有一点难度的,但并不是不可能,前端对自己的定位要变,从前端工程师到软件工程师。

我常常听到很多前端自己都在质疑自己,或者就是膨胀到觉得自己团队没有什么可以做了,那么这个时候可以考虑下:

你们团队的自动化、安全性已经到位了吗,效率就真的完全没有上升空间了?

前端的重视程度需要你我一并努力,在大公司做前端难,在小公司做前端更难,你我共勉!