Posts

当我起笔写总结的第一感受就是 2021 在写作这件事儿上，我变懒了，对外输出才 8 篇文章。 我翻了下前几年的年度终结，每年好像都觉得自己输出不够多，所以打心底里还是很想把写作这个事情做好的，但是由于自己思维的懒惰，总是没有落实下去。 工作 最近几年自己把工作的地位还是放得很高的，特别是来了蚂蚁之后，一个是因为工作任务比较重，暂用比较多的时间；二是因为在现在的财富积累上绝大部分来自于这份工作。 今年对我而言工作状态终于从忙碌回归到了正常，从来蚂蚁到 2021 年上半年，我基本上都处于一个满负荷的状态，工作日的时间百分之 90 的精力在工作上，准确的说是在业务上。 这种满负荷(业务压力)让我没跟太多的时间去思考自己如何成长、业务应该怎么去发展等，所以之前多次跟女朋友说想换一份工作，干着太累，自己也没太多成长。 后面由于业务调整加上自己终于在公司内找到一个技术发力点，所以心态回到正常，业务压力也从忙碌到正常，现在的状态还是比较满意。 另外有点就是渐渐的对业务价值这个词有了更深的感触，对我们老板说的一句话印象比较深刻： 公司招我们来不是让我们成长的，而是给公司创造业务价值的，所以你在公司不管造多牛逼的轮子，一定是要为业务服务的。所以最好的情况就是我们基于业务造的轮子，即给业务带来了帮助，也让自己技术得到了成长，双赢，这当然也是公司希望的。 所以作为技术人员一定要去了解业务，然后才知道我们的业务怎么赚钱的，或者他们怎么帮公司赚钱的，这样我们才能更有机会创造业务价值。 开源 一、开源最重要的是维护。 我很开心自己在蚂蚁体验技术部这个部门，这个部门应该是国内开源氛围最好的部门之一。组内也有多个非常优秀的开源项目，今年自己有幸参与了一点点 ahooks 和 antd mobile 。 让我开心的不是提了多少个 PR，而是了解了维护一个开源项目有多么的难，参与其中之后了解了开源项目的维护过程，了解了其中的艰辛，很多从公司开源出去的项目真的是纯靠爱发电，并不会纳入个人 KPI 里。 另外一个老板说过一句话：前端的绝大部分的技术项目，打的是维护，并没有太多的技术壁垒。 真的，这认识，太到位了，做开源最重要的持续不断的维护，而不是某个 KPI 项目。有部分阿里开源的东西，可能后期不怎么维护了，所以现在很多一看到阿里开源的，担心的这是不是 KPI 项目，会一直维护吗？可见一直维护才是最重要的一环。 二、尽量的去参与开源。 想起以前上大学的时候，一直在用 antd，从未想过能有机会给流行的开源项目提 PR，但是现在感觉提 PR 跟平时写代码一样了。 我觉得主要是两个原因： 一个是自己身边有很多这样的机会，身边同事都搞开源，想加入进去会变得很容易。 二是因为自己工作多年了，水平比以前高不少，代码也能看懂，自己写的代码也还行，能顺利的参与进去。 所以如果现在想参与开源项目，但是觉得自己还没有能力的，不要着急，打磨一下，让自己稍微厉害一点了来，另外就是要多找机会，看到你想参与的开源项目，有 issue 你可以解决的，你可以主动去提 PR，如果没有被合进去也没关系，一般作者是会给你建议的，这也是你提升的机会。 三、开源其实没那么难。 以前总觉得要去创造一个开源项目，想着要去做一个技术难度很高的开源项目，但是一直想不到，就觉得开源太难了。 今年在了解很多开源项目，以及开源项目背后的发展过程之后，其实自己以前的思路不太多，总想着要去做创新，做很牛逼的东西，做出来直接提效翻倍啥的。 如果没有这样的能力或者机会，我建议如果想做开源可以从集合类的库开始做，或者说一些最佳实践，demo、模板等。 什么叫集合类的库，我举几个例子就明白了。 ahooks（多个常用的自定义 hooks 集合）、antd（中后台组件集合）、lodash（工具函数集合）等等，这种项目你看，每一个集合里的元素都不是很难，写一个 hook、写一个组件、写一个函数有啥难的嘛，平时写项目公用组件，或者 common 文件夹里不也有么。**难的是要多、好用、长期维护。**可能你一个元素使用的人不多，但是当你的集合越来越多，就会跟越来越多人的需求匹配之后，就有用了。 最佳实践，demo 、模板类是什么样的呢？这种项目用户更多的可能是新手、或者小公司，刚接触某个技术栈的时候不知道怎么上手，不知道怎么写一个项目，不知道怎么写好一个项目，你就可以写一份 demo、或者最佳实践，让别人参考，或者快速搭建自己的项目。 这种项目比如：antd pro，你是不是也可以去写一个 antd mobile pro？或者 element pro ？或者 xx pro。类似的最佳实践还有很多很多，自己可以发散一下。...

