1什么是优秀的前端团队?

　　团队初期缺什么
　　在公司中，层级越高对业务关注比例越高，反而不太关注个人成长，所以评价一个leader是以团队为单位，团队成员比他强是应该的;对于个人来说的话，要多关注自身能力成长，然后能力匹配自己的职位，甚至超出自己的职位，这样的团队的话，战斗力是比较强的。
　　主管(包括前端主管)设定目标必须可量化 ，比如你做一个业务，kpi是多少，那么技术就需要考虑如何才能达成，细化到研发甚至前端层级，就是所谓技术kpi了。
　　比如，今年H5站想达到单日平均出票量10000，那么这个就是业务目标，需要消化分到各个业务团队，可以是：
　　① SEO优化
　　② SEM优化
　　③ 营销广告
　　④ 微信&支付宝&手机百度流量接入(微信钱包是十分优秀的流量入口，可以极大程度的增加流量)
　　⑤ 实地推广
　　……
　　以上当然只能解决部分问题，具体到前端，可能我们就要从页面转换率入手，建立订单漏斗模型，做性能优化，做交互优化，每一个具体的层面都需要转化目标。
　　这些都是直接可量化的东西，因为当前业务已经到了一个瓶颈，或者公司已经到了一个瓶颈，业务上就需要做不停的尝试，对应到技术就是需要你快速迭代，低成本迭代，不断的容错试错。
　　这个时候就会提出很多问题：
　　第一是你的团队在类似高压下会不会主动加班去实现公司的目标、个人的kpi。
　　第二是你的团队在这轮高压拼搏后有没有留下什么东西?
　　根据之前经验，没有团队可以无休止的承受高压加班的压力
　　以之前携程无线高压迭代的经历来说，就算是那么优秀的团队事实上到后期也是疲惫不堪，疲惫的时候容易犯错，亢龙有悔，盈不可久。
　　第三是如何帮助新人快速的融入团队，如何让1+1=2。
　　我们都清楚，好的项目绝不是堆人可以堆出来的，如何让一个项目可以分解到各个人手中，如何让良莠不齐的同事可以更好的协作，这个是我们需要考虑的。
　　要解决这些问题是要靠平时的积累，具体体现到前端是：
　　1 在不停的迭代中，你的业务流程是不是最优(产品到设计到前端到最终上线流程)
　　2 在不停的迭代中，是否沉淀出来了公共服务与工具化服务
　　2好的前端是什么样的?
　　首先，好的前端是一定愿意加班的，同时，好的前端是会找办法让团队少加班的。
　　和一些朋友做过交流，很多好的点子，改善工作效率的点子都是几个人讨论后私下晚上搞出来，然后反复实践用于生产的。
　　一般来说业务kpi对于能力强的朋友来说不会太难，所以对他们的期待也会更多：
　　有强烈的意识，能深刻了解到当前项目性能的缺陷，开发效率低下的原因，并会找寻处理办法
　　很多团队在快速迭代中会开始“欠账”，时间久了就不愿意还，问题的存在搁置需要想办法去解决，团队成员是看得到问题的，没人说，没人做是因为知道那是坑，你如果能解决的话，一到二次便能提升自己在团队中的位置。
　　好的前端应该有良好的架构设计能力
　　首先，好的前端能向人清晰有条理的描述自己的技术方案，并且让人听得懂!
　　然后架构设计能满足长久的需求发展，就算业务频道扩大了10倍，用户量增加了100倍，也不会有根本的变动。
　　好的前端应该具有良好的交流能力
　　对内，好的前端需要了解团队成员的性格与能力，做出适当的任务分配分解;对外，需要抢占业务还不能产生利益冲突，这类人是项目推进的主力。
　　3小公司的前端应该怎么做?
　　不是所有的小公司都这样，但是我见过的小公司的前端都在扑业务，并且疲于奔命，这个是个恶性循环，第一次做业务：
　　加班赶业务-业务结束轻松一周-加班赶迭代-业务结束轻松一周-加班新业务-业务结束轻松下……
　　偶尔你会问这些朋友为什么没有什么积累，得到的答案基本是一致的，忙啊!他们忙起来的时候是真的很忙，但是第二次如果依旧这么忙的话就有问题，第三次还这样就是团队不健康了，一个好的做法是：
　　① 完成前后分离，这步做不到，后面也不用做了
　　② 形成几套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方案应该是每一个成熟团队必须的，持续优化这些都是建立在有效的数据监控与意见反馈机制上的，我们不能做完网站变成瞎子。     

---

　　传智的web前端培训课程一直紧随市场发展脚步，实时更新前沿、深度、覆盖面广的前端课程。
　　传智全新升级的前端与移动开发课程新增了大热的小程序+小游戏、人脸识别、机器学习、大数据可视化等前沿技术，还加入了前所未有的全终端大型项目，让学员通过一个大型项目掌握从需求到开发再到上线部署的各项技能，为学员高薪就业增加砝码。
　　更多的相关web前端培训课程请访问：http://www.itcast.cn/web/

