我的2019

2019年，是对我非常重要的一年，比想象中更累的一年，比想象中收获更多的一年。这一年，真的发生了非常多的事，无论是生活还是工作学习上，由于是技术社区的年度征文，我就从 写作和积累 、 技术上的提升 、 工作上的转换 这三个方向来总结一下这一年。

写作和积累

这部分我在 code秘密花园2019年终总结 | 原创文章汇总 这篇文章里已经总结过，这里就不在赘述了。

技术上的提升

2019年我的技术关键词应该是 React 、 数据结构和算法 、 工程化 ，当然其他的技术我也有涉猎，但是主要深挖的还是这三个方向，

React

这一年关于 React 我做了很多原理上的分析，读了 redux 、 mobx 以及一部分 React 源码。

说实话 React 源码是我读过的源码里最难读的一个，我相信很多同学都有这个想法，如果硬生生的读很容易半途而废。这里我分享一下我的经验:一定要带着实际问题去读源码，我就是如此，在读源码的时候带着日常开发中经常会遇到的问题：

• setState 是同步的还是异步的？

• 为什么有时连续多次 setState 只有一次生效？

• React 如何实现自己的事件机制？

• 为何 React 事件要自己绑定 this ？

• ...

这样你在读源码的时候就会不断想去通过源码找到这些问题的答案，而不是看完源码再想发现了些什么，当你从源码中找到了你想要的答案，那么说明你的努力是没有白费的。

因为之前我在生产环境使用的 React 一直是 15.x ，所以源码解析大多数都停留在 16 版本以前，如今 React17 马上要发布了， React 又给我们带来了非常多的令人激动的新特性：可中断渲染、指定加载顺序、并行处理多状态... 未来我还会针对这些新特性对 React 继续探索。

数据结构和算法

18年立过一个flag，2019年要把重新把数据结构和算法练好，我一直认为，数据结构和算法对于一个程序员是非常重要的，前端工程师也是一样的。它能带给你的不仅仅是面试上的收益，更重要的是可以拓宽你解决问题的思路。

当然你可能会讲，有些大佬并没有刻意练习数据结构和算法，但是他们一样很厉害。不得不承认有些人先天就有优势，又或者他们能从其他途径领悟这些解决问题的思路，但这并不能否认数据结构和算法能够让你获得这些思路，而且是属于比较快捷的途径。

2019年我做了差不多 300 道左右题目，输出了题解 60 余篇，困难：中等：简单比例大概是 1:3:3 左右，全部都放在我的仓库 awesome-coding-js 中。

虽然这个数量跟很多大佬比起来不算什么，但是这些题目基本上覆盖了常见算法（排序、递归、二分、搜索、回溯、动态规划、贪心）和数据结构（数组、二叉树、链表、栈和队列、哈希、堆）的各个分类，由于时间有限，我一般也只会挑这些分类的典型题目，然后针对某一类题目进行总结。我也针对这些题解又做了一个比较全面的系统性的解题指南 前端该如何准备数据结构和算法？ 希望能够帮到大家。

刚开始做算法题目是非常耗时的，有时候一道题要花上几个小时的时间，我的做题时间一般是晚上下班后睡觉前，做完就睡觉，所以做题时间和睡觉时间是成反比的，这也能激励我快速的把题目解出来。

当然现在已经好很多了，经过长时间有规律的练习和总结，现在遇到典型的题目我都能很快的解答出来，遇到有点难度的基本上也可以套用已有的思想慢慢的解出来，不会再有当初毫无头绪的感觉了，不得不说，这真的是一个非常奇妙的过程，强烈建议大家也体验一下。

工程化

前端工程化就是以工程化方法和工具提高开发生产效率、降低维护难度、把控研发质量。我研究的方向仔细划分其实还可以划分为研发效率、研发质量、研发安全三个方向。

研发效率

提升研发效率应该是最常见的前端工程化方向了，整个研发流程的各个节点都是可以进行统一规范和优化的。