你有没有花一个下午的时间浏览过 Mozilla 文档？如果你有，你会很清楚网上有很多关于 JavaScript 的信息。这使得人们很容易忽略一些不同寻常的 JavaScript 操作符。 然而，仅仅因为这些操作符不常见并不意味着它们不强大！它们在语法上看起来都很相似，但是当它们以不同的方式工作时，请务必阅读它们。 让我们开始吧！ 译者注：nullish 代表 null 或者 undefined 1. ?? 操作符 在 JavaScript 中，?? 操作符被称为nullish 合并操作符。如果第一个参数不是 null/undefined，这个运算符将返回第一个参数，否则，它将返回第二个参数。让我们看一个例子。 null ?? 5 // => 5 3 ?? 5 // => 3 当为一个变量分配默认值时，JavaScript 开发人员传统上依赖于逻辑 OR 操作符，如下所示。 var prevMoney = 1 var currMoney = 0 var noAccount = null var futureMoney = -1 function moneyAmount(money) { return money || `You currently do not own an account in the bank` } console....

自从我发过几篇关于面试经历的文章，由于我面试结果还不错，所有很多人来询问我一些面试相关的问题， 我这里给到 5 点建议，希望对大家有帮助。 1. 简历里应该惜字如金 简历简历，可以分为简和历。简，简单简洁之意，历，经历，总体就是简单的表达自己的经历。 我看到一些人的简历写了四、五页，甚至十来页的都有，每个项目把细节都写出来了，甚至还把项目截图给贴在了简历里面，生怕面试官不能理解需求，我建议最多不超过 2 页，亮点能写两页就已经很牛逼了。 我相信有很多人工作了很多年，经历的项目很多，其实不需要把所有的项目都列出来，简历里是要展示自己的亮点，牛逼的点，这个亮点、牛逼的点事相对的，相对于自己所做的东西里面的，不是客观的牛逼(如果有当然更好，那必然也是你相对的里面的亮点，不冲突)。 这句话意味着两层意思： 很多人觉得自己的项目没有亮点的问题，因为你是那这别人更高的标准来衡量自己，所以你相对于别人没有亮点，这样你就写不出一份简历。 多个亮点类似的项目合并，或者只写一个，因为都是为了给面试官展示这一个亮点，写多了就是浪费空间，简历上面的字很珍贵。 第一层让你的简历有东西可写(增加)，第二层是让你把简历写得更优质(减少)。 2. 简历应该是你设计过的 「设计简历」可能对这个词有点迷惑，可能你第一感觉是设计得好看一点，其实我想表达的设计是一种「圈套」，给面试设计的「圈套」，下面我会举例子让你明白这个「圈套」是什么。 我举两个点：技术要点和项目经历。 技术要点(就是自己会哪些技术)和项目经历相信是简历里面必不可少的内容，但是也许你可能忽略了哪些应该写。 之前我给别人看简历的时候，我就会问他们写的技术点三个问题 你对这个技术点的掌握程度是什么样的？ 你对这个技术点准备了哪些问题？ 当问到了相关技术点的时候，你能回答到哪个层次？仅仅了解、用过一两次、熟练使用、还是掌握原理。。。 当你能清楚的回答完这三个问题之后，你对你自己的水平就有了一定的认识，同时你对自己是否符合这个岗位有了一定的判断。我的目的就是让你了解自己的水平，然后才能针对性的去复习，查漏补缺，自己心里要有一杆秤，自己把这个知识点掌握到这个程度，能不能胜任这个岗位。 当你了解了之后，然后根据你自己是否有充足的复习时间，你就可以去设计你的技术要点部分了，只写你准备好了的技术点，这个准备好了不是说掌握得很深才叫准备好了，就算是只能回答几个简单的问题也算是准备好了，就是你想准备，然后自己也去复习了的，这就叫准备好了，这样你在面试的时候才会胸有成竹。 这就是在套路面试官问你准备好的问题，因为技术官基本只会问你简历里面提到的技术点，所以自己要对自己简历里面的技术点有充足的准备(把一些常见的面试题刷一些也是非常有帮助的)。 第二点设计就是对于项目经历部分。项目经历这部分没有人比你更熟悉，所以如果问到项目经历应该是你的地盘，是你给面试官展示你的项目有多牛逼，你在里面发挥了多大的价值，带来了多大的成果，你要非常自信的去给他讲解。 你的自信来源于什么？你非常了解这个项目的需求(为什么要做这个项目)、项目价值(做了之后怎么样了)，以及整个项目的技术方案，架构体系(怎么做的)，最重要的是你负责的或者参与的。 同时，你再把你在项目中遇到的一些**难点，和解决方案总结下来，**那么项目这块就是你的主战场了。 划重点：上面我所说的，最好最好是要准备，也就是说最好你要写下来，然后可以没事儿自己问自己上面的这些问题，然后自己去回答。 你可能会说，哇，那要准备好多东西哦，所以说啊，项目不用写太多，就把觉得自己最牛逼的、最熟悉的两、三个项目总结下来就够了，在项目这块比的不是数量，而是质量。 ** 项目经历这块在面试的时候面试官会问你一些问题，比如一些其他的解决方案，如果当时想到了，或者面完了想到了，记得补充进去。 3. 选常用的东西去准备 前端的技能要求很多，就算解决同一个问题的解决方案也会有很多个，比如解决视图的，就有 React、Vue，构建的就有 Webpack、Rollup、Parcel ，React 状态管理也有 Redux、Mbox、unstate 等。 如果你的脑袋里面都装着这些东西，那么你肯定是复习不完的了，我的建议是把你项目用常用的东西好好准备，尽量不要让面试官把你常用的东西还问倒了，如果你平时用的东西你都没有掌握得好，你觉得面试官会觉得你平时不用的东西掌握好了吗？ 4. 准备一份自我介绍 准备一份自我介绍，不是简简单单的准备，而是自己要写下来，然后对着稿子练习一下。可能你会觉得很麻烦，有必要吗？我说两点： 自我介绍是每个面试官，每场面试都会问的，没有哪个面试题有如此高的频率，100% 中的面试题不值得去好好准备吗？ 上面我说了简历是去套路面试官问哪些东西？而自我介绍就是去套路面试官怎么去问的一个很好的方式，因为往往面试官会在你自我介绍之后，会问几个你自我介绍里面所包含的东西，自我介绍的结尾，也许就是面试题的开始。 这个一个很好的引导面试官怎么问的方式。 5. 职业规划 职业规划这个，其实也是一个高频面试题，不管是面试官还是 HR，都喜欢问的一个问题，这个题没有标准答案，我说一下我的一些看法。 职业规划我觉得可以从三个方面去谈： 我想做什么？(兴趣、价值观等方面) 我能做什么？(你的知识、技术、经历等方面来支持) 环境支持我做什么(意味着未来)？(外部环境，公司、团队) 大致你可以像这样去回答，我的兴趣是 XXX，优势是 XXX，因此我选择了前端，这是一个可以将我的兴趣和工作结合起来的行业，是我非常喜欢的，所以我会很用心对待这个工作。我之前做过 XX，有了 XX 的经验，然后觉得很有意思，想继续深挖(当然你也可以说，我之前一直在做 XXX，以后想换一种 XXX 技术)。近期我打算研究 XXX，后续可以在 XXX 上独当一面，独立负责 XXXX 事务,解决 XXXX 问题。谈到远期规划，我会根据环境的变化，工作内容的变化，以及我自身能力的变化，不断进行调整的。...

demo演示 多边形图 ...

也许，你会遇到这样的情况，UI给你一张图片，然而根据实际情况，比如需要适配XXX手机，或者需要把图片形状搞好看一点，会让前端人员进行图片剪裁工作。 ...