winter讲述了在阿里的第三个整年，这些年里做过的事情的一些总结，主要关于前端发布方式、分离与同构、向服务端延伸、向客户端延伸、性能和工具和库等方面。并回答了关于前端开发的一些问题，值得看看。
在这个双十一结束的点上，打算分享点东西，其实我一直乐意写些实在的技术点，因为不同环境里工程手段和团队发展很不一样。不过到这个双十一是我在阿里的第三个整年，我想把这些年里我们做的真正重要的事总结总结。
发布
在我来阿里之前，其实没太想过发布这个事情，在阿里的时候，也没想过发布方式是如此重要，不过最开始来的时候，听说前端跟服务端的配合方式吓了一跳：前端产出demo页面，服务端负责把参考html代码来写vm（就是velocity模板，阿里是用Java的），这个过程就是传说中的“套页面”了，这个过程往往不是那么愉快的，有时候服务端的同学会把标签嵌套搞错，前端出了bug，则需要服务端重新改模板。这个模式我一开始确实觉得不妥，但是并没有把它当做非常严重的事情而，直到后来回忆起来，我才知道当时的想法错的有多么离谱。
然而我运气特别好，在我自己没有做出正确判断的情况下，这个问题被服务端同学解决了——虽然我们当时脑子里想的都是“要搞webapp”。当时我们对WebApp的理解是单页应用，那么以静态页面+AJAX就是首选方案了，于是服务端同学帮我们搭建了一个叫做AWP的发布平台，和一个CDN源站，又驱动把h5.m.taobao.com这个域名（我知道你们要吐槽这个域名……历史啦历史原因）指向了CDN，这个事情对CDN来说也有划时代的意义，我们稍后再说。
从今天的视角来看，这个发布平台第一次让前端工程师有了向线上的发布能力，之前前端工程师基本都是发布资源文件和提供素材的，这个事情之后，前端工程师开始有真正意义上的“发布”，我之前跟团队同学开玩笑说，在这之前，前端连搞出线上故障的能力都没有——不要以为这是好事，没风险意味着没价值。
分离与同构
接下来一个很重要的事情，是手机淘宝目前的一个核心能力有关——API网关，通俗点说，就是所有的服务端提供API，而且通过统一的出口提供出来。这个便利条件，促成了一个前所未有的前端开发模式：前端开发纯静态页面，跟客户端调用同一套服务端API。
这个模式深度地解决了两个关键问题：
- 前后端分离
- 前端客户端同构（当然这里还不是彻底的同构）
当然这个方案有得的同时，也有舍弃：它舍弃了服务端渲染的能力。而对手机淘宝的业务和架构来说，这个做法是合时宜的。这时候的一些放弃，也为接下来也为后续的一些发展做了铺垫。
另一个对同构非常重要的，是手机淘宝的导航系统，这个事情我原以为也是比较无意中达成的，但是去年手淘Android架构师离职的时候跟我坦诚他暗中推动了很多，看来世上没有那么多偶然啊:)。总之从某个时期开始，我发现手淘的业务形态开始以页面为单位组织，所以顺道跟团队的人一起，推动了几件事：
- 业务以页面为单位组织
- 每个”页面”，具有切换Web和Native的能力
- 页面对应url（基础业务不论web还是native都对应taobao:协议，手淘打开web页面对应taobaovebview:协议）
这个形态让手淘变成了一个类似浏览器的东西，从业务的角度，让子业务在Native和Web之间切换更低成本，也让后来Weex等方案的诞生有了土壤。
向服务端延伸
其实说到全栈，大家一般的印象是高手、全能，感觉很遥远。但是其实并不一定是如此。我们试图用一种更亲和前端的方式去推动全栈化。考虑到阿里的服务端基本上涉及的量会比较大，需要一定的性能和容量意识，只能要求少数人去获得真正意义上的服务端开发能力。
所以我盯上了一样东西——CDN。CDN的回源服务，它的前面有CDN缓存挡着，相对来说需要承载的压力是比较低的，非常适合前端来维护。业务上，我则选择了运营业务，因为运营业务特点鲜明，页面生存周期短，短期内爆发性量大，服务端申请机器大张旗鼓搞集群也是一种浪费。
一旦脑洞开了，就会发现其实这个方向上能做的事情就变得多了起来，因为CDN+回源服务的模式在面对大流量时有极大优势，所以我们发现，非个性化的、非隐私的数据，其实都可以这么搞，最典型的场景是全局配置、运营推荐的导购内容等。到后来时，一些客户端的同学也开始用这个静态集群上面的服务。
我们的使用方式也让CDN从一个静态资源服务逐渐变成了一部分业务的载体，这种CDN的使用方式，也是不多见的，幸好阿里CDN团队是很喜欢面对新挑战的，甚至帮我们做了ABTest。
向客户端延伸
其实我特别想写这一段请直接参考勾三股四的文章……
Weex是原来WeApp的基础上发展起来的，中间经历两次大规模的重构，第一次重构，代码几乎全部重写，第二次，整个设计方案全变，从原来的服务端设计变成前端设计。
其实Weex主要的功臣和贡献者不止前端，负责Android和iOS实现的、以及服务端的同学都付出了巨大努力，而双十一会场的前端@mingelz 似乎也不明不白地被拽进坑里……
勾三股四已经写了四篇，技术上我就不重复了，其实我想说的是，我们从2013年就开始干这件事，这项目一开始坑到首批参与者几乎全部离职只剩下一个搞客户端的还在……光重写就两遍，一个玩具和一个真正能用的技术方案之间，差距就是如此。（所以拜托某些围观群众不要说我们造轮子了好么，不是所有外国东西都比中国东西早的）
性能
我挺早就提出来过一个观点——一切不做profiling的性能优化都是耍流氓。
现在我觉得应该改改：一切没有线上监控的性能优化都是耍流氓。
性能这块网上的文章很多，看上去写的认真的也有很多，但仔细看其实有些错的挺离谱的。你不亲身经历一遍，没法体会到，真机测试跟你想象之间的区别，以及测试环境跟线上之间的区别。
我一直觉得性能最适合驱动的是前端，前端是距离用户最近的代码，所以前端应该做的，不仅仅是以前端的角度去解决问题，从一个url到一个页面的过程，涉及到WebView、网络层、DNS、运营商、服务端等各个环节，找出问题，分析原因，设计方案，推动解决，这是一个完整的性能优化过程。
我们比较幸运的是，我们有一群靠谱的合作伙伴，HTTPDNS、SPDY、ZCache等等技术方案，给我们带来了充足的弹药，但是再好的东西也需要人去用，前端在这件事上，必须明确自己owner的角色，对最终结果负责。
工具和库
这个事情我又要反省，我早先对node的判断是有问题的，我一开始把node看做“只是另一个服务端解决方案”，然而忽视了node在工具方面的价值和npm的价值。所以现在我们正在做亡羊补牢的是：工具链和基础库的npm化。
任何一个搞自己的库的团队总会被质疑在造轮子。我们的基础库从最开始的base.js，逐步发展到lib系列，到现在的npm化，自己搞的原因只有一个——我们更好。我们的基础库最好的地方就是坚持了单一职责的原则，没胡乱塞东西，这也让性能优化成为了可能。
工具链方面，我们则采取了全然不同的策略，几乎是全面贯彻了“拿来主义”，我们要做的，是把babel、sass、browserify、uglify、webpack、gulp等工具做整合，形成真正意义的工程体系，最近大家也在畅想，我们是否能能把构建、调试、发布等功能集成起来，做成一个ide？这应该是下一个双十一之后该讲的故事了。
结语
前端一直是一个变化很快的职能，它太年轻，年轻意味着可能性和机会，也意味着不成熟和痛苦。自加入手淘前端来，我经常担心的事情就是，我们团队每一天都在做一样的事，或者在不断跟随和尝试，最终一无所获。所幸至今回顾，每年还是总有点不同，也算给行业贡献了些经验值吧。
ITA1024互联网技术联盟微课堂Q&A实录问答
前端问答
问：winter老师 您提到建立知识体系 我想很多人在最开始的时候 遇到第一个困难就是怎么去建立一个知识体系不知道树上应该有什么。您能给点建议么，从哪里入手比较好？
winter：要先找到线索，第一步线索，就是帮你找到知识体系的依据。
问：前端技术做到资深工程师了，再往上走该怎么发展，该掌握什么专业技能？
winter：一般公司的资深工程师，我认为是编程能力比较好，架构能力有一点，工程能力可能刚刚起步或者没有，是这个标准。再往后，应该是重点发展后面两项能力。
问：是不是我们在遇到一个问题的时候以点带面の学习，知识技术点的关键？
winter：对，但是关键是两点，一是点要足够全（即我所说的线索），二是学的要准，即我介绍的追本溯源过程。
问：现在前端技术层出不穷，你是如何判断这是值得学习或关注的？
winter：很简单啊，我通过我的知识体系去判断，我对前端整个，也是有个体系的，没放出来，是因为我不希望影响大家自己学习和建立体系的过程，产生误导。
问：winter老师对前端来说算法这块能力的培养从什么地方着手呢？
winter：任何算法教材的习题，做一遍，你绝对成为社区大牛，算法专家，一定比我强多了，至少算法导论的习题，我是没做下来的。
问：对原生和框架的学习分别是怎么看的？
winter：原生和框架都要学习，原生是必选项，但是至少以目前的原生的水平，任何大一点的团队都需要框架，要么自己造，要么用别人的，这事同样取决于你的知识体系。
问：寒老师，在团队带人方面有什么经验可以分享的？
winter：带人这话题稍微有点大，而且其实在这一点上我算不上专家，我个人的风格，是比较偏向于人本身的成长的，所以之前我在无线，带的人都发展的不错，但是从整个团队拿到的结果来看，就不算好了。
问: 对于培养前端架构能力这块需要从哪些方面学习提升?
winter：还是前面分享中说的，去找经典的教材，面向对象就看《面向对象分析与设计》，还有TC++PL的最后一章。
问：winter老师，您一般如何快速掌握一个新的前端技术？比如react及相关的redux和reactnative，还有webpack等相关工具，感觉知识量好大，如何才能以最快速度掌握呢？
winter：我觉得并不大，其实这些东西都是Native十年前玩剩下的，比如MVVM吧，大概是07年微软架构师搞出来的，你会突然觉得信息量大，一定是之前你的知识体系出现了较大的空白，刚才分享中没说这个问题，有时候，你给自己贴个标签，比如我只是个前端，但是知识并不是孤岛，别的领域一定会渗透过来的，所以抓住这个机会，好好看看UI架构这十年的变化，你就能预言未来啦。
问：昨天看到新闻，说以后web开发将不再重度依赖js，任何语言都可以用来开发web，而且性能比js高，这个你怎么看待？js会在几年之后没落么？
winter：这个我是赞同的，但是我觉得可能比你想象的要慢一些，另外JS肯定不会没落，纯从编程语言角度看，JS其实挺粗糙，但是目前来看，JS的发展，TC39委员会的工作形态要远远比别的语言先进，所以它会长期统治web，将来也可能下沉，也可能JS会变得跟今天完全不同如另一门语言，当然未来很难预测，这种事看看就好啦。
问：像我这种以前从Android转前端的。刚开始是直接从ja入手。然后写公司跨平台框架。然后以js为基础，拓展，如node什么的，然后研究前端。学习css等。但是到现在就会出现一个瓶颈，就是知识较为广泛，而不精。像会后台，会手机移动，写过unity游戏，会前端，能自己写框架，但是有着致命的弱点，算法不足，没有系统深入研究过算法，感觉没有自己的核心优势。不知道应该从那一方面突破！（目前自己是先准备突破css这个点，然后积累算法，不知这样可好？希望您能给点建议）
winter：其实吧，我觉得哪边都跑不了，所以也不用太纠结，人的精力和时间有限，做你觉得最应该做的事，尽力就好，不要给自己找借口，说网上那个谁谁说了XX根本不用学啊。
问：对现在的大前端，全栈工程师你怎么看？
winter：这是必然结果，分工的目的是让你专精前端，不是让你不会后端，不能画地为牢。
问：业界前端技术这么多繁杂快速变化，大概需要到什么阶段后才容易简化并稳定下来？这个阶段需要具备什么特征？
winter：我觉得现在的前端应该跟几年前的native比较类似，所以看native的发展就可以预测前端的未来啦，之前的html5相当于移动这一波，是底层API的发展，API差不多了，估计就是开发体验的竞争了，等到开发体验出现了霸主，就可以稳定一段了，但是看现在的行业发展速度，估计新的一波又要开始了……
问：以前一直在做浏览器端的工作，最近借nodejs接触了一些服务端的内容，感觉做起来遇到很多困难，需要如何系统的提高一下呢？
winter：这个问题有点难，因为我自己并没有服务端的经验呢，似乎服务端技术并没什么系统的资料，都掌握在各大公司手里，所以我觉得进大公司，学习他们的服务端技术也许比较靠谱。即使是作为前端，我个人在阿里还是觉得服务端方面很有收获。
问：如果现在的工作就是切图，而且加班，没时间学习的话，是不是应该考虑换一份工作？
winter：老实说，我没见过真的忙到没时间学习的人，一般总还有些娱乐和摸鱼的时间，即使我们996期间，也还是有很多自我提高的机会的。假设说真的到这个程度，那我的答案肯定是赶紧走，不说成长，身体也受不了啊。当然，辛苦程度和薪资一般成正比，肯定要牺牲些收入的，但是我个人是不可能选择超出自己能力如此多的岗位的。
问：前端现在范围越来越宽，是否还需要做到全知全能？还是注重在某一方面形向发展？
winter：不可能全能啊，你看80年代那帮搞C的也不行啊…… 你要做的还是专精几种技术和组合出商业价值。
问：问老师，对于一新手前端应该怎么样面对大千前端世界，很容易在多选择化变得迷茫！是专注一点还是全面发展？
winter：这个差不多吧，有情怀的就专精，想赚钱获得社会认可就组合几种技能，不可能真的全面的……
问：winter老师，感觉前端的天花板不太高，在普通的公司前端的地位很难赶上后端，面对这种情况，是学点java或者node方面的知识接触后端，还是加深前端的知识，跳去大公司？
winter：薪资是由人决定的，所以说，其实你转去做别的，是按照你的工资反算级别，不是按照级别重新算工资……这是行业规则。
问：老师推荐看框架源码吗？看源码有什么好的方法呢 平常看容易头晕？
winter：我不看框架源码，因为我觉得他们写的不好。
问：对于不懂后端的同学来说应该先熟悉java php node三选一该怎么选？
winter：你们公司用什么，就选什么，否则你会哭的，相信我。
问：@winter 老师，如何在没有导师或者公司规模达不到的情况下，提高自己的工程能力和架构能力，这两种能力怎么自学提高？
winter：如我分享的，还是得找教材呀，不系统学习，师傅也好，公司也好，都是浮云。
问：再赶快问一个问题，现在前端架构从mvc、mvp已经前进mvvm，未来还会如何演进？mvvm架构的短板是什么？
winter：这个问题我回答不了，这几个架构的创造者无一不是划时代的大师，我觉得我只能跟着学习呀，下一个大师估计不会是我。 mvvm目前是我见过的最完美的架构，我只能从使用的角度来看，它最大的问题在于，让整个团队理解并且实施，还是挺困难的。
问：像你刚才说的追溯技术源头的过程，一般都有哪些渠道呢？
winter：看我分享噢，里面有讲到，先去wiki找历史，再去google搜原始的论文。还有邮件列表啦，代码提交记录啦，都是不错的资料。
问：如何看待现阶段浮躁的前端环境？
winter：每个时代大家都觉得浮躁，因为其实有不少伟大而低调的技术方案的创造者在踏踏实实干活不肯出来说话呢。
问：winter老师，在前端开发现在极度依赖框架的情况下，是否还需要从JS最基础方法和浏览器相关接口开始学习？就jQuery的使用而言，可以说很多JS原生的东西都是被颠覆了，学习了原生用法可能反而不利于学习jQuery等框架。
winter：这个嘛，我觉得是一派胡言，jr他自己敢说颠覆原生么？而且等你真的做到比较资深，你会发现，所谓API风格这种东西，根本就没什么工作量和实际意义，原生的确是繁琐，也不能说好到哪里去，但在我看来，还是比jq强一点的。至于说学了原生以后不利于学习jq，那说明没真学明白。
问：只是一种感觉吧 大量的人涌入前端 正正做事的人还是在少数 在这种时候 如何选择？
winter：选择真正做事呗……
问：前几天看到H5OS已经开始部署市场，还有有中国势力的出现，未来对于这种H5部署的手机系统有什么看法？真的能成为android的竞争对手吗？google的sky的语言发展会不会对前端技术有一定影响呢？
winter：这事别想了，Android上又不是没有H5，操作系统竞争靠的是私有技术，没听说过功能比别人少能拿来当卖点的。
问：对于移动端开发，特别是很多国产浏览器，如何能够比较有效率的进行兼容性测试，采用什么使用api的策略，能规避一些坑？
winter：这个嘛，比较复杂，我们的做法是测试要定开发调试机型（大概三五种）和发布机型（30多种）两档，再根据caniuse数据反算一个icanuse列表，再由架构团队来决定，哪些要，能pollyfill。
问：winter老师，对于很多企业前端框架来说，旧有的框架很快会成为未来重构的负担，如何持续保持企业前端框架的先进性，适应未来的发展？为什么天猫采用react？而不是在原有框架改进？企业中这种大规模的替换成本很高。
winter：其实保持框架先进性是个伪命题，企业没这个需要，只有权衡利弊来选择框架。天猫的情况我倒了解一些，这个基本上是必须要还的技术债，之前基于Kissy的mui太过于沉重，修改的代价大于推倒重来呗。
问：移动端M页开发，有前端架构科学合理，工程化特别高的网站推荐吗？
winter：嗯，手机淘宝应该算比较好的吧，但是还是有很多旧页面和别的bu的页面，这个就没办法了。
问：@winter 我最想前端技术回到win32时代拖控件可视化开发模式，但是就连微软也是把asp.net、asp MVC扔了又扔，啥时候重回唐朝啊？是不是一直没戏了？
winter：这个嘛，我觉得不是没有拖控件，而是现在的UI，它基本是自动排版，而不是固定位置，所以我觉得是IDE懒得搞啦，而且恰好赶上新技术大量出来，竞争的焦点不再开发体验而在于功能，毕竟后者才是真金白银呢。
问：手机淘宝注意到首页是全部由touch来做的滚动，这在一些安卓原生浏览器对translate属性支持不是特别好的时候特别卡顿，淘宝是已经放弃这些浏览器的引入订单了么？
winter：这个决策是根据机型占比来做优化的，大部分机型应该体验会好过原生，如果不行的会降级回原生，不过有些低量手机就管不到了。
问：对ES新出的一堆语法怎么看？是进步还是引起混乱？
winter：当然是进步，但用不好肯定也会引起混乱啊，所以对团队leader和架构师考验更大了。
