前言
意识到很多时候不能靠经验，适当的时候还是需要做点技术调研。今日前端早读课文章由字节跳动
朱徽授权分享。朱徽同学，字节商业化前端，性喜静，略微善文正文从这开始~~
由于某次需求的需要，我进行了一次技术调研，内容是调研前端将pdf文件转为图片的解决方案，我接到这个需求的第一时间，立马打开搜索引擎，翻看了十分钟后，很快啊得出了一个口头结论
但这肯定是不行的，十分钟就能整明白的事情就不叫技术调研了，也无需技术调研，然而如何摆好一个技术调研的正确姿势，也没有啥标准模板，让开发人员写文档本来就够痛了，再加上一个没有标准的场景，痛上加痛，既然我想做好这次技术调研，就必须解决这个痛点，那就顺便把这个问题也调研一下吧
网上关于如何做好技术调研的文章也有一些，本文主要是贴合自身，从前端的角度进行解读
了解需求首先你肯定要足够了解需求的，然后才能确定一个技术调研方向
比如需要你实现一个环绕地球的3D显示效果，你一看到3D立马就想到three.js甚至是webgl，然后二话不说开始闷头研究起来，结果研究了两天后，在开始做需求的时候，发现需求的重点并不是那个3D地球，而是环绕地球展示的数据点，实际上这是个可视化展示的需求而不是3D效果需求，echarts才是最佳解决方案
那么这个过程中你固然是可以了解到一些跟webgl相关的知识，但毕竟跟需求产生了偏差，对于当前需求来说可能是无用功
所以一定要确定好要求，准确分析出需要准备的技术点，再进入下一步
当然，不仅是技术调研，平常的技术开发也是需要这一步的，即确定需求的要求然后你才能从技术的角度跟PM讨价还价
什么时候需要技术调研就像文章开头提到的那样，你得先确定一件事情需要调研你才能开始调研，如果十分钟就能完全确定的事情就没必要大费周折了
比如，你新启动一个项目，在vue和react中犹豫，不知道到底用哪个好，如果这个问题放到5年前，你可能确实需要调研一番，但放到当下这个时间点，显然就没必要了，十分钟足以判断
为什么5年前需要呢？因为那个时候，无论是react还是vue，都不够成熟，特别是vue在年才起步，没有现在那么普及，对于当时的前端圈来说，这两个东西都还算是比较新颖的事务，有经验的人不多，可搜集到的资料也没有那么全，为了保证线上的稳定性，就必须先对它们仔细调研一番才能决定是否启用
有些技术存在的时间已经足够久了，资料也比较齐全，但也不代表就能拿来就用
大多数前端可能都涉及不到可视化方面的开发，但可能突然某一天你就接到了一个3D环绕地球的可视化需求，准确分析了需求的意图后，你去网上搜了下，找到了最火的echarts，但是从效果上来看，明显不可能随便三两下就能实现的了，可能需要考虑很多问题，例如需要哪些配置？是否需要UI出图？用的canvas还是webgl？是否有兼容性上的问题？这些细节性的东西，可能就需要你亲自去实践一番了
当这些细节都已经确定了之后，你发现还需要在3D地球的周围加一些飞线之类的东西，或者是需要具备点击地球上某个点实现地图放大/缩小的能力，那么你就还得看下echarts是否支持这种功能，如果不支持是否有其他替代方案等
那么，综合上述，需要技术调研的场景包括但不限于以下三个方面：
新技术，资料较少，社区不完备
足够成熟，但不确定细节实现
想做xxx功能，但不确定能不能实现
调研方向现存方案得益于前端生态的百花齐放，对于同一个问题可能存在很多种解决方案，抛开那些重复的轮子以外，剩下的方案既然能够存在下去就说明它们有存在的理由，必然都有各自的优缺点，也都有各自最适合使用的场景
你需要先尽可能地罗列出市面上已存的较为流行的方案，然后再对这些方案进行各方面对比，选出一个最适合你当前需求需要的方案
对于3D环绕地球效果这个需求来说，echarts、three.js、antdv、d3、chart.js等都是潜在的可选方案，但是你不可能闭着眼睛随便选一个就行了，要去一一了解它们的各自优缺点，找出一个最适合你自己的
当然，有些需求的解决方案可能就唯一的一个，例如前端操作PDF，线上可用的可能就只有pdf.js了，其他的可能都只是玩具，那么就只需要专注分析这一个即可
对比环节了解了需求，列举了所有可用方案后，下面就进入最重要的选优环节了，方案对比的方向不要求能够覆盖所有方面，但最起码应该覆盖一些关键节点
对比不应当仅是客观地描述各个解决方案的优劣，更主要的是结合你当前的实际需求，从不同的方向上给各个解决方案进行打分，以解释明白为什么从A功能上看，要选α方案，而从B功能上看，β方案更好
原理实现原理基本上决定了具体方案的方方面面，了解了原理，才能更好地进行分析
例如echarts是svg/canvas双引擎，而three.js更多的是基于webgl，那么如果想要更好地控制它们，前者要求开发者更熟悉svg/canvas，而后者可能需要开发者具备一定的webgl知识；
例如，pdf.js是依据pdf文件标准，纯js进行二进制文件解析，不依赖特定浏览器API/特性实现的
知道了原理之后，对于其优缺点就能有进一步的认知，同时可以结合自己对于其底层原理相关知识的经验，得出更多的结论
活跃度主要从githubstar数、代码更新频率、issue响应速度、文档完整度、在线示例、官方团队和社区的规模等方面进行判断
一个低于1kstar、超过半年没有更新、issue很少或者响应速度很慢，低于3个contributor、文档只有几段话的项目一般而言是无法用于线上环境的
例如，echarts由业内知名公司开源，有专门团队维护、有专门的社区、几乎每天都有