理清思路，前端技术调研到底应该怎么作？

因为某次需求的须要，我进行了一次技术调研，内容是调研前端将 pdf 文件转为图片的解决方案，我接到这个需求的第一时间，立马打开搜索引擎，翻看了十分钟后，很快啊得出了一个口头结论

但这确定是不行的，十分钟就能整明白的事情就不叫技术调研了，也无需技术调研，然而如何摆好一个技术调研的正确姿式，也没有啥标准模板，让开发人员写文档原本就够痛了，再加上一个没有标准的场景，痛上加痛，既然我想作好此次技术调研，就必须解决这个痛点，那就顺便把这个问题也调研一下吧

网上关于如何作好技术调研的文章也有一些，本文主要是贴合自身，从前端的角度进行解读

了解需求

首先你确定要足够了解需求的，而后才能肯定一个技术调研方向

好比须要你实现一个环绕地球的3D显示效果，你一看到 3D 立马就想到 three.js 甚至是 webgl，而后二话不说开始闷头研究起来，结果研究了两天后，在开始作需求的时候，发现需求的重点并非那个3D地球，而是环绕地球展现的数据点，实际上这是个可视化展现的需求而不是3D效果需求，echarts 才是最佳解决方案

那么这个过程当中你当然是能够了解到一些跟 webgl 相关的知识，但毕竟跟需求产生了误差，对于当前需求来讲多是无用功

因此必定要肯定好要求，准确分析出须要准备的技术点，再进入下一步

固然，不只是技术调研，日常的技术开发也是须要这一步的，即肯定需求的要求而后你才能从技术的角度跟PM讨价还价

何时须要技术调研

就像文章开头提到的那样，你得先肯定一件事情须要调研你才能开始调研，若是十分钟就能彻底肯定的事情就不必大费周折了

好比，你新启动一个项目，在 vue 和 react 中犹豫，不知道到底用哪一个好，若是这个问题放到5年前，你可能确实须要调研一番，但放到当下这个时间点，显然就不必了，十分钟足以判断

为何5年前须要呢？由于那个时候，不管是 react 仍是 vue，都不够成熟，特别是 vue 在 2014 年才起步，没有如今那么普及，对于当时的前端圈来讲，这两个东西都还算是比较新颖的事务，有经验的人很少，可搜集到的资料也没有那么全，为了保证线上的稳定性，就必须先对它们仔细调研一番才能决定是否启用

有些技术存在的时间已经足够久了，资料也比较齐全，但也不表明就能拿来就用

大多数前端可能都涉及不到可视化方面的开发，但可能忽然某一天你就接到了一个3D环绕地球的可视化需求，准确分析了需求的意图后，你去网上搜了下，找到了最火的 echarts，可是从效果上来看，明显不可能随便三两下就能实现的了，可能须要考虑不少问题，例如须要哪些配置？是否须要UI出图？用的canvas仍是webgl？是否有兼容性上的问题？这些细节性的东西，可能就须要你亲自去实践一番了

当这些细节都已经肯定了以后，你发现还须要在3D地球的周围加一些飞线之类的东西，或者是须要具有点击地球上某个点实现地图放大/缩小的能力，那么你就还得看下 echarts 是否支持这种功能，若是不支持是否有其余替代方案等

那么，综合上述，须要技术调研的场景包括但不限于如下三个方面：

1. 新技术，资料较少，社区不完备
2. 足够成熟，但不肯定细节实现
3. 想作 xxx 功能，但不肯定能不能实现

调研方向

现存方案

得益于前端生态的百花齐放，对于同一个问题可能存在不少种解决方案，抛开那些重复的轮子之外，剩下的方案既然可以存在下去就说明它们有存在的理由，必然都有各自的优缺点，也都有各自最适合使用的场景

你须要先尽量地罗列出市面上已存的较为流行的方案，而后再对这些方案进行各方面对比，选出一个最适合你当前需求须要的方案

对于3D环绕地球效果这个需求来讲，echarts、three.js、antdv、d三、chart.js 等都是潜在的可选方案，可是你不可能闭着眼睛随便选一个就好了，要去一一了解它们的各自优缺点，找出一个最适合你本身的

