小公司的前端应该怎么作？

 

随着能力的提高，负责的工做种类会逐渐增多，考虑的方向也会有所不一样，这个时候不太会有太多单独的知识点成为阻碍了，工做中碰到的问题要么太 “大”，总结起来费力，要么太“小”。

在小公司作前端，由于公司以及职位的变化，对于在小公司如何作前端有一些心得，拿出来与各位作个分享，但愿对处于小公司的前端有必定用处。

什么是优秀的前端团队？

团队初期缺什么

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

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

好比，今年H5站想达到单日平均出票量10000，那么这个就是业务目标，须要消化分到各个业务团队，能够是：

① 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方案应该是每个成熟团队必须的，持续优化这些都是创建在有效的数据监控与意见反馈机制上的，咱们不能作完网站变成瞎子。

诚然，对于一个前端来讲，要推进上述工做仍是有一点难度的，但并非不可能，前端对本身的定位要变，从前端工程师到软件工程师。

前端的重视程度须要你们一并努力，在大公司作前端难，在小公司作前端更难。