理清思路，前端技術調研到底應該怎麼作？

因爲某次需求的須要，我進行了一次技術調研，內容是調研前端將 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. 參考文檔連接

做用和現存方案對比記錄差很少，都是你調研結果的支撐論據，也方便其餘參考你報告的人自行去獲取更多的內容

參考文檔

• 當咱們在作技術調研的時候，到底須要作什麼？怎麼作？
• 技術調研的模式
• 如何作好技術調研
• 技術調研流程分享