博文（玖五）
博文（玖五）
2020年终总结
# 2020年终总结 2020年就这样结束了，与往年不一样，今年时间没有往年那么快。2020年是不平凡的一年，对这个世界，对我自己，都是如此。 ## 2020年度大事回顾 * 2020.2月 从360离职加入Alibaba淘系技术部，25岁P7小目标达成，正式结束北漂生涯 * 2020.3月 踏上去往杭州的高铁，开启新的工作与生活、 * 2020.5 试用期转正 * 2020.6月 获奖（618大促奖励优秀PM的一个荣誉），奖状在淘宝办公楼里挂了三四个月 * 2020.8 ~ 2020.11 首次参与双11，帮大家剁手 * 2020.11 去了趟云南玩 #### 结束北漂 > The End...
# 小程序底层实现原理及一些思考（2） > 写在前面的话，最近频繁出现有人盗版我的原创文章、盗版我出版的书、抄袭我的文章、根据我的文章又写了一篇新的文章然后说是自己的研究成果、根据我的文章写了一个开源项目然后说是自己原创、根据我出版的书二次改写并开源到Github获得好几千Star等情况。 > > 我愿意写硬核知识分享给大家是给大家学习与成长用的，也仅限于学习与学术交流使用。 > > 我不希望我的文章以任何形式被转载、被二次改写、被盗版、被抄袭、或者根据我的文章开发了一个小程序框架开源出去骗star等侵占我版权的行为，一经发现必追究责任。 > > 如果无法控制盗版行为，我将考虑关闭博客，开启白名单模式，只有白名单内的人可以阅读我的文章。为了帮助更多的人学习与进步，请大家拒绝盗版！ 去年九月份写了篇文章 [《小程序底层实现原理及一些思考》](https://github.com/berwin/Blog/issues/43)，讲述了我实现（探索）小程序的过程及一些思考，并揭露了一个事实：**小程序是基于Web技术实现的**。 兜兜转转尝试了很多方案，但不同的方案均存在一些问题，我试图找到完美的解决方案，功夫不负有心人，最终找到了。 在前文的最后，我提到最终还是要回到双线程，双线程才是正确的方向，现在经过验证这个方向非常正确。 但如何基于双线程实现小程序前文只是略微提及，因为当时也只是一个初步的设想，并没有实现出来。 ## 为什么是双线程 当反复尝试了很多方案后，我开始重新思考，到底什么是小程序。 思考后得到的结论是，站在产品角度思考技术，小程序有两个特点： 1. 免安装 2. 具备通过宿主APP访问OS的能力 > 小程序的定义和特点有很多，但我认为最根本的特点是以上两点 站在技术角度思考，小程序至少要保证四点：**安全**、**稳定**、**性能**、**简单**。 *...
# 嗨，送你一张Web性能优化地图 我们都知道对于Web应用来说性能很重要。然而性能优化相关的知识却非常的庞大并且杂乱。对于性能优化需要做些什么以及性能瓶颈是什么，通常我们并不清楚。 > 不包括那些对性能优化有丰富经验的高手 事实上关于Web性能有很多可以优化的点，其中涉及到的知识大致可以划分为几类：**度量标准**、**编码优化**、**静态资源优化**、**交付优化**、**构建优化**、**性能监控**。 图1. 性能优化分类 本文主要介绍性能优化需要做的事以及需要考虑的问题。目的在于给读者脑海中生成一个宏观的地图。 不会介绍每个优化项目具体如何操作。PS：后续会有系列文章针对不同优化分类下的具体优化操作进行更详细的介绍。 ## 1. 度量标准与设定目标 在进行性能优化之前，我们需要为应用选择一个正确的度量标准（性能指标）以及设定一个合理的优化目标。 > 并不是所有指标都同样重要，这取决于你的应用。最后根据度量标准设定一个现实的目标。 ### 1.1 度量标准 下面是一些值得考虑的指标： * 首次有效绘制（First Meaningful Paint，简称FMP，当主要内容呈现在页面上） * 英雄渲染时间（Hero Rendering Times，度量用户体验的新指标，当用户最关心的内容渲染完成） * 可交互时间（Time...
# 前端工程师如何在业余时间提升自己？ 其实提升自己没有秘籍和诀窍，只要愿意花业余时间去学习，再加上长时间的坚持，就可以成为大神。 ## 读书 我个人比较喜欢读书，喜欢读纸质的书，记得刚开始工作的时候，很多东西都不会，只会写CSS切页面，是一名真切图仔，同时自己又特别想成为大神，然后就每天中午吃完饭在工位上看一个小时的书，下班后也会留在公司看两个小时的书再回家，就这样每天中午和晚上一边看书一边写Demo，前期的提升速度还是非常明显的，基本上每天都能感觉到自己学会了新知识。 我比较推荐多读一些技术书，特别是纸质书，熟悉我的同学都知道我有非常多的书。一本书从填选题表到最终出版，中间会经历很多步骤，出版社专业的编辑也会和作者一起反复的校验和修改好多遍，上市之后再经过读者的认可，这样一本书的内容质量是非常有保障的。根据经验图灵出版的书质量都非常高。 ## 学习资料 学习资料非常重要，要阅读高质量的第一手资料，很多时候我们学习某个技术发现怎么都学不会搞不懂时可能不一定是我们笨，也有可能是学习资料有问题。 我见过很多文章讲某个技术，即使那个技术我事先已经会了，也确实看不懂文章里在说些什么。我也见过很多文章可能作者自己也不是很懂某个技术，他只是把一些其他文章拼凑起来。 不好的学习资料通常内容晦涩难懂且没有把技术讲清楚，而高质量的学习资料通常会很清晰且精准地把一个技术讲透，因为讲解清晰明确，所以学习起来也不会太复杂枯燥。 JS框架、库、工具等，我一般会从官网和口碑较好的纸质书籍中学习。基础知识我一般通过阅读高质量的纸质书籍 + 阅读W3C的规范来学习。Web性能领域我通常在Chrome开发者官网和web.dev里的文章来学习。 具备了一定的基础知识后就可以判断出学习资料的质量，这时候就可以关注一些公众号或者明星程序员来获取一些知识。 ## 写作与分享 除了学习，我还会利用业余时间写文章，做技术分享等，将自己学到的知识分享出去。切身体会，将自己学到的知识分享出去对自己的成长有很大帮助，有时候写文章的过程中会发现自己对某个知识也没有真的学透。 而且写作和分享可以让自己学会思考并锻炼思考能力，而思考能力其实很重要。 ## 坚持 最后，坚持才是最重要的，我们的职业生涯，其实是一场没有终点的长跑比赛，很多人可能想问怎样才能跑得更快，把这场比赛跑赢。其实在这条没有终点的赛道上在短期内快一些没有任何意义。大部分人跑到中途就主动放弃了，这就是为什么大牛那么少。唯一能决定这场比赛输赢的，只有两个字叫 **“坚持”**。在这条赛道上跑赢的，不是那些跑得快的人，而是为数不多坚持跑的人。他们能跑赢，只是因为他们还在跑。 ## 书单推荐 最后推荐一些书单，全都是我自己看过的觉得非常不错的书。 **JavaScript相关的书籍**：《你不知道的JavaScript》上中下共三本、《深入理解ES6》、《JavaScript高级程序设计》 **CSS相关的书**我都没有亲自看过，但我是看张鑫旭博客学的CSS，他出版的书我虽然没看，但凭着对作者的信任，而且作者还专门为这本书做了个[官网](https://www.cssworld.cn/)感觉还是蛮用心的，质量应该是可以保障的：《CSS世界》。 **JS框架相关的书籍**，React相关我没有看过不做推荐，Vue相关的推荐一本：《深入浅出Vue.js》（真不是打广告，内容质量和深度确实是目前市面上最好的一本）。...
# 需求分析与开发时间评估 今天想谈一谈关于“需求分析”和“开发时间”这两个话题，工作这么些年还是头一次公然讨论这个话题，今天聊一下我对这两个话题的浅见。 ## 需求分析 早些年在我刚开始工作时，我认为“需求分析”就是听一听产品经理提的需求，评估下开发可行性和难度，把实现不了的需求砍掉。 这么多年过去了，我发现这是最Low Level的需求分析。 原因在于当时的我完全不知道产品经理为什么要提出这个需求，我甚至压根没有关注过这个问题，当时的我只关注这个需求如何实现，难度如何。所以我很难理解产品经理，甚至经常站在技术的角度认为产品经理提出的这个需求好SB啊，他是智障吗？ 但其实产品经理和工程师不应该是敌对关系，**应该是“搭档”**，现在我和我们的产品经理一直是搭档关系，我们的关系很融洽，因为我们的目标是一致的：让我们的产品，满足用户的需求。 但有时候产品经理提出的需求可能不是很正确，这个时候需要工程师进行辅助。这里面有很多原因： 1. 产品经理可能对技术的边界不是很了解，所以无法充分利用技术解决用户需求 2. 对用户原始需求的理解是很难传递的 3. 产品经理对用户需求的理解有误 4. 其他 我们先讨论第一点：**“产品经理可能对技术的边界不是很了解”**。 ### 产品经理可能对技术的边界不是很了解 优秀的产品经理是需要有技术广度的，他**不一定要深入了解技术的原理，但一定要理解技术的边界**。某个技术能做什么，不能做什么，最近是不是又有新技术了，和我的产品有关系吗？ 但通常大多数产品经理都比较缺乏技术广度，所以这个时候需要工程师去补位。 但工程师去补位有一个前提，那就是工程师真的理解产品经理，理解他在想什么。这就要谈到第二点：**对用户原始需求的理解很难传递**。 ### 对用户原始需求的理解很难传递 很多时候，产品只是发了个产品文档过来，然后就拉着技术做“需求评审”，但其实这份需求文档，是产品经理对用户需求理解的二次加工。工程师在这份需求文档里是很难看清用户的原始需求的。 > 比如：用户需要一个消息提醒。产品经理可能是不知道有Web...
# 2018你应该知道的Web性能信息采集指南  假设您正在访问一个网站，如果Web内容不在几秒内显示在屏幕上，那么作为用户您可能会选择关闭标签页，转去浏览其他页面从而代替这个网页的内容。但是作为Web开发者，您可能希望跟踪**请求**与**导航**的详细信息，这样你就可以知道为什么这个网页的速度在变慢。 W3C性能工作组提供了可以用来测量和改进Web应用性能的用户代理（User Agent）特性与API。开发者可以使用这些API来收集精确的性能信息，从不同方面找出Web应用的性能瓶颈并提高应用的性能。 > 这些特性和API适用于桌面、移动浏览器以及其他非浏览器环境。 > 由于这些特性与API不止适用于浏览器，还适用于非浏览器环境，所以本文会大量使用“用户代理”这个词来代替“浏览器” ## 1. 如何获得高精度的时间？ ECMA-262 规范中定义了 `Date` 对象来表示自 1970 年 1 月 1 日以来的毫秒数。它足以满足大部分需求，但缺点是时间会受到时钟偏差与系统时钟调整的影响。时间的值不总是单调递增，后续值有可能会减少或者保持不变。 例如，下面这段代码计算出来的“`duration`”有可能被记录为正数、负数或零。 ```javascript const mark_start = Date.now() doTask()...
深入浅出 Koa2 原理
# 深入浅出 Koa2 说在前面的话：本文针对对koa1非常了解并学习过源码或者阅读过我[上篇koa文章](https://github.com/berwin/Blog/issues/8)的同学阅读~ 吸取之前的经验，本章用幽默的风格来分析又臭又硬的原理，我尽量用最通俗易懂的语言来描述复杂的逻辑。 前几天koa发布了2.0版本。这几天找了个不忙的时间，赶紧阅读了2.0的文档和源码 这次改动主要是中间件的部分。其他部分对于使用者来说没什么改动。 阅读过我的[上一篇文章](https://github.com/berwin/Blog/issues/8)的同学应该知道。koa内部主要有两个知识点，context（上下文）和middleware（中间件）两个部分 所以总体来看，改动不算太大，我先把改动分个类 - 使用 - 中间件 - 源码 - 语法 - 中间件 ## 使用上的改动 先说使用方面，这次改动让中间件部分可以使用ES2015-2016的语法~ 比如async await，在比如箭头函数 正因为中间件支持了async 和await，所以内部的中间件逻辑就不得不做一些改动。 但是koa的作者还是做了兼容的。同时支持3种不同种类的中间件，`普通函数`，`async 函数`，`Generator函数`。（这个屌） 普通函数的用法 ```...
# 成长 & 经历 - 走在独特的路上，遇见自己的风景 有很多人好奇我是如何成长的，之前有一些朋友也曾试图邀请我写一篇自己的成长史，不过却被我婉言谢绝了。原因无他，因为我并没有觉得自己有资格写这个东西。我并不觉得自己很厉害，哪能有资格教导大家如何成为厉害的人？ 不过既然大家这么好奇我是如何成长的，那我就把自己的经历拿出来分享一下。 ## 善于做决策 像我这种没有学历，也没有光鲜的背景的人，在踏入前端这个行业时，起点非常低。我在北京的第一份工作，工资低到只有可怜的不足四千块钱。说实话，那时候我连JavaScript都不会写，只会一点点CSS能写个页面，是个非常典型的『切图仔』。 从这么低的起点走到今天，这中间是有什么秘籍么？还是偶然现象？是因为我比其他人聪明？还是我比其他人更努力？ 其实都不是，我不认为自己比其他人聪明，也不觉得自己比其他人更努力（比我更努力的人多了去了）。我自认为我能走到今天，更大的因素可能是因为我比较善于做 **『决策』**。 > 这里说的 **“决策”** 分两种情况，一种是“选择”，一种是“规划”。 现在回想起来，我的每一次转折点，背后都是我“选择”了当时我所面临的实际情况的 **『最优选择』**，以及在我能接触到的信息中做出对未来的 **『最优规划』**。 > 最优规划的意思是：根据自己了解到的信息，规划出一条对自己最有利的路线。 做选择还稍微容易一点，毕竟选项通常是有限的，但做规划就多少有点运气的成分在里面了。做规划有无限种可能性和无限种选择，我在做规划时，其实也很迷茫，不知道自己的选择是对是错，一般就尽人事听天命了。 从那么低的起点走到今天，这一路上有太多的诱惑，每一次“选择”都会对未来的职业生涯产生不同程度的影响。例如：每一次跳槽如何选择offer、是否要接外包赚点外快、在有限的时间里如何做技术投资、规划未来的职业路线等。 ## 亲身经历 我的第一次重大决策是在我刚出来工作的时候，当时的我17周岁，在沈阳一家互联网外包公司当学徒（学徒是没有工资的），在公司里学怎么切图。而同一时间我的同学们有当客服的，有干销售的，干什么的都有，他们工资都远高于我，那个时候同学们都刚出来工作，互相之间的攀比还是挺严重的，当时的我都不好意思跟同学们说我赚多少钱，当时的我接触到的信息也不多，完全不知道互联网行业是否有前途，当时心里想的就是，不管怎么说我也是在做技术吧，至少比销售，客服之类的随着时间的推移完全没有让自身有任何沉淀的行业好一点，没准哪天我的工资就和你们一样多了。就这样，**我第一次重大决策就是坚持做技术**。 > 当时的我虽然心里想的很简单，但潜意识里我自己都没有发现，我更倾向于为自己投资。简单来说，我更看重长期利益，而不是短期利益。哪怕会受尽同学的白眼与瞧不起。...
# Largest Contentful Paint (LCP) LCP 全称 “Largest Contentful Paint”，翻译为“最大内容绘制”，用于监控网页可视区内“绘制面积”最大的元素开始呈现在屏幕上的时间点。 ## 1. 介绍 度量网页 **“主要内容”** 何时呈现在用户眼里是一项非常具有挑战的事情。 历史上一直如此，最早期使用 `load` 与 `DOMContentLoaded`，但它俩无法度量内容何时渲染，“主要内容”何时呈现在用户眼里更无法度量，特别是单页应用流行起来之后，这两个度量标准更无参考价值。 后面使用 `First Paint` 与 `First Contentful Paint`，但它俩更多的是专注于“初始渲染”，不会考虑绘制内容的重要性。如果页面一开始显示一个小菊花（Loading Indicator），此时此刻这个被捕获的时间点所呈现给用户的内容并不是有价值的主要内容。 使用比较高级的 `First...
时间好快，眨眼间，加入阿里已经一年了。这一年发生了很多事，整体上非常地充实且精彩，在一件又一件事情中，我不停地犯错，一路走来，步履蹒跚，也收获到了很多成长。每次结束一件事后，经过短暂宁静的生活便再次踏上新的征程。 之前写过一篇[《我在阿里半年收获的成长》](https://github.com/berwin/Blog/issues/50)，因此文本主要讲述“后半年”收获的成长。 ## 1. 关于“思考” > * Mentor：你平时周末都做些什么？ > * 我：没事的时候通常会看看书，写写代码，研究一些自己感兴趣的东西 > * Mentor：可以把一些平时做事的时间换成什么都不做，坐在那“思考”，想一些东西 以上对话来自一次我向导师询问的一个问题：“我应该如何再进一步，7和8的区别是什么”（大致是这个问题，原问题记不清了😿）。 7和8之间就级别本身的区别优势是 **“可以调动更多资源”**。之所以需要调动更多资源是因为需要做更复杂的事。复杂的事哪来？ **“思考得来”**，当然也可以靠主管分配，但谁又能保证主管一定会把那个机遇分配给自己。 完全靠主管分配机遇，这也违背我内心一直以来所坚定的信念： **“让事情因为自己而与众不同”**。今天能通过面试进入到阿里巴巴的同学，能力都不差，主管把机遇分配给另一个人绝大概率拿到的结果不会比我差多少，一件事情究竟是因为我去做才拿到好结果，还是大家去做都能拿到好结果，不太好说，这达不到 **“让事情因为自己而与众不同”** 的标准。 只有自己凭空创造出的机遇并最终拿到了结果，才符合 **“让事情因为自己而与众不同”**，也更能展现出自己的水平。 所以一个更可靠的发展路径是： 1. 多思考项目未来的发展方向和现有技术体系的问题 2. 做判断并按照正确的方向执行 3....