固然，有些需求的解决方案可能就惟一的一个，例如前端操做PDF，线上可用的可能就只有 pdf.js 了，其余的可能都只是玩具，那么就只须要专一分析这一个便可

对比环节

了解了需求，列举了全部可用方案后，下面就进入最重要的选优环节了，方案对比的方向不要求可以覆盖全部方面，但最起码应该覆盖一些关键节点

对比不该当仅是客观地描述各个解决方案的优劣，更主要的是结合你当前的实际需求，从不一样的方向上给各个解决方案进行打分，以解释明白为何从 A 功能上看，要选 α 方案，而从 B 功能上看，β 方案更好

原理

实现原理基本上决定了具体方案的方方面面，了解了原理，才能更好地进行分析

例如 echarts 是 svg/canvas 双引擎，而 three.js 更多的是基于 webgl，那么若是想要更好地控制它们，前者要求开发者更熟悉 svg/canvas，然后者可能须要开发者具有必定的 webgl 知识； 例如，pdf.js 是依据pdf文件标准，纯js进行二进制文件解析，不依赖特定浏览器API/特性实现的

知道了原理以后，对于其优缺点就能有进一步的认知，同时能够结合本身对于其底层原理相关知识的经验，得出更多的结论

活跃度

主要从 github star 数、代码更新频率、issue响应速度、文档完整度、在线示例、官方团队和社区的规模等方面进行判断

一个低于 1k star、超过半年没有更新、issue不多或者响应速度很慢，低于 3 个 contributor、文档只有几段话的项目通常而言是没法用于线上环境的

例如，echarts 由业内知名公司开源，有专门团队维护、有专门的社区、几乎天天都有commit，显然是一个可选方案

生产环境可用性

主要考虑的是，市面上是否已经存在使用这个解决方案的案例了，若是有其余规模较大的产品线上使用了这个方案，那么在必定程度上能够证实，这个方案是能够放在线上的

好比，对于 echarts 和 antv 来讲，市面上使用它们的产品比比皆是，毫无疑问是能够线上化的方案； 再好比，对于 web在线编辑器来讲，ACE 和 CodeMirror 都是很好的开源产品，但从目前使用普遍度来讲，CodeMirror 的受欢迎程度更高，羽雀、github都是基于其打造本身的在线编辑器，那么从这个方面相对来讲，CodeMirror 可能比 ACE 更好

若是有内部团队曾经有过这方面的使用案例，那么就更须要去沟通一番了，可能他们的使用场景跟你的不同（彻底同样的话可能就不必重复调研了），但确定有能够借鉴的地方，了解他们的使用场景、使用过程当中遇到的坑、是否有踩坑文档、是否推荐使用等

功能

技术方案是为实际业务需求所服务的，选出的技术方案必须可以知足需求所要求的全部功能

对于3D环绕地球效果来讲，echarts、three.js 都能实现这个效果，而 antv、chart.js 则没有直接提供这个选项；而若是你想要可视化是关系数据（树状图、脑图、流程图）而且配色更专业协调，那么antv-G6 可能就是最佳选择

兼容性

前端必然须要考虑兼容性，好比浏览器的最低兼容版本、是否涉及pc端/移动端等，这其实也算是一种功能，用户须要能使用你所提供的功能才行

echarts、antv基本上都支持到 IE9，可是 antv 对于移动端有更佳的优化版本，因此若是你是在移动端使用，那么在其余主要功能都能知足的前提下，应该优先考虑 antv

性能

能够从包体积、渲染速度方面进行考量

包体积过大，一方面会致使页面加载速度变慢，其次是太大的体积意味着在通常状况下其性能也不会好到哪里去，例如，对于移动端gzip以后超过200k，pc端gzip以后超过 500k，均可以认为是体积有点大了（数字只是凭经验给出的）

渲染太慢致使页面空白时间过长或者浏览器失去响应，都是很影响用户体验的事情，为了加入一个功能而致使另一个功能效果变差，那么还不如不加

