总结

前言 2020 年真的是不平凡的一年， 疫情夺走了很多人的生命，还夺走了我的工作(公司因为疫情被迫裁员)，所以今年换了工作来到了蚂蚁，在蚂蚁的工作经历跟之前在蘑菇街完全不一样。。。 工作 来蚂蚁这半年我觉得在工作上的成长比我之前在蘑菇街一年半的成长都还多，经历比较丰富。 阿里一直都有拥抱变化的文化，我来大概五个月的时候就换了三个主管，经历了好几次的组织架构变动，我刚进来的时候同组的同事（之前组内大概 12 人）到现在还跟我一组的仅剩一名。 不过随着每一次的变动，我的分工也越来越清晰，从最开始哪里缺人就去哪里，再到负责一块模糊的业务线，再到一个人带着 3 个合作伙伴负责一整个业务线，再到现在有了 3 个正式加 6 个合作伙伴的阵型。 作为整个业务线的 owner 不仅要接需求还要去预测业务未来的走向，这样才能在技术上做好提前的准备，当业务真的来了，才能快速的支持。这个是我在试用期答辩的时候面试官给到我的期望，这个我在之前试用期结束后有写过。 原来我是个业务性选手？？？？ 只不过那个时候我只是觉得这个话说得很对，并没有体感，但是当我在负责整块业务的，以及带着一群人在做的期间，作为业务 owner 必须得去思考这些了，因为我们这里业务发展得很快，虽然我们业务团队成员变多了，但是需求也越来越多，所以如果不提前去做一些业务上的预测，技术上的沉淀，当业务发展再快点，需求再多一些我们目前的这些人就消化得很吃力，甚至吃不下，这是我今年非常大的一个收获。 对于这个收获其实我之前想过我为什么可以得到，我刚开始把原因归结到了运气，因为我能有机会负责一条业务线的东西是由于我的师兄以及其他大部分同事都走了，现有的业务只能由留下来的人去承担，所以我当时想到了那些得到晋升或者 375 的同学是不是运气好，可以做到好的业务或者技术。但是又细想如果机会给你了，如果没有把它当机会，而且他这块重重的东西当做负担，或者平常心看待，可能也做不出什么优秀的成果。 但是一件平凡的事情如果交给一个优秀的人去做，大概率还是会做出优秀的东西。 所以最后我得出的结论是运气可以让一个准备好了，有实力的人加速成功，但不会让一个平凡的人获得成功。 学习与写作 当我在准备写总结的时候，我本以为今年读的书(去年 20 本)会比去年要少，没想到今年还略多一点，读完的都有 29 本了，但是我明显能感觉到今年花在读书上的时间变少了，特别是在入职蚂蚁之后，属于自己的时间更少了。 我想可能是渐渐的找到了读书的方法，越读越快了吧。 下面是我今年读书列表：豆瓣主页 在写作方面今年公开文章产量就很低了，只有 13 篇，基本都是上半年写的，下半年入职蚂蚁之后就基本没怎么写了，一方面是因为确实工作太忙了，另一方面需要在公司内部写不少的文档。 文章列表见博客：前端桃园 技术 很遗憾今年对技术没有做什么深的研究，主要是业务太忙，把我对技术的追求抹平了，整天就想着如何能把业务支持下去。 来蚂蚁半年没写过 React，大部分时间写钉钉小程序和支付宝小程序，另外还写了将近两个月的云凤蝶。 在我没怎么接触过小程序前，对小程序有刻板的印象，总觉得小程序限制太多，很简单，没有什么意思，当然也不知道其原理，所以对小程序比较抵触。 但是当我写了两三个月之后，对小程序了解得越来越多，但是另一方面发现自己对小程序了解得越来越少，为什么这么说呢？ 当我还没怎么接触小程序的时候可能想到的就只有 小程序的语法是什么样的，小程序是怎么运行的，但是写得越来越久，发现自己以前的视野太小了，整个小程序生态还有很多东西可以去研究，越写越发现自己不会的越来越多，这些不知道反而让我对小程序产生了兴趣，感觉可以有新的东西值得去研究。 比如小程序他是怎么运行的，跟原生、H5 之前的区别在哪里，关联是什么，view 层是怎么渲染的，逻辑部分的 js 是怎么执行的，与客户端，容器是怎么通信，怎么打包的，怎么编译的，编译出来的东西又是什么，怎么发布上架的，以及什么情况下使用小程序技术栈、什么情况下使用 h5 技术栈，等等等，这些没有搞明白的问题深深的让我对小程序产生了兴趣。 所以明年在技术上的一个目标就是深入小程序。 生活 家人 生活方面最令我开心的就是女朋友在 11 月份从上海辞职，来到了杭州，结束了 3 年的异地恋，每天下班后有个人在家里等的感觉真好！ 旅游 西安旅游 国庆去西安旅游了，在去西安之前我们还先去南京溧水参加了【咪豆音乐节】。这次是准备得最充分的一次，还做了一些攻略。 重庆 Outing 重庆三峡博物馆 江景：重庆洪崖洞夜景...

一个读者的困惑，我做了简单的解答，希望能对他有所帮助。 ## ##1. 如何把一个知识由浅入深的学习？ 见问题 2 ##2. 那些写技术文章的作者，为什么对某一知识或某一框架理解得那么深入，是如何学习的呢？ 我觉得有以下几点： 使用的多，踩得坑多，经验丰富。 花时间深入研究过原理。 思考过这个东西的价值以及为什么会出现(这个点很容易被忽略，我的那篇从历史的长河中聊虚拟 DOM 的意义就是这个点)。 思考过这个东西能给自己的业务带来什么帮助，然后紧密的结合到自己的项目中。 如果你觉得这几个点感觉你都懂，那我问你几个问题，比如你在你们公司想引入 React 来做项目。 问题一：你为什么要用 React？ 问题二：用 React 能带来什么好处？ 问题三：如果用 Vue 或者 JQuery 能行吗？ 问题四：React 适合哪些场景？哪些场景又不适用？ 问题五：你觉得 React 存在的意义是什么？ 问题六：React 有什么缺点？ 问题七：你觉得引入 React 会有什么成本，收益和成本如何进行平衡？ 我想表达的是在学习一个东西，或者说想深入一个知识，不仅仅知道它是什么，怎么用，还要去了解它为什么会产生，能带来什么价值，解决了什么问题。这样在你判断是否引入这门新技术才有充足的理由，否则就是追风，看到这个东西比较火，可能你根本就不需要，然后引入了反而给自己增加负担。 在你想知道它解决了什么问题的时候，可能就会思考为什么它能解决这个问题，然后再去寻找这个答案的时候就会深入他的原理，加上自己大量的实践，慢慢的就成为这个东西的专家了。 ##3. 什么时候去接触和怎么去学一些规范文档？ 我想你说的规范文档应该是官方文档这种吧，然后下面讨论的都是基于官方文档。 官方文档我一直是把它当做完善我知识体系的东西来看待的，而不是入门教程。毕竟官方文档是给所有人写的，不管你是没使用过的，还是使用过很长时间的，所以就导致大部分的内容都是比较官方的，所以就导致不一定适合你。所以才有了各种各样的教程，因为每个人的所拥有的知识不一样。 另外官方文档也不会告诉你哪个知识点重要，哪个知识点常用，它只会告诉你有这个东西，这些东西都是需要在实战中去得知。 特别是对于 CSS 标准，或者 Javascript 标准这种，不到万不得已是不会去看的，东西又多，又不适合新手阅读，但是在你看到网上有不同答案的时候，就非常适合去看标准，平时就看看书、看看博客、看看视频教程就行。 4. 如何处理网上的技术文章以及实体书？ 我觉得首先要明白文章和书的区别是什么，然后才能正确的去使用他们。 我们一般对书的认知是对知识成体系的介绍，书是比较的全，是对整个知识比较全面的介绍，另外由于写书比较的耗时，所以往往书里面的内容都是晚于知识点出来很久的，比较适合那种很久不会变的知识。 知道了书的特性，那么我们何时需要去读书呢？ 我觉得应该是在你想打造或者说完善你自己的知识体系的时候就一定要去读书，特别是像那种《xxx权威指南》这种，就特别的适合用来完善知识体系的。 但是一本书不可能把方方面面讲完，都是会有侧重点的，就拿学习 JavaScript 来说，想学好《JavaScript高级程序设计》又称红宝书、《JavaScript权威指南》又称犀牛书是不应该绕过的，那么这两本书又有什么区别呢，这两本书都很厚，理论上讲得都很全。 这两本书都会把 JavaScript 最重要的东西肯定都是会介绍的，但是红宝书侧重于程序设计，相对来说比较注重实战一点，所以对于原型、继承这种在程序设计方面较多的知识点会用大量的篇幅，然后举很多的例子，这样更利于我们的程序设计。 而对于犀牛书的话他的侧重点在于权威，那么他的侧重点就在于全，要比所有的 JavaScript 的书都介绍的更全，相对来说比较偏理论。 因为每本书都会有自己的特点，就是侧重点不同，所以在看实体书的时候就要看自己需求，如果想提高自己的程序设计能力，就看红宝书，如果想查漏补缺，看看自己是否对 JavaScript 全面了解，就看犀牛书。 其他的书也一样，对于技术书我一般的习惯都是带着目的去看，而不是像一些消费型的书随便翻。 再说说技术文章，技术文章他的特点就是可以做到很新，但是质量参差不齐，而且很容易传播错误的知识。...

又一年过去了，2018 年写年终总结的场景还历历在目，写这篇文章之前还专门去看了下 2018 年的年度总结，主要是看自己在 2018 学的东西自己还能记得啥。 印象最深刻的应该是还是函数式编程相关的东西，因为确实在我深入的去接触它过后，我的很多编程思维都被它所影响。虽然在项目中不会去用很多函数式的方式去写，但是函数式的那些特点深深的指导着我如何去设计一个更容易维护的函数，其中一些思维可以见我去年的写 函数式编程，真香。 做个预测：三年之内，函数式编程要火一波，原因是 serverless 的兴起。 回顾了过去，我对今年的整体总结是：输入很多、输出不够。 输入 自我感觉自己是一个焦虑的人，焦虑也许来源与社交(周围优秀的人太多，见了太多比自己年轻或者同龄人)、也许来源于自己见识更多(处于达克效应里面「知道自己不知道」的境界)。 图片来源于网络 如果按照这张图来的话，我现在处于自信崩溃区，不知道自己是否处于绝望之谷，但是希望明年能进入开悟之坡。 从这张图里可以看到，自信程度高也不一定约好，很可能是处于愚昧山峰。 自我感觉自己还算坚强，没有被焦虑或者自信崩溃打败，相信自己通过努力，提升自己的专业知识和能力，总会逃离绝望之谷，所以我今年比以前都更努力的去学习，得到结果是我感觉自己今年在见识上提升了非常的多，见识越多，意味着格局会慢慢变大，格局越大，就越能成功(这只是我自己的人生逻辑)。 虽然在精神上的收获了很多，但是从今年各方面的产出来看，不管是职业还是影响力都没有实质性的进展，但是我没有着急，平时安慰我自己的话就是：还没到爆发的时候，现在一直积累就行。 读书 读书是我今年最满意的一项输入，读了 20 多本书，虽然这个成绩不算好，但是对于我来说是一个非常大的进步，因为我从小就特别讨厌读文字，小说也不例外。现在一年能读 20 多本，差不多半个月读一本，进步非常的大了。 最开始想读书也是自己接触的很多大佬，或者在网上看到一些大佬的文章等，了解到读书非常的重要，所以就开始买书来读，刚开始读得很慢，而且很枯燥，一本书可能要花一个月才能读完，大概读了两个月后，自己养成了读书的习惯了，每天花 30 ~ 60 分钟的时间读书，周末就花多一点，一周就能读一本书。 那个时候成就感就来了，对读书产生了兴趣，然后读书 对于我来说就不算什么难事儿了，反正有大段的空闲时间就会用来读书。 在书的媒介方面我还是比较传统，喜欢纸质书翻书的感觉，所以我读的大部分书都是纸质书，基本每个月都会买 3、4 本书，主要是每个月基本上当当都会搞活动，打 5 折或者满 100 - 50，另外还有满 200 - 30 的券，然后由于我会每个月自费给公众号里的读者送书，正好就一起会买六七本书，差不多 200 块。 下面是我今年读完的书，没读完的没有列出来，明年再继续读，大部分都是纸质书。我目前读书还没有进行主题阅读，基本上都是泛读，涉及的不仅仅是技术书，也有心理学、品牌、历史、理财、个人成长各个方面。 电子书 《实用性阅读指南》三星 《麦肯锡精英高效阅读法》三星 《半小时漫画中国史》1-4 册 三星 《小狗钱钱》五星 《如何有效阅读一本书》三星 纸质书 《现代前端技术解析》四星 《你不知道的 JavaScript(上)》五星 《高效前端：Web 高效编程与优化实践》四星 《重构(第二版)》五星 《React 状态管理与同构实战》四星 《见识》四星 《被讨厌的勇气》五星 《刻意练习》四星 《高效能人士的七个习惯》五星 《超级符号原理》三星 《学会写作》三星 《少有人走的路 4：在焦虑的年代获得精神的成长》四星 《原则》五星 《语言学的邀请》五星 《文明之光(第一册)》五星 打五星的都是我自己读完之后感觉收获很多的，每个人可能感受不同，三星就是我觉得可读可不读的书。...

2018已经结束了，总结自己这一年来就是三个角色的转变：自己从一个学生成为了一个社会人，从一个读者变成了一个自媒体人，从一个在校学习者变成了终身学习者。 每一种角色的转变意味着责任的转变，每多一种角色，就会多承担一份责任。角色变得越大，责任也会承担得越大，当然收获得也更大。 技术成长 对于技术成长，我感觉我莫名其妙的就走在了前端的前沿，刚刚在知乎上看到一个帖子2019 前端技术规划该包含什么？很多大佬在规划里面都谈到 Rxjs、Typescript、函数式编程、Flutter、PWA、Node 相关, 然而事实就是这么巧(或者可以说我眼界比较远，偷笑)，在 2018 年我很多都已经接触过了，比如 Rxjs、TS、函数式编程、Node 等。 聊 Typescript(TS) 特别是对于 TS，我在公众号，然后我维护的微信群里早就已经说过，TS 最近会火起来的，没学的赶紧学起来，不知道有多少人听了我的，看了那么多大佬的规划，我更加的坚信了 TS 将会变成未来前端工程师一项必备的技能。 然后对于 TS 的学习，我看过这些东西，我推荐一下，不过对于 TS 我仍然是个初学者，不敢说有多精通，我只在我自己的小项目中用过，没有在公司的项目中使用。 TS 官方文档 技术胖的 ts 教程 TypeScript极速完全进阶指南 深入理解 TypeScript 如果问我使用 TS 感觉是什么样的，我只能说相逢恨晚，就跟 vim 一样，用过之后就像一直用。 聊 Rxjs 对于学 Rxjs 来说，我想说的是，Rxjs 是我学过最难学的一个库了，目前为止没有之一。现在回想起来，要是早点接触函数式编程就好了，如果先是研究函数式编程，再去学习 Rxjs，我相信会轻松 40% 以上。但是目前为止，我并没有拿到真正的生产环境去用过，只是写过一些简单的 demo，然后看过一些资料和书籍，同时也在团队做过相关的普及。 Rxjs 难的就是思维方式以及 api 很多，然后就是由于一些概念不知道为什么要这么设计(很多思想我相信学了函数式编程就会明白了)。 对于 rxjs 的学习看过很多的文章，我这里还是推荐三个我觉得比较全的学习资料。 Rxjs 官网 30 天精通 Rxjs 程墨老师的深入浅出 Rxjs 聊函数式编程 学习函数式编程给我最大的感受就是让我拓宽了我的眼界，突然的就弥补了以前知识体系缺的点。比如对于 compose、curry 这些 js 里面也算一直提及的重要概念，但是总是记了又忘，忘了又记，就算自己手写来实现过了，但是隔了几个月还是又忘了，因为没用过。但是学了函数式编程以后，发现全是这些东西，compose 呀、柯里化呀、部分应用呀，就跟用数组的 map、reduce 这些方法那么熟练，所以，现在闭着眼睛也能写出来，就几行代码的事儿。...

当我起笔写总结的第一感受就是 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。类似的最佳实践还有很多很多，自己可以发散一下。...