@朱徽同學(xué)，字節(jié)商業(yè)化前端，性喜靜，略微善文

大廠技術(shù)  高級前端  Node進階

點擊上方 程序員成長指北，關(guān)注公眾號

回復(fù)1，加入高級Node交流群

由于某次需求的需要，我進行了一次技術(shù)調(diào)研，內(nèi)容是調(diào)研前端將 pdf 文件轉(zhuǎn)為圖片的解決方案，我接到這個需求的第一時間，立馬打開搜索引擎，翻看了十分鐘后，很快啊得出了一個口頭結(jié)論

但這肯定是不行的，十分鐘就能整明白的事情就不叫技術(shù)調(diào)研了，也無需技術(shù)調(diào)研，然而如何擺好一個技術(shù)調(diào)研的正確姿勢，也沒有啥標(biāo)準(zhǔn)模板，讓開發(fā)人員寫文檔本來就夠痛了，再加上一個沒有標(biāo)準(zhǔn)的場景，痛上加痛，既然我想做好這次技術(shù)調(diào)研，就必須解決這個痛點，那就順便把這個問題也調(diào)研一下吧

網(wǎng)上關(guān)于如何做好技術(shù)調(diào)研的文章也有一些，本文主要是貼合自身，從前端的角度進行解讀

了解需求

首先你肯定要足夠了解需求的，然后才能確定一個技術(shù)調(diào)研方向

比如需要你實現(xiàn)一個環(huán)繞地球的3D顯示效果，你一看到 3D 立馬就想到 three.js 甚至是 webgl，然后二話不說開始悶頭研究起來，結(jié)果研究了兩天后，在開始做需求的時候，發(fā)現(xiàn)需求的重點并不是那個3D地球，而是環(huán)繞地球展示的數(shù)據(jù)點，實際上這是個可視化展示的需求而不是3D效果需求，echarts 才是最佳解決方案

那么這個過程中你固然是可以了解到一些跟 webgl 相關(guān)的知識，但畢竟跟需求產(chǎn)生了偏差，對于當(dāng)前需求來說可能是無用功

所以一定要確定好要求，準(zhǔn)確分析出需要準(zhǔn)備的技術(shù)點，再進入下一步

當(dāng)然，不僅是技術(shù)調(diào)研，平常的技術(shù)開發(fā)也是需要這一步的，即確定需求的要求然后你才能從技術(shù)的角度跟PM討價還價

什么時候需要技術(shù)調(diào)研

就像文章開頭提到的那樣，你得先確定一件事情需要調(diào)研你才能開始調(diào)研，如果十分鐘就能完全確定的事情就沒必要大費周折了

比如，你新啟動一個項目，在 vue 和 react 中猶豫，不知道到底用哪個好，如果這個問題放到5年前，你可能確實需要調(diào)研一番，但放到當(dāng)下這個時間點，顯然就沒必要了，十分鐘足以判斷

為什么5年前需要呢？因為那個時候，無論是 react 還是 vue，都不夠成熟，特別是 vue 在 2014 年才起步，沒有現(xiàn)在那么普及，對于當(dāng)時的前端圈來說，這兩個東西都還算是比較新穎的事務(wù)，有經(jīng)驗的人不多，可搜集到的資料也沒有那么全，為了保證線上的穩(wěn)定性，就必須先對它們仔細(xì)調(diào)研一番才能決定是否啟用

有些技術(shù)存在的時間已經(jīng)足夠久了，資料也比較齊全，但也不代表就能拿來就用

大多數(shù)前端可能都涉及不到可視化方面的開發(fā)，但可能突然某一天你就接到了一個3D環(huán)繞地球的可視化需求，準(zhǔn)確分析了需求的意圖后，你去網(wǎng)上搜了下，找到了最火的 echarts，但是從效果上來看，明顯不可能隨便三兩下就能實現(xiàn)的了，可能需要考慮很多問題，例如需要哪些配置？是否需要UI出圖？用的canvas還是webgl？是否有兼容性上的問題？這些細(xì)節(jié)性的東西，可能就需要你親自去實踐一番了