除了这两个通用的以外，对于特定的技术方案可能还有特定的衡量指标，好比对于前端pdf转图片这个需求，须要衡量的指标应该还有转换过程须要耗费的时间，若是转换一个10页的 pdf须要5s以上，这就太慢了，若是再考虑到这个功能可能会存在几十乃至是上百页的pdf文件，那么显然用户是没法接受的

另外，你能够亲自对关键性能指标进行测试，列出详细的数据，会更有说服力，好比你须要在移动端引入一个可视化库，那么你就能够在移动端分别测试 antv 和 echarts 从加载到渲染完毕所需耗费的时间，得出一个耗时结果

可维护性

主要从工做量、学习/维护成本、对于业务的侵入度、最佳实践等方面考量

通常状况下，开箱即用的确定比须要一大堆配置项的要好，没有额外学习成本的确定比须要专业知识的要好（好比 webgl 就是专业知识），业务侵入度越低越好，若是能有官方/社区的最佳实践可参考那就最好不过了

缺陷及隐患

关注缺点的优先级高于关注优势的优先级，优势再多，也可能由于一个缺点而不能被应用

好比对于 antv，缺少对于3D地球的直接支持，那么其余方便作的再好，对于你需求都是于事无补

不过也不是全部缺陷都不能容忍的

好比对于前端pdf转图片，pdf.js 直到目前为止依旧存在不少缺陷，还有一些issue建立几年了都没关，但这些问题若是并不影响你需求的实现，而且之后也不太可能涉及到这些，那么就是没问题的 你的项目是pc端项目，那么pdf.js在移动端的缩放、兼容等问题就不是问题；你不可能加载超过100页的复杂内容pdf，那么pdf.js处理大文件时可能遇到的问题你就无需担忧

就算是可能与你需求相关的问题，若是其在可容忍范围内，那么也是能够接受的

好比pdf.js将原pdf文件转为图片后，清晰度会下降，但若是这并不明显影响体验，那么也是能够忽略的

其余

针对具体的技术方案，可能还有其余一些比较重要的环节，须要具体需求具体对待

调研一个表单组件，你可能须要考虑到其安全性（是否默认防范xss攻击）；调研一个UI库，你可能须要考虑到到其是否具有跨端能力

产出文档

基本上上述信息足以支撑起得出一个调研结论了，但这个结论不能只存在于你本身的脑海中，你应当将这个过程记录下来，能够就按照上面的步骤做为模板，造成一份调研文档进行输出

这份调研文档应当包括如下四个方面：

1. 需求背景

你的调研文档可能会被其余不熟悉你所作需求的人查看，对于一个作业务的技术人员来讲，脱离具体业务谈技术就是耍流氓，你好不容易调研了一番而后又产出一篇文档，那么固然想要更多的人可以看得懂获得更多的认同

2. 一句话结论

为了能快速给出一个定调，做为详细内容的“太长不看版”

不是全部人都想先完整地看完全部调研内容而后才获得一个结论的，你的详细调研内容都属于过程，而结论可能才是不少看你调研文档的人最早关心的东西，因此你应该提供一句简短的断言结论

3. 现存方案对比记录

详细的对比过程是为了调研结论的细节和说服力，让别人更加认同你的结论

这个对比记录的内容主要应当围绕你当前面临的实际业务需求展开，除此以外，还能够描述一些需求可能涉及不到的点，好比你想调研pdf.js在pc端切割pdf文件转为图片的支持状况，那么除了这方面以外，你还能够额外描述一下其在移动端的支持度，给出一个更全面的参考，可能会对其余查看你调研报告的人产生启发

固然仍是要注意主次关系，大部份内容应当都是围绕你所面临的实际需求，额外的东西应当放在次要位置

4. 参考文档连接

做用和现存方案对比记录差很少，都是你调研结果的支撑论据，也方便其余参考你报告的人自行去获取更多的内容

参考文档

• 当咱们在作技术调研的时候，到底须要作什么？怎么作？
• 技术调研的模式
• 如何作好技术调研
• 技术调研流程分享