　1什么是优秀的前端团队?

　　团队初期缺什么
　　在公司中，层级越高对业务关注比例越高，反而不太关注个人成长，所以评价一个leader是以团队为单位，团队成员比他强是应该的;对于个人来说的话，要多关注自身能力成长，然后能力匹配自己的职位，甚至超出自己的职位，这样的团队的话，战斗力是比较强的。
　　主管(包括前端主管)设定目标必须可量化 ，比如你做一个业务，kpi是多少，那么技术就需要考虑如何才能达成，细化到研发甚至前端层级，就是所谓技术kpi了。
　　比如，今年H5站想达到单日平均出票量10000，那么这个就是业务目标，需要消化分到各个业务团队，可以是：
　　① SEO优化
　　② SEM优化
　　③ 营销广告
　　④ 微信&支付宝&手机百度流量接入(微信钱包是十分优秀的流量入口，可以极大程度的增加流量)
　　⑤ 实地推广
　　……
　　以上当然只能解决部分问题，具体到前端，可能我们就要从页面转换率入手，建立订单漏斗模型，做性能优化，做交互优化，每一个具体的层面都需要转化目标。
　　这些都是直接可量化的东西，因为当前业务已经到了一个瓶颈，或者公司已经到了一个瓶颈，业务上就需要做不停的尝试，对应到技术就是需要你快速迭代，低成本迭代，不断的容错试错。
　　这个时候就会提出很多问题：
　　第一是你的团队在类似高压下会不会主动加班去实现公司的目标、个人的kpi。
　　第二是你的团队在这轮高压拼搏后有没有留下什么东西?
　　根据之前经验，没有团队可以无休止的承受高压加班的压力
　　以之前携程无线高压迭代的经历来说，就算是那么优秀的团队事实上到后期也是疲惫不堪，疲惫的时候容易犯错，亢龙有悔，盈不可久。
　　第三是如何帮助新人快速的融入团队，如何让1+1=2。
　　我们都清楚，好的项目绝不是堆人可以堆出来的，如何让一个项目可以分解到各个人手中，如何让良莠不齐的同事可以更好的协作，这个是我们需要考虑的。
　　要解决这些问题是要靠平时的积累，具体体现到前端是：
　　1 在不停的迭代中，你的业务流程是不是最优(产品到设计到前端到最终上线流程)
　　2 在不停的迭代中，是否沉淀出来了公共服务与工具化服务
　　2好的前端是什么样的?
　　首先，好的前端是一定愿意加班的，同时，好的前端是会找办法让团队少加班的。
　　和一些朋友做过交流，很多好的点子，改善工作效率的点子都是几个人讨论后私下晚上搞出来，然后反复实践用于生产的。
　　一般来说业务kpi对于能力强的朋友来说不会太难，所以对他们的期待也会更多：
　　有强烈的意识，能深刻了解到当前项目性能的缺陷，开发效率低下的原因，并会找寻处理办法
　　很多团队在快速迭代中会开始“欠账”，时间久了就不愿意还，问题的存在搁置需要想办法去解决，团队成员是看得到问题的，没人说，没人做是因为知道那是坑，你如果能解决的话，一到二次便能提升自己在团队中的位置。
　　好的前端应该有良好的架构设计能力
　　首先，好的前端能向人清晰有条理的描述自己的技术方案，并且让人听得懂!
　　然后架构设计能满足长久的需求发展，就算业务频道扩大了10倍，用户量增加了100倍，也不会有根本的变动。
　　好的前端应该具有良好的交流能力
　　对内，好的前端需要了解团队成员的性格与能力，做出适当的任务分配分解;对外，需要抢占业务还不能产生利益冲突，这类人是项目推进的主力。
　　3小公司的前端应该怎么做?
　　不是所有的小公司都这样，但是我见过的小公司的前端都在扑业务，并且疲于奔命，这个是个恶性循环，第一次做业务：
　　加班赶业务-业务结束轻松一周-加班赶迭代-业务结束轻松一周-加班新业务-业务结束轻松下……
　　偶尔你会问这些朋友为什么没有什么积累，得到的答案基本是一致的，忙啊!他们忙起来的时候是真的很忙，但是第二次如果依旧这么忙的话就有问题，第三次还这样就是团队不健康了，一个好的做法是：
　　① 完成前后分离，这步做不到，后面也不用做了
　　② 形成几套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方案应该是每一个成熟团队必须的，持续优化这些都是建立在有效的数据监控与意见反馈机制上的，我们不能做完网站变成瞎子。     

---

　　传智的web前端培训课程一直紧随市场发展脚步，实时更新前沿、深度、覆盖面广的前端课程。
　　传智全新升级的前端与移动开发课程新增了大热的小程序+小游戏、人脸识别、机器学习、大数据可视化等前沿技术，还加入了前所未有的全终端大型项目，让学员通过一个大型项目掌握从需求到开发再到上线部署的各项技能，为学员高薪就业增加砝码。
　　更多的相关web前端培训课程请访问：http://www.itcast.cn/web/