jtalk第七期前端场--收获分享

前言

本次分享主要是三个主题吧，一个是阿里通讯染陌大神渐进式pwa的入门级介绍，一个是有赞连成杰分享涉及先后端协做的技术产物zanProxy和zanApi的部分，一个是宋小菜--scott老师关于前端一些方法论的分享。

而后我本身的话大概前端作了三年多一点，分享下本身的感觉吧，有整理不对或者理解不对的，欢迎你们吐槽，咱们从小白到大师慢慢来。

pwa：渐进式web应用

核心介绍特色

• service worker 主要用途以及其生命周期、更新机制

文件请求加载以及数据加载优化，主要是离线场景使用；其api的部分相信大部分开发者查到使用文档并不难，再也不赘述。

• 相关api 不断完善中，但一些已经开发出来的部分对于开发者仍是不错的，好比消息推送
• 桌面快捷入口

提供了一个区别于web浏览器地址和原生应用的中间体验方式，能够添加到主屏；也有技术大神断言，如今的electron（一个使用 JavaScript, HTML 和 CSS 等 Web 技术建立原生程序的框架）就是其以后的发展趋势，能够实如今移动端替代本来的客户端，或者其以后就会和electron实现技术合并，成为前端跨端应用技术。

• 相关推荐

light house是一款chrome插件能够查看web app的性能；pwa.rocks能够查看到已经进行pwa实践的项目；https://github.com/alibaba/ice，https://alibaba.github.io/ice/，阿里的开源项目推荐。

推荐场景

• 对离线使用体验要求高的
• 静态资源或者数据内容变化系数低的应用类型
• 业务初期推广以及相关用户引流以及激活的技术栈

可能瓶颈

谷歌的技术支持不够到位 ，并非全部的中小公司均可以有如此的技术力量去实行； 须要https支持，若是业务的站点还没作升级会有问题； 用户习惯，你的用户要习惯把web应用放到桌面上； 虽然主流浏览器支持，但要求较高的版本，并且其不可预期的问题仍是不少的，部分低端机型仍是有问题的，而不可能放弃这部分用户； 产品体验对离线使用有切实较高的要求； 须要在业务中区分清楚什么状况下使用service-work，若是在不少场景中须要采用就要有细致的区分，增长不少不一样场景带来的测试用例成本、产品定位成本，好比用户离线的时候你让它下单，这条确定是失败的，由于要链接服务器产生真实数据，那么这个业务点其实就是不能离线使用的，还有些数据若是用户对数据真实性敏感的好比股票，若是产品不明确讲明离线的数据是无效的，并阐明就会有相应的问题，固然这些只是更科学的作法，不是由于pwa引来的，而是由于离线你如今有数据的方案带来的体验必然要考虑的工做量与风险。

有赞先后端协做产出

首先，我我的是以为有赞的技术tl以及整个团队方案是很赞的，不但完成了其业务目标，并且完成了技术基础建设，甚至进行了技术开源，做为一家非bat规模的公司，仍是很不错的，因此不少杭州的中小公司都会想参观学习有赞内部究竟这些轮子能作什么事情，有什么缺点。

而后更具体的内容我以为你们看有赞技术开放日那天介绍的比较详细，移步有赞技术开放活动

我本身的我的感觉是： 1 有赞确实在某些痛点上和大多数中小公司是同样的，因此作的方案也是很切中要害的，但我以为其真实的方案可能有两点局限性：与前端业务执行方式和前端总体技术栈挂钩比较不容易解耦；与后端协做的某些细节以及后端对应的技术栈有较强关联。因此在片面的使用它某些技术栈的时候，可能会与本身公司存在不符的状况。 2 技术核心是什么。就技术核心来说，有赞的几个技术成品没有太复杂深刻到其余公司研发团队作不出来或者研究不出来的。但大多数公司更倾向于使用现有的技术成品，好比说请求拦截，开源的是fidder、postman,数据mock有mockjs或者easymock，写api文档有阿里的rap或者swaggar，而缺乏研发人员所应该具备的极客精神。而后ui框架也是的，滴滴出行、饿了么不少公司都有开源出来其ui框架，但公司本身的ui组件却拿不出来，可能更像是因业务堆砌的一堆页面、死组件。

因此，最终我的感受蛮须要反思的，也是更须要向有赞学习的，无论你当前技术栈是什么，有多先进或者落后，扎根于当前分析你们目前能接触到的最优技术栈而且分析其不足并用必定的可行方案作本身研发团队能用的轮子，这点很重要。别人团队再好的东西，不少时候不能直接拿来用的。

• 安利内容：在线编辑代码：Online coding

宋小菜 ，scott老师：前端方法论--套路

我我的来说，其实每隔一段时间就会听一些湿货，更多人喜欢叫方法论，纯技术的人管这个叫套路。本身在毕业后的一年期限的时候，也开始作一名小主管，因此套路这东西从那时就开始慢慢的渗透到本身的管理思想和平常工做中。那么，我结合scott老师有提到的一些点带些案例出来，相信你们会理解的更好。

本能抵触情绪

15年的时候还没开始风行三大框架，大部分的公司仍是先后端未分离，使用bootstrap+jq的时代。咱们公司也是这样的，但即使如此仍是有人分不清js原生语法和jq语法，对jq语法只知其一;不知其二，代码写着写着就掺杂了原生的部分，不少js封装对象知识存在漏洞却以能解决业务需求为理由拒绝学习。好比jq的链式操做、jq插件不会写、js对象的拷贝、js闭包、js数组的复制与删除等。 这时候，你若是和他们推jq的链式操做会建议你如何写，某些dom的操做这样写是性能更快的，这些事件是这样绑定的，他们根本听不进去的。这个场景就和今天，三大框架风行，大部分人只会简单用用，却用很差，殊不知道为何这样用，其源码是如何思考的一无所知很类似的吧。