當(dāng)這些細(xì)節(jié)都已經(jīng)確定了之后，你發(fā)現(xiàn)還需要在3D地球的周圍加一些飛線之類的東西，或者是需要具備點擊地球上某個點實現(xiàn)地圖放大/縮小的能力，那么你就還得看下 echarts 是否支持這種功能，如果不支持是否有其他替代方案等

那么，綜合上述，需要技術(shù)調(diào)研的場景包括但不限于以下三個方面：

• 新技術(shù)，資料較少，社區(qū)不完備

• 足夠成熟，但不確定細(xì)節(jié)實現(xiàn)

• 想做 xxx 功能，但不確定能不能實現(xiàn)

調(diào)研方向

現(xiàn)存方案

得益于前端生態(tài)的百花齊放，對于同一個問題可能存在很多種解決方案，拋開那些重復(fù)的輪子以外，剩下的方案既然能夠存在下去就說明它們有存在的理由，必然都有各自的優(yōu)缺點，也都有各自最適合使用的場景

你需要先盡可能地羅列出市面上已存的較為流行的方案，然后再對這些方案進行各方面對比，選出一個最適合你當(dāng)前需求需要的方案

對于3D環(huán)繞地球效果這個需求來說，echarts、three.js、antdv、d3、chart.js 等都是潛在的可選方案，但是你不可能閉著眼睛隨便選一個就行了，要去一一了解它們的各自優(yōu)缺點，找出一個最適合你自己的

當(dāng)然，有些需求的解決方案可能就唯一的一個，例如前端操作PDF，線上可用的可能就只有 pdf.js 了，其他的可能都只是玩具，那么就只需要專注分析這一個即可

對比環(huán)節(jié)

了解了需求，列舉了所有可用方案后，下面就進入最重要的選優(yōu)環(huán)節(jié)了，方案對比的方向不要求能夠覆蓋所有方面，但最起碼應(yīng)該覆蓋一些關(guān)鍵節(jié)點

對比不應(yīng)當(dāng)僅是客觀地描述各個解決方案的優(yōu)劣，更主要的是結(jié)合你當(dāng)前的實際需求，從不同的方向上給各個解決方案進行打分，以解釋明白為什么從 A 功能上看，要選 α 方案，而從 B 功能上看，β 方案更好

原理

實現(xiàn)原理基本上決定了具體方案的方方面面，了解了原理，才能更好地進行分析

例如 echarts 是 svg/canvas 雙引擎，而 three.js 更多的是基于 webgl，那么如果想要更好地控制它們，前者要求開發(fā)者更熟悉 svg/canvas，而后者可能需要開發(fā)者具備一定的 webgl 知識；

例如，pdf.js 是依據(jù)pdf文件標(biāo)準(zhǔn)，純js進行二進制文件解析，不依賴特定瀏覽器API/特性實現(xiàn)的

知道了原理之后，對于其優(yōu)缺點就能有進一步的認(rèn)知，同時可以結(jié)合自己對于其底層原理相關(guān)知識的經(jīng)驗，得出更多的結(jié)論

活躍度

主要從 github star 數(shù)、代碼更新頻率、issue響應(yīng)速度、文檔完整度、在線示例、官方團隊和社區(qū)的規(guī)模等方面進行判斷

一個低于 1k star、超過半年沒有更新、issue很少或者響應(yīng)速度很慢，低于 3 個 contributor、文檔只有幾段話的項目一般而言是無法用于線上環(huán)境的

例如，echarts 由業(yè)內(nèi)知名公司開源，有專門團隊維護、有專門的社區(qū)、幾乎每天都有commit，顯然是一個可選方案

生產(chǎn)環(huán)境可用性

主要考慮的是，市面上是否已經(jīng)存在使用這個解決方案的案例了，如果有其他規(guī)模較大的產(chǎn)品線上使用了這個方案，那么在一定程度上可以證明，這個方案是可以放在線上的

比如，對于 echarts 和 antv 來說，市面上使用它們的產(chǎn)品比比皆是，毫無疑問是可以線上化的方案；再比如，對于 web在線編輯器來說，ACE 和 CodeMirror 都是很好的開源產(chǎn)品，但從目前使用廣泛度來說，CodeMirror 的受歡迎程度更高，羽雀、github都是基于其打造自己的在線編輯器，那么從這個方面相對來說，CodeMirror 可能比 ACE 更好

