ConardLi：写好一篇技术文章的秘诀是为他人带来价值 | 思否年度征文

# 思否年度征文

一起来总结你的 2019 #

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

—— @ConardLi

*本文为 SegmentFault 思否社区征文活动参选稿件，了解活动详情，请点击文章底部海报图片。

No.1

写作和积累

我来思否的时间并不长，发表的文章也不是很多，但是我真的非常喜欢这个社区，我的文章在这里产生了非常多的阅读量和点赞，这些数字能够满足我的虚荣心，但是同样让我在发表文章的时候变得诚惶诚恐。文章一旦发出来就会经过众多目光的检阅，所以虽然我发表文章的数量并不多，但每篇文章都是经过我反复修改和优化的，所以一篇原创文章所要花费的时间是非常多的，由于平时工作比较忙，每天只有有限的时间学习和总结，加上反复的修改和优化，有时一篇文章要花上一个月的时间。

这里关于原创文章我发表一些我的看法，关于 原创文章 和 知识总结 是有非常大的区别的，前者是要为他人提供一定价值，后者是自己做查阅使用。如果文章仅仅停留在知识总结的层面上，那大可不必发出来，放在自己的笔记里就好了，所以一旦是发表在外面的原创文章我一定会保证每篇文章的质量，保证发出来都是对大家有一定价值的。

很多同学问过我，写好一篇文章的秘诀是什么，如果真的有秘诀，那就是在写这篇文章的时候时刻要想着，写出来的东西不仅仅自己要非常明白，而且能够让其他阅读的人也明白，并且为他们带来一定价值。

下面是我今年在社区发表的一些文章，虽然数量不多，但我尽量保证每一篇都是精品：

自检

这篇文章本来是用于归纳总结我自己的知识体系的，没想到发出来受到很多人的关注，我更希望的还是大家以我的这篇文章为例，建立自己的知识体系，然后不断去自检和完善。

• 一名【合格】前端工程师的自检清单

工程化

今年下半年的工作主要在前端工程化上，所以我研究和输出的重心也放到了这上面，这将会是一个很长的系列，未来我会尽可能的将我在工程化上的底层研究和最近技术输出给大家。

• 前端工程化 - 剖析 npm 的包管理机制 （完整版）
• 前端代码质量-圈复杂度原理和实践
• 前端开发者必备的 nginx 知识

React

关于 React 我做了很多源码和原理上的分析，大多数都停留在 16 版本以前，React17 马上要发布了，未来我还会继续在时间切片、异步渲染等最新特性上输出一些原理分析文章。

• 【React 深入】深入分析虚拟 DOM 的渲染过程和特性
• 【React 深入】从 Mixin 到 HOC 再到 Hook
• 【React 深入】React 事件机制
• 【React 深入】setState 的执行机制

JavaScript

市面上非常多关于 JS 基础的文章，我不太喜欢简单的知识点罗列，我更喜欢在实际的应用中将这些知识点体现出来，未来也是如此，这部分也会有更多的文章。

• 如何写出一个惊艳面试官的深拷贝
• 【JS 进阶】你真的掌握变量和类型了吗
• 一个函数让你看懂 'Why 0.1+0.2!=0.3'

送你 43 道 JavaScript 面试题源于我对开源项目 javascript-questions 的翻译，只发了一篇文章在思否上，好久没更新了，后面会继续跟进最近题目。

网络

一篇非常全面的对 ajax、fetch 原理和应用的分析文章。

• 全面分析前端的网络请求方式

Electron

用 JS 开发跨平台桌面应用，从原理到实践 是从【运行原理】到【实际应用】对 Electron 进行一次系统性的总结，非常全面。

Webgl

• 看完这篇，你也可以实现一个 360 度全景插件

跨端

从移动端适配的基础概念出发，探究移动端适配各种问题的解决方案和实现原理。

• 关于移动端适配，你必须要知道的

数据结构和算法

数据结构和算法是我一直在持续练习的，我平时也会分享出一些题目或者一些类型的解题方法出来，不过重要的还是要掌握解题的思想，所以我整理了开源项目 awesome-coding-js ，并且写了前端应该如何准备数据结构和算法？这篇文章，希望大家通过这篇文章能系统性的掌握和联系数据结构和算法，而仅仅不局限于某些题目。

新技术

我一直比较喜欢关注业界的最新技术动态以及走向，并且定期总结，今年年尾我开始把我关注的技术动态的东西分享出来，于是我总结成【技术圈】这个专栏，它是我对业界最新技术动态的跟进总结，不仅限于前端，未来我会持续更新。

• 【技术圈】谷歌新提案：可在脱机状态实现内容分发、大四学生开源文言文编程语言，star 破 5K
• 【技术圈】Node.js 宣布对 ECMAScript 的正式支持、WebAssembly 正式成为 W3C 标准

No.2

技术上的提升

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 中。

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

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

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

工程化

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

1. 研发效率

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

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

2. 研发质量

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

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

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

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

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

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

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

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

3. 研发安全

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

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

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

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

No.3

开源

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

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

我的道歉

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

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

项目列表

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

1. tpanorama

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

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

https://github.com/ConardLi/tpanorama

2. electron-react

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

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

3. awesome-cli

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