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 为员工找到进步的节奏，依据，让他感受到自己在切实的成长，公司也感受并感激他的付出