如果有內(nèi)部團隊曾經(jīng)有過這方面的使用案例，那么就更需要去溝通一番了，可能他們的使用場景跟你的不一樣（完全一樣的話可能就沒必要重復(fù)調(diào)研了），但肯定有可以借鑒的地方，了解他們的使用場景、使用過程中遇到的坑、是否有踩坑文檔、是否推薦使用等

功能

技術(shù)方案是為實際業(yè)務(wù)需求所服務(wù)的，選出的技術(shù)方案必須能夠滿足需求所要求的所有功能

對于3D環(huán)繞地球效果來說，echarts、three.js 都能實現(xiàn)這個效果，而 antv、chart.js 則沒有直接提供這個選項；而如果你想要可視化是關(guān)系數(shù)據(jù)（樹狀圖、腦圖、流程圖）并且配色更專業(yè)協(xié)調(diào)，那么antv-G6 可能就是最佳選擇

兼容性

前端必然需要考慮兼容性，比如瀏覽器的最低兼容版本、是否涉及pc端/移動端等，這其實也算是一種功能，用戶需要能使用你所提供的功能才行

echarts、antv基本上都支持到 IE9，但是 antv 對于移動端有更佳的優(yōu)化版本，所以如果你是在移動端使用，那么在其他主要功能都能滿足的前提下，應(yīng)該優(yōu)先考慮 antv

性能

可以從包體積、渲染速度方面進行考量

包體積過大，一方面會導(dǎo)致頁面加載速度變慢，其次是太大的體積意味著在一般情況下其性能也不會好到哪里去，例如，對于移動端gzip之后超過200k，pc端gzip之后超過 500k，都可以認(rèn)為是體積有點大了（數(shù)字只是憑經(jīng)驗給出的）

渲染太慢導(dǎo)致頁面空白時間過長或者瀏覽器失去響應(yīng)，都是很影響用戶體驗的事情，為了加入一個功能而導(dǎo)致另外一個功能效果變差，那么還不如不加

除了這兩個通用的之外，對于特定的技術(shù)方案可能還有特定的衡量指標(biāo)，比如對于前端pdf轉(zhuǎn)圖片這個需求，需要衡量的指標(biāo)應(yīng)該還有轉(zhuǎn)換過程需要耗費的時間，如果轉(zhuǎn)換一個10頁的 pdf需要5s以上，這就太慢了，如果再考慮到這個功能可能會存在幾十乃至是上百頁的pdf文件，那么顯然用戶是無法接受的

另外，你可以親自對關(guān)鍵性能指標(biāo)進行測試，列出詳細(xì)的數(shù)據(jù)，會更有說服力，比如你需要在移動端引入一個可視化庫，那么你就可以在移動端分別測試 antv 和 echarts 從加載到渲染完畢所需耗費的時間，得出一個耗時結(jié)果

可維護性

主要從工作量、學(xué)習(xí)/維護成本、對于業(yè)務(wù)的侵入度、最佳實踐等方面考量

一般情況下，開箱即用的肯定比需要一大堆配置項的要好，沒有額外學(xué)習(xí)成本的肯定比需要專業(yè)知識的要好（比如 webgl 就是專業(yè)知識），業(yè)務(wù)侵入度越低越好，如果能有官方/社區(qū)的最佳實踐可參考那就最好不過了

缺陷及隱患

關(guān)注缺點的優(yōu)先級高于關(guān)注優(yōu)點的優(yōu)先級，優(yōu)點再多，也可能因為一個缺點而不能被應(yīng)用

比如對于 antv，缺乏對于3D地球的直接支持，那么其他方便做的再好，對于你需求都是于事無補

不過也不是所有缺陷都不能容忍的

比如對于前端pdf轉(zhuǎn)圖片，pdf.js 直到目前為止依舊存在很多缺陷，還有一些issue創(chuàng)建幾年了都沒關(guān)，但這些問題如果并不影響你需求的實現(xiàn)，并且以后也不太可能涉及到這些，那么就是沒問題的