从初始化的脚手架，到研发的代码规范，到开发调试的工具，再到构建打包、自动化CICD，都可以做成一套统一的并且可适配不同业务场景的解决方案。这个工作还是非常有意思并且有一定挑战性的。

研发质量

研发质量也可以放到工程化的范畴，研发质量也是可以从多维度多场景来衡量的。和上面的研发效率类似，研发质量也可以从研发的全流程，也就是初始化、开发、调试、构建、上线、性能监控、错误监控来体现出来。

市面上大部分的监控研发质量的工具都只是针对以上的某一个阶段，我的目标是实现一套针对研发质量监控的全流程解决方案。

我之前写过一篇 前端代码质量-圈复杂度原理和实践 ，实际上这只属于以上的开发阶段的代码分析阶段的一小部分，其中单单代码分析阶段就会有很多很多需要探索的事情。

比如下面的代码文件耦合度分析:耦合指逻辑层面上有互相关联和影响的代码模块，通常这个可以通过分析文件的依赖，以及分析一个给定时间分片内，代码的提交情况判断（耦合的模块通常会在一起提交），耦合是一种常见以及肯定会出现的情况，并不一定是坏事。但是需要能够展现出非必要耦合的能力，例如我在改文件A的时候通常也会修改和文件A看似毫无关联的B文件，这两个文件就可能存在需要解耦的必要。

如下图，红色部分代表系统内某个时间分片内经常协同修改的文件，即改了A就会改B，这些文件是存在耦合的。通过耦合的检测和可视化，我们可以做到检测单元测试以及文档是否在和系统代码本身同时演进；检测代码架构上有问题的部分和模块间隐藏的设计上的依赖。

下面的协作效率分析，也属于开发阶段的质量监控:有时增加开发者的数量并不能显著的增加开发效率，如果你的项目有可能成为布鲁克斯定律的受害者，那么你会发现开发者总数与其产出之间的距离会增加。

布鲁克斯法则：指投入更多的人来开发一个紧急的项目只会让进度更慢。更多并不意味着更好，有些事最好是一个人来干。

总之这也是一个很复杂并且很有挑战性的方向，需要研发全流程的大量数据监控和算法架构的支持。我也期待未来可以把这个方向做的更好。

研发安全

大部分同学可能对安全问题还停留在 xss 、 csrf 等常见问题上，其实安全问题多种多样，有可能你不经意间一个操作就可能引起一个安全问题，比如你不小心把 source map 文件传到了线上，吃瓜群众就可以开心的在控制台看你的源码了...

当然，安全问题造成的影响不仅仅是上面这么简单，可能你的日志打点不小心在某些国家多收集了一些数据，就可能会引起该国家对你启动国家安全调查（咳咳这里就不明说了...）。回想之前 Facebook 的用户信息泄露问题，直接给他带来 50 亿美元的巨额罚款...

这些都有可能是你的几行代码就可能造成的影响，所以一定要重视代码安全问题，不然有可能你在不经意间就把公司写破产了～

大部分安全问题其实都是可以人为避免的，而我们能做的就是从工程化的角度去发现和避免这些问题，这样的工作对于有一定体量的公司还是非常重要的。

开源

我玩 github 的时间并不久，之前只是去 github 下载项目，偶尔逛逛 issues ，今年才开始把自己沉淀的一些东西开源出来。以后会有更多更实用更有意思的东西开源出来。

这一年收获的 star 大概有 2k 左右，这个数字跟众多 上万star 的大佬们真的不能比，但是对我来讲已经很满足了，是一个很好的开始。

我的道歉

这里真的要跟关注和使用我开源项目的同学说一声抱歉，首先真的很感谢你们的关注，你们的关注也带给我持续输出的动力，但是下半年工作上我真的非常忙（具体原因下面会阐述），花在博客和开源项目上的时间少了许多，以至于很多问题不能及时修复，下面是我某个项目下的 issues ：