方法论 ： 1 把正经可用的技术体系搬上技术栈、日程 2 让抵触学习的人在平时的开发中真实的体会到这样写带来的问题，以及推荐的写法带来的优点，并对比的奖励那些写优质代码的人 3 把技术提高部分做为员工技术评级考核的一部分

不能只谈技术革新

老大确定说先把业务搞上去，用啥技术不重要。产品确定说，作业务，加业务。若是你直接谈，给我研发一段时间，去作技术建设，去作代码重构，基本是失败的。在公司小的时候，老大们会说，咱们还没发展到那个阶段。到人多了，老大们会说大家作这个能带来多少业绩增加，或者你能保证这个能带来多大的效率提升么？做为技术推动的你，你也很犹豫，由于一方面你知道目前的方式确定不行，另外一方面，本身想的那个方案由于没有实践经验本身也不敢打保票，而后公司也未曾培养过你这方面的能力。

方法论 ： 1 保留并持续的积累在某个方面问题的解决方案以及其具体的解决能力是什么，反复模拟确人，为沟通提供佐证。 2 寻找合适的破绽时机，好比你预言的某个场景或者问题爆发了，而后和老大去谈，这个问题我有比较成熟的方案能够去推动解决。 3 向产品和领导们宣讲你的技术方案，在间歇的时间里作一些技术产品的甜头，或者噱头，给产品和老大看到技术改革所带来的红利，那么推动会更容易 4 不要贪大，不要激进。从每一个可控的可优化的细节部分开始，尤为是本身还不是某方面大牛的时候。

分业务线，不作救火人员

曾经私下和前端网的情封以及不少tl私聊过，其实大多数人都是建议前端分业务线的。而后具体的方案多是：某个业务线固定的交固定人负责，让其整理其模块并不断地优化，中间哪怕业务忙了或者松了也是这我的负责。

那么这样作优点是很明显的，可让人对业务，对这部分业务使用的技术栈很是清楚，也给足了他足够的机会和时间成为业务线的负责人而不只仅是前端负责人。

可能的缺点就是：可能会致使他对其余业务不熟悉，对其余技术栈不熟悉。弥补的方案就是按期进行业务轮岗，技术轮岗，这个期限多是半年或者一年。还有一个缺点就是可能会存在某个业务线真的临时很忙，这时容许抽调人员，但不容许变动业务负责人；若是某个业务线长期业务紧，建议招人。

方法论 ： 1 分业务线，分模块处理业务，不要哪里有活干哪里，也不要什么活都接 2 进行按期的业务和技术轮岗，进行业务和技术更综合的成长 3 对成员的管理、业务熟悉更加把握的细致，让他们成为技术的主人、业务的管理者。

技术栈的推动

假设大家公司已经开始说要推动技术栈了，但大部分项目都是原始项目，而后有人学了一个月vue，以为很好用就说为啥不用vue呢，这个好用，那里好用。还有的人学了下es6的语法，就开始鼓励整个公司所有用es6语法去项目里写代码。而后遭到了技术总监的拒绝或者项目中遇到了滑铁卢。

对于公司来说，大多数时候，其实并无到技术必须重构了才能业务作下去的场景的。前端大热的场景下，随便一个前端在本身的公司里发现如今前端大热的技术怎么公司都不用的，而后就有点郁闷，开始公司里推，或者本身悄悄的写两行爽一下。今天scott老师也讲到了，推技术栈不是简单的一点。react就要把react全家桶以及其一系列的技术点、流程、可能带来的问题，其技术方案彻底准备好，没准备好就最好不要开始。我最初也是这样建议的，用vue-cli写一个demo谁都会，但若是谁都会而后就开始写代码了，引进vue了，就开始的太随便啦。和你们当初用jq同样，也许不少人都不知道requirejs或者seajs这种东西，人家那时候就在按模块加载了，而当初你们谁都不知道还能够这样操做。因此问题不在于你知道了，而在于你理解的有多深，你能用好么，你有架构师的深度和解决一系列工程化、业务化的能力没有。

方法论 ： 1 推技术栈不是官方出个框架，你开始复制粘贴这部分api这样，须要进行技术预研，技术可行分析，其完整的生态，对团队的要求种种苛刻的条件的 2 推技术栈也能够以大化小，先推某个技术点，某个本来框架的痛点能够用新框架的某个特性解决。 3 推技术栈能够渐进的，不用一次到位，先针对一个简单场景找出其对应的方案是什么，进行实践验证成功以后再进行下一步。 4 保障足够的学习与技术基础，不是只是本身兴趣或者本身不满意公司的现状 5 有足够的沟通能力、团队协商能力、能针对每一个具体状况分析清本身切实须要的可行方案，以及对应的其余职能部门须要怎么配合你，流程是什么

人的成长是最不可忽略的一环

你们作业务都没问题的啊，工资也没少给，但仍是有大波的人由于公司没有用jq，由于公司vue用的很差，由于本身以为项目不规范就离职了。对于技术来说，业务的堆砌对于他们来说是不敏感的，本身敏感和感兴趣的是本身能写什么苦逼的代码，本身能力上升了。因此由此带出，不管你想让成员作什么业务，保证必定的人的成长是很是关键的。

方法论： 1 按期的技术能力以及软能力的沟通，考核，指导 2 提供成长的土壤、资源 3 提供其在能力成长的时候能够获得项目的历练，职位以及薪资的提升 4 我的职业规划，人生规划，我的建议的长期关注 5 帮助员工落实她认为能够改善的事情，你或者公司能帮他作的，帮助员工落实你想让他作的事情 6 为员工找到进步的节奏，依据，让他感觉到本身在切实的成长，公司也感觉并感激他的付出