你的項目是pc端項目，那么pdf.js在移動端的縮放、兼容等問題就不是問題；你不可能加載超過100頁的復(fù)雜內(nèi)容pdf，那么pdf.js處理大文件時可能遇到的問題你就無需擔(dān)心

就算是可能與你需求相關(guān)的問題，如果其在可容忍范圍內(nèi)，那么也是可以接受的

比如pdf.js將原pdf文件轉(zhuǎn)為圖片后，清晰度會降低，但如果這并不明顯影響體驗，那么也是可以忽略的

其他

針對具體的技術(shù)方案，可能還有其他一些比較重要的環(huán)節(jié)，需要具體需求具體對待

調(diào)研一個表單組件，你可能需要考慮到其安全性（是否默認(rèn)防范xss攻擊）；調(diào)研一個UI庫，你可能需要考慮到到其是否具備跨端能力

產(chǎn)出文檔

基本上上述信息足以支撐起得出一個調(diào)研結(jié)論了，但這個結(jié)論不能只存在于你自己的腦海中，你應(yīng)當(dāng)將這個過程記錄下來，可以就按照上面的步驟作為模板，形成一份調(diào)研文檔進行輸出 這份調(diào)研文檔應(yīng)當(dāng)包括以下四個方面：

1、需求背景

你的調(diào)研文檔可能會被其他不熟悉你所做需求的人查看，對于一個做業(yè)務(wù)的技術(shù)人員來說，脫離具體業(yè)務(wù)談技術(shù)就是耍流氓，你好不容易調(diào)研了一番然后又產(chǎn)出一篇文檔，那么當(dāng)然想要更多的人能夠看得懂得到更多的認(rèn)同

2、一句話結(jié)論

為了能快速給出一個定調(diào)，作為詳細(xì)內(nèi)容的“太長不看版”

不是所有人都想先完整地看完所有調(diào)研內(nèi)容然后才得到一個結(jié)論的，你的詳細(xì)調(diào)研內(nèi)容都屬于過程，而結(jié)論可能才是很多看你調(diào)研文檔的人最先關(guān)心的東西，所以你應(yīng)該提供一句簡短的斷言結(jié)論

3、現(xiàn)存方案對比記錄

詳細(xì)的對比過程是為了調(diào)研結(jié)論的細(xì)節(jié)和說服力，讓別人更加認(rèn)同你的結(jié)論

這個對比記錄的內(nèi)容主要應(yīng)當(dāng)圍繞你當(dāng)前面臨的實際業(yè)務(wù)需求展開，除此之外，還可以描述一些需求可能涉及不到的點，比如你想調(diào)研pdf.js在pc端切割pdf文件轉(zhuǎn)為圖片的支持情況，那么除了這方面之外，你還可以額外描述一下其在移動端的支持度，給出一個更全面的參考，可能會對其他查看你調(diào)研報告的人產(chǎn)生啟發(fā)

當(dāng)然還是要注意主次關(guān)系，大部分內(nèi)容應(yīng)當(dāng)都是圍繞你所面臨的實際需求，額外的東西應(yīng)當(dāng)放在次要位置

4、參考文檔鏈接

作用和現(xiàn)存方案對比記錄差不多，都是你調(diào)研結(jié)果的支撐論據(jù)，也方便其他參考你報告的人自行去獲取更多的內(nèi)容

參考

• 當(dāng)我們在做技術(shù)調(diào)研的時候，到底需要做什么？怎么做？

• 技術(shù)調(diào)研的模式

• 如何做好技術(shù)調(diào)研

• 技術(shù)調(diào)研流程分享

關(guān)于本文 作者：@朱徽 原文：https://juejin.cn/post/6901845776880795662

Node 社群

我組建了一個氛圍特別好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你對Node.js學(xué)習(xí)感興趣的話（后續(xù)有計劃也可以），我們可以一起進行Node.js相關(guān)的交流、學(xué)習(xí)、共建。下方加 考拉 好友回復(fù)「Node」即可。

   “分享、點贊、在看” 支持一波??