由于某次须要的须要，我举办了一次手艺调研，体例是调研前端将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由业内著名公司开源，有特地团队维持、有特地的社区、险些天天都有