好的前端是什么样的？小公司的前端应该怎么做？
本文分享一位在大城市，回到家乡小城市的web前端工作经历，主要讲述小城市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为例，这个组件事实上是一个聚合组件，由一个select组件与一个弹出层组件组成，你的UI是不是可拆分是评价他质量的一个很大考虑点。
公共服务可以说成一个大一点的“UI组件”，但是他是与业务相关的，UI来说一般不会与业务产生耦合，以上面的日期选择器来说，无论他装的是日期还是区域都是可以的，并且不应该请求服务，他是纯净的UI组件。
而公共服务是不纯净的是一定与业务相关的，移动端比较常见的公共服务是：
包含登录注册、个人资料管理，甚至包含一些认证相关的，与公司账号相关的操作，登录注册是各种活动，各种业务频道都可能会使用的业务，这种东西是必须服务化的，但是很多小公司都没做。
因为公共的特点，页面设计最好中性一点，其中几个常用的页面，比如登录需要包含以下设计：
① 样式可定制化（弹出层、独立页面什么的都是常事）
② 回退可定制，其实所有的公共服务回退按钮都是需要定制的，登录成功去哪个URL登录失败去哪个URL，点击浏览器回退去哪个URL都得约定，少一个都不是公共服务
③ 单点登录，事实上初期根本用不到什么单点登录，甚至大家都不是跨域的，所以后续需要再支持即可
还有很多与passport一样的公共业务，比如：
① 钱包服务，包括用户支付订单相关管理
② 城市列表，这个要考虑参数如何传递
③ 反馈系统
④ 公司介绍
除了面向C端的公共页面服务，还会有面向B端的统计平台相关。
前端工具化
静态资源处理
评价一个前端团队是否优秀成熟的评判多以团队工具化的程度，一个简单的例子是：
① 你们前端静态资源是如何组织的、如何打包的
② 你们前端静态资源是如何解决缓存的（比较好的方案是MD5）
上面两点可以使用grunt/gulp一类的构建工具轻松做到，如果有公共框架文件还会需要引入种子文件的概念
另外，所有前端团队都会遇到跨域问题，特别是前后分离后，服务器端只提供API接口，前端代码随便在哪都能运行，那么这个时候你是怎么做呢？
① 使用fiddler&charles做代理
② 提供测试服务器
③ 支持jsonp跨域
④ 支持cors跨域
那么这些方案，哪种最适合团队，哪种成本最低（一般来说是代理），是我们需要考虑的
tips：我之前使用fiddler，现在换mac了使用charles，两款工具十分优秀，正则一块的处理很好，推荐使用
移动端适配
从后端转到前端的同学一般在业务逻辑上有一些天生的优势，但是往往在CSS一块比较弱，如何在开发人员无感的情况下引入rem，如何与现有机制无缝的使用less，如何处理单页应用中css的污染，这个是框架底层需要考虑的。
模块化&组件化开发
团队上规模后，如何使用模块化开发处理协作问题；业务代码复杂度上升后，如何使用组件化编程思维简单开发复杂度，这些需要应用到项目实践中，并且路径是可复制的；
一些优化手段，也需要工具化，框架化，让开发人员无感。
前后端协作
前端与服务器端，开发速度未必同步，事实上很多时候都不是同步的，在已经约定了接口格式的情况下，接口还没有写好，但是前端依然能写交互，团队是如何写这种假数据，这个方面实现会大大的提升工作效率。
订单下降分析
如果在某一个时间段，全站的流量或者全站的订单量下降了，你如何跟踪这次下降的原因，如何最大程度上避免下次出现类似的现象，这个时候数据统计会避免我们成为瞎子，所以得尽快建立统计平台，转换率模型。
快速迭代，通过迭代来优化产品，但是如果每一个迭代都完全颠覆了之前的设计，很多时候公司就是原地踏步，每迈出一步你要清晰的知道前一个版本哪里出了问题，针对问题做优化，而不是频繁改版。
这次改版后，你如何知道这次优化就比上一次的好，而不是其它因素造成，ABTesting方案应该是每一个成熟团队必须的，持续优化这些都是建立在有效的数据监控与意见反馈机制上的，我们不能做完网站变成瞎子。
* 作者：叶小钗（@欲苍穹）
* 本文转载自：http://www.cnblogs.com/yexiaochai/p/5311712.html
* 免责声明：转载文章和图片均来自公开网络，版权归作者本人所有，推送文章除非无法确认，我们都会注明作者和来源。如果出处有误或侵犯到原作者权益，请与我们联系删除或授权事宜。
“阅读原文”
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点有做web前端的朋友请进，web前端学好很难吗比后端如何，师傅说前端不容易啊，迷茫中_百度知道
有做web前端的朋友请进，web前端学好很难吗比后端如何，师傅说前端不容易啊，迷茫中
答题抽奖
首次认真答题后
即可获得3次抽奖机会，100%中奖。
虚拟主机5TOM
来自电脑网络类芝麻团
虚拟主机5TOM
采纳数：103
获赞数：467
参与团队：
做一个好的web前端工程师，首先需要有一定的审美技能，设计能力。其次就是一些前端技术了比如要有以下技能1、js + css + html + xml...；2、一些美术、UI设计能力；3、分析研究能力，用来分析研究需求、构架等；4、用户体验、交互设计方面的知识；5、一些产品设计方面的知识；做好一名后端工程师，那就是一个思维逻辑性问题了，如何实现这个模块功能，你只要做到实现这个功能就可以了。至于技术么，那就需要你至少懂一种后台交互性语言和数据库也就是职业定位的问题，看您主要是喜欢哪方面的，你喜欢设计一些美感的东西那么你就做前端，你对实现一些功能逻辑感兴趣，那么就从事程序设计了
采纳数：730
获赞数：2935
后端是纯技术，前端要会设计，有头脑，有技术，相对于要求更高点。
那是不是说比起后端前端更加的难学罗
前端学的东西多，要求的高。但是不太难学。
来自电脑网络类芝麻团
自从接触网站开发以来到现在已经有六个年头了，今天偶然整理电脑资料看到当时为参加系里面一个比赛而做的第一个网站时，勾起了在这网站开发道路上的一串串回忆，成功与喜悦、烦恼与纠结都历历在目，感慨颇多。在此与大家分享，希望对初学Web前端的各位童鞋来说有所帮助。欢迎各位吐槽、拍砖。先从大家学习上的一个误区开始谈起。前端开发是一个近几年兴起的新兴行业，所以远没有电子商务那样成熟的课程体系，大学内也没有完整的前端课程体系，所以学习前端在国内无非就是培训，以及自学。培训是针对那些有条件的人来说，很多小伙伴更喜欢的是自学。但是一个人自学毕竟力量是有限的，为了让想学习的人可以更好的学习，给大家推荐一个裙，前面是6 1 1，中间是肆 二 8，最后面就是壹 四 &二，这里有很多想学习的人和你一起交流，也有大牛每天晚上免费教学，想要学习的人都可以加入我们，但是我们只欢迎想学习的人，不是来学习，随便看看的就不要进了。Web前端的学习误区　网页制作是计算机专业同学在大学期间都会接触到的一门课程，而学习网页制作所用的第一个集成开发环境（IDE）想必大多是Dreamweaver，这种所见即所得的“吊炸天”IDE为我们制作网页带来了极大的方便。　　入门快、见效快让我们在不知不觉中已经深深爱上了网页制作。此时，很多人会陷入一个误区，那就是既然借助这么帅的IDE，通过鼠标点击菜单就可以快速方便地制作网页。　　那么我们为什么还要去学习HTML、CSS、JavaScrpt、jQuery等这些苦逼的代码呢？这不是舍简求繁吗？　但是随着学习的深入，就会发现我们步入了一种窘境——过分的依赖IDE导致我们不清楚其实现的本质，知其然但不知其所以然。因此在页面效果出现问题时，我们便手足无措，更不用提如何进行页面优化以及完成一些更高级的应用了。其原因是显而易见的——聪明的IDE成全了我们的惰性，使我们忽略了华丽的网页背后最本质的内容——code。正确的方向胜过无谓的努力　有两只蚂蚁想翻越一段墙，寻找墙那头的食物。一只蚂蚁来到墙脚就毫不犹豫地向上爬去，可是每当它爬到大半时，就会由于劳累、疲倦而跌落下来。虽然它不气馁，一次次跌下来，又迅速地调整一下自己，重新开始向上爬去。　另一只蚂蚁观察了一下，决定绕过墙去。很快，这只蚂蚁绕过墙来到食物前，开始享受起来；而另一只蚂蚁还在不停地跌落下去又重新开始。　　很多时候，成功除了勇气、坚持不懈外，更需要方向。也许有了一个好的方向，成功来得比想象的更快。如果在错误的路上奔跑,再怎么努力也是白搭。学习Web前端也是如此，首先应该选择一个正确的学习路线。　　Web前端的学习路线结合我的学习经历、近年来辅导学生的经验以及公司中实际项目的需求，在这里将Web前端的学习分为以下几个阶段第一阶段——HTML的学习。　超文本标记语言（HyperText Mark-up Language 简称HTML）是一个网页的骨架，无论是静态网页还是动态网页，最终返回到浏览器端的都是HTML代码，浏览器将HTML代码解释渲染后呈现给用户。因此，我们必须掌握HTML的基本结构和常用标记及属性。　　HTML的学习是一个记忆和理解的过程，在学习过程中可以借助Dreamweaver的“拆分”视图辅助学习。在“设计”视图中看效果，在“代码”视图中学本质，将各种视图的优势发挥到极致，这种对照学习的方法弥补了单纯识记HTML标签和属性的枯燥乏味，想必对各位初学的小盆友们来说必定是极好的！在学习了HTML之后，我们只是掌握了各种“原材料”的制作方法，要想盖一幢楼房就还需要把这些“原材料”按照我们设计的方案组合布局在一起并进行一些样式的美化。　　于是进入第二个阶段——CSS的学习。CSS是英文Cascading Style Sheets的缩写，叫做层叠样式表，是能够真正做到网页表现与内容分离的一种样式设计语言。相对于传统HTML的表现而言其样式是可以复用的，这样就极大地提高了我们开发的速度，降低了维护的成本。　　同时CSS中的盒子模型、相对布局、绝对布局等能够实现对网页中各对象的位置排版进行像素级的精确控制。通过此阶段的学习，我们就可以顺利完成“一幢楼房”的建设。　　“楼房”建设完成之后，我们可以交给用户使用，但是如果想让用户获得更佳的体验，我们还可以对“楼房”进行更深一步的“装修”，让它看起来更“豪华”一些。为了完成这个任务，我们进入第三个阶段——JavaScript的学习。JavaScript是一种在客户端广泛使用的脚步语言，在JavaScript当中为我们提供了一些内置函数、对象和DOM操作，借助这些内容我们可以来实现一些客户端的特效、验证、交互等，使我们的页面看起来不那么呆板，屌丝瞬间逆袭高富帅！有么有？此时，也许你还沉浸在JavaScript给你带来的惊喜之中，但你的项目经理却突然对你大吼道:“这个效果在××浏览器下不兼容，重新搞……”“不兼容？”瞬间石化了有木有？“我擦，坑爹啊！那可是花了我一个晚上写了几百行代码搞定的啊，吐血了都!”JavaScript的兼容性和复杂性有时候的确让我们头疼，还好有“大神”帮我们做了封装。接下来我们进入第四个阶段——jQUery的学习。jQuery是一个免费、开源的轻量级的JavaScript库，并且兼容各种浏览器（jQuery2.0及后续版本放弃了对IE6/7/8浏览器的支持），同时现在有很多基于jQuery的插件可供选择，这样在我们实现一些丰富的动态效果时更方便快捷，大大节省了我们开发的时间，提高了开发速度，这也充分体现了其write less,do more的核心宗旨。这个Feel倍儿爽！有么有？“豪华大楼”至此拔地而起，但是每天这样日复一日，年复一年的盖楼，好繁琐！能不能将大楼里面每一个单独部件模块化，当需要盖楼时就像堆积木一样组合在一起，这样岂不是爽歪歪？可以实现吗？答案是肯定的。这种思想在Web前端开发中也是适合的，于是乎就出现了各种前端框架，在这里推荐给大家的是Bootstrap。 Bootstrap是Twitter推出的一个开源的用于前端开发的工具包，是一个CSS/HTML框架，并且支持响应式布局。一经推出后颇受欢迎，一直是GitHub上的热门开源项目。在项目开发过程中，我们可以借助Bootstrap提供的CSS样式、组件、JavaScript插件等快速的完成页面布局和样式设置，然后再有针对性的微调样式，这样基于框架进行开发大大缩短了开发周期。站在巨人的肩膀上就是爽！Web前端的学习建议最后给大家聊聊在学习Web前端中的一些建议和方法。在CSS布局时需要注意的一个问题是很多同学缺乏对页面布局进行整体分析，不能够从宏观上对页面中盒子间的嵌套关系进行把握，就急于动手去做，导致页面中各元素间的关系很混乱，容易出现盒子在浮动时错位等情况。建议大家在布局时采用“自顶向下，逐步细化”的思想，先用几个盒子将页面从整体上划分，然后逐步在盒子中继续嵌套盒子。“君子生非异也，善假于物也”，在学习的过程中还要多浏览一些优秀的网站，善于分析借鉴其设计思路和布局方法，见多方能识广，进而才可以融会贯通，取他人之长为我所用。同时还要善于使用Firebug这个利器。Firebug一方面可以在我们学习过程中帮助我们调试自己的页面，另一方面我们可以使用Firebug方便地查看、分析别人网站的源代码，“偷”也是一种技能！随着移动互联网热潮的到来，移动开发越来越受到大家的追捧，响应式布局、微网站等需求量不断增加，也是我们Web前端未来的发展方向之一，学有余力的同学可以多多关注。最后祝愿大家能在Web前端开发道路上走出一片更宽更广的天地！
为你推荐：
其他类似问题
您可能关注的内容
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。好的前端是什么样的？小公司的前端应该怎么做？
本文分享一位在大城市，回到家乡小城市的web前端工作经历，主要讲述小城市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为例，这个组件事实上是一个聚合组件，由一个select组件与一个弹出层组件组成，你的UI是不是可拆分是评价他质量的一个很大考虑点。
公共服务可以说成一个大一点的“UI组件”，但是他是与业务相关的，UI来说一般不会与业务产生耦合，以上面的日期选择器来说，无论他装的是日期还是区域都是可以的，并且不应该请求服务，他是纯净的UI组件。
而公共服务是不纯净的是一定与业务相关的，移动端比较常见的公共服务是：
包含登录注册、个人资料管理，甚至包含一些认证相关的，与公司账号相关的操作，登录注册是各种活动，各种业务频道都可能会使用的业务，这种东西是必须服务化的，但是很多小公司都没做。
因为公共的特点，页面设计最好中性一点，其中几个常用的页面，比如登录需要包含以下设计：
① 样式可定制化（弹出层、独立页面什么的都是常事）
② 回退可定制，其实所有的公共服务回退按钮都是需要定制的，登录成功去哪个URL登录失败去哪个URL，点击浏览器回退去哪个URL都得约定，少一个都不是公共服务
③ 单点登录，事实上初期根本用不到什么单点登录，甚至大家都不是跨域的，所以后续需要再支持即可
还有很多与passport一样的公共业务，比如：
① 钱包服务，包括用户支付订单相关管理
② 城市列表，这个要考虑参数如何传递
③ 反馈系统
④ 公司介绍
除了面向C端的公共页面服务，还会有面向B端的统计平台相关。
前端工具化
静态资源处理
评价一个前端团队是否优秀成熟的评判多以团队工具化的程度，一个简单的例子是：
① 你们前端静态资源是如何组织的、如何打包的
② 你们前端静态资源是如何解决缓存的（比较好的方案是MD5）
上面两点可以使用grunt/gulp一类的构建工具轻松做到，如果有公共框架文件还会需要引入种子文件的概念
另外，所有前端团队都会遇到跨域问题，特别是前后分离后，服务器端只提供API接口，前端代码随便在哪都能运行，那么这个时候你是怎么做呢？
① 使用fiddler&charles做代理
② 提供测试服务器
③ 支持jsonp跨域
④ 支持cors跨域
那么这些方案，哪种最适合团队，哪种成本最低（一般来说是代理），是我们需要考虑的
tips：我之前使用fiddler，现在换mac了使用charles，两款工具十分优秀，正则一块的处理很好，推荐使用
移动端适配
从后端转到前端的同学一般在业务逻辑上有一些天生的优势，但是往往在CSS一块比较弱，如何在开发人员无感的情况下引入rem，如何与现有机制无缝的使用less，如何处理单页应用中css的污染，这个是框架底层需要考虑的。
模块化&组件化开发
团队上规模后，如何使用模块化开发处理协作问题；业务代码复杂度上升后，如何使用组件化编程思维简单开发复杂度，这些需要应用到项目实践中，并且路径是可复制的；
一些优化手段，也需要工具化，框架化，让开发人员无感。
前后端协作
前端与服务器端，开发速度未必同步，事实上很多时候都不是同步的，在已经约定了接口格式的情况下，接口还没有写好，但是前端依然能写交互，团队是如何写这种假数据，这个方面实现会大大的提升工作效率。
订单下降分析
如果在某一个时间段，全站的流量或者全站的订单量下降了，你如何跟踪这次下降的原因，如何最大程度上避免下次出现类似的现象，这个时候数据统计会避免我们成为瞎子，所以得尽快建立统计平台，转换率模型。
快速迭代，通过迭代来优化产品，但是如果每一个迭代都完全颠覆了之前的设计，很多时候公司就是原地踏步，每迈出一步你要清晰的知道前一个版本哪里出了问题，针对问题做优化，而不是频繁改版。
这次改版后，你如何知道这次优化就比上一次的好，而不是其它因素造成，ABTesting方案应该是每一个成熟团队必须的，持续优化这些都是建立在有效的数据监控与意见反馈机制上的，我们不能做完网站变成瞎子。
* 作者：叶小钗（@欲苍穹）
* 本文转载自：http://www.cnblogs.com/yexiaochai/p/5311712.html
* 免责声明：转载文章和图片均来自公开网络，版权归作者本人所有，推送文章除非无法确认，我们都会注明作者和来源。如果出处有误或侵犯到原作者权益，请与我们联系删除或授权事宜。
“阅读原文”
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点