下面是我的 github commit 记录，后半年的提交真的少了很多，这里真的要跟大家说一声抱歉。明年我会尽力想办法更好的去平衡工作和学习时间，来修复这些问题。

项目列表

还有一点就是真的希望有感兴趣的同学来一起来参与项目的共建，我之前也收到过很多同学的 pr ，只要是有价值的我都会合并，一个好的开源项目还得需要社区的力量来不断的完善和优化，下面是我的几个开源项目：

tpanorama

tpanorama 是一个全景插件，它可以把一张平面图转换为可操作的全景效果，并且提供自定义标记、平面球面标记互转功能，我的这篇文章 看完这篇，你也可以实现一个360度全景插件 就是对这个全景插件的实现讲解。

在功能上它还有许多需要完善的地方，上面我贴的 issues 就是这个项目的，感兴趣的同学可以一起共建来修复这些问题，或者添加新的功能。

https://github.com/ConardLi/tpanorama

electron-react

electron-react ，使用 electron + react + react-router + mobx + webpack 搭建的脚手架工程，集成了开发调试、程序保护、升级、打包构建等功能，另外还对窗口、通信、菜单、系统、弹框、打印 等常用功能提供了示例 demo 。

https://github.com/ConardLi/electron-react

awesome-cli

这个项目是我开发的一些有趣实用的命令行工具集合，目前提供代码扫描、代码行数统计、代码复杂度检测等功能，后面我会继续完善。

https://github.com/ConardLi/awesome-cli

awesome-coding-js

这是一个 markdown 项目，上面已经介绍过了我的算法题解都记录在这上面，不得不说 github 上的 markdown 项目 star 都挺多的。

https://github.com/ConardLi/awesome-coding-js

工作上的转换

今年我对于工作的关键词应该是 转换

由前端到全栈

最近又重新捡起了尘封已久了 sql ，也开始在 nodejs 上发力，并且还会写一些 go 和 python ，自己 cover 整个研发全流程的感觉非常好，再也不用和后端撕逼了...

由业务到架构

今年上半年以及之前的工作，基本上都是和业务打交道的，按照排期完整需求。然后剩余的时间就是关心线上监控、对已有的功能进行性能优化、以及为了提升业务效率而造轮子。

今年的下半年，可能算是我工作的一个转折点，我开始专注于前端基础架构方面的工作，主要方向我上面已经提到了，研发效率、研发质量、研发安全。这些东西是我以前从没有深入研究过的，对我来讲非常有挑战性，我也非常感兴趣。

上面我提到了我下半年非常的忙，这里我就简单说明一下，做业务和做架构真的不一样。做业务相对来说是见到成效比较快的，而基础架构不一样，需要很长的时间去打磨和优化，短时间很难见到成果，做完一件事情之后我会想方设法的去优化，让它变的更好，而且还有非常多新的事情等着我去做。总之我一直会抱着一种没有最好只有更好，没有最完善只有更完善的心态去做，所以下半年我花在开源项目和总结输出上的时间少了很多。

但是这对我来讲并不是一个坏事，输出的时间变少意味着沉淀的时间会更多，通过大量长时间的积累和沉淀才能多输出一些有价值的东西。也希望未来的我能够继续沉淀下去，戒骄戒躁、厚积而薄发。

尾声和开始

2019 已经进入尾声，我们也即将迎来 2020 的开始。其实我现在还能想起 2018 年除夕夜的鞭炮声，想到当时我对新的一年的展望... 闭上眼睛， 2019 的点点滴滴还历历在目，一个圆满的尾声又即将变成了一个崭新的开始... 2020 年会发生什么？谁知道呢～

2019 年你过得怎么样？开心还是不开心？赚钱了还是负债了？减肥成功了么？年初的 flag 完成了么？和喜欢的人在一起了么？升职加薪还是被裁员了？你的尾声是什么？你的开始又是什么？欢迎分享出来 ...

不开赞赏了，喜欢请转发，或者点个在看～