跳到主要內容
黯羽輕揚每天積累一點點

定制化 IDE 選型筆記

免費2018-03-24#Mind#开源IDE二次开发#定制IDE#VSCode二次开发#VSCode vs Atom#VSCode deep customization

第二次獨立選型，看到了一些不太一樣的東西

零。為什麼要定制？

把 IDE 這樣龐大的黑盒掀開一角，妄圖進行深度定制，看起來那可真蠢，寫寫插件不好嗎？之所以這樣做，主要有 2 個原因：

  • 更高的靈活性：不受擴展機制限制，無論定制現有功能，還是擴展新功能，都是可實現的

  • 更細的控制粒度：深度的二次開發能夠做到細節完全可控，滿足細粒度的定制需求

實際上，靈活性收益的多少取決於擴展機制的限制程度，如果插件機制是完全開放的，二次開發帶來的靈活性提升就顯得不那麼必要了，例如 Atom 的擴展機制，幾乎沒什麼限制，依靠插件機制完全可以造出來一個全新的 IDE，比如 Nuclide

控制粒度則側重於可定制能力，例如主題風格、UI 佈局、語法擴展等等，二次開發能夠支持定制那些插件機制不允許定制的部分，小到應用名稱/圖標，大到 UI 佈局/交互操作

另一方面，從需求場景來看，專用的 IDE 有幾個優勢：

  • 一站式工具：集成。葫蘆小金剛的感覺，擁有其它 7 個娃的所有能力

  • 沉浸式體驗：銜接。把工具鏈有機組合起來，腳手架 - 語法提示-Lint 檢查 - 構建 - 預覽 - 調試 - 打包一條龍服務

  • 平台化建設：整合。應對工具零碎、不成體系的問題，促進工具體系建設

  • 規範化開發：約束。寫法的靈活性與車間流水線協作是矛盾的，統一的開發環境能夠提供更強的約束力

這也是 ReactNative、Weex、微信小程序、支付寶小程序等特殊場景要提供專用 IDE 的原因，其一希望開發起來更方便，體驗更好；其二希望在一定程度上規範寫法，統一風格

一。預期特性

一款可用的定制化 IDE 應該具備哪些能力：

  • 基礎功能：至少要具備主流前端 IDE 的大多數能力，要能滿足碼碼的變態欲望

  • 集成能力：要能集成現有的常用工具，包括規範檢查、構建、預覽、調試、API 文檔等

  • 可擴展性：一方面應該有開放的插件生態支持、另一方面要能從容集成將來的新工具

其中，各個能力的地位分別是：

空間/發展 可擴展性
-------
種子/成長 集成能力
-------
水/生存 基礎功能

集成能力和基礎功能缺一不可，可擴展性是想象空間。因為沒有種子一切都是空談，沒有水就會迅速失去生命力，有了種子和水之後，是草還是樹取決於空間。發芽之後，水要持續不斷地滿足，所以基礎功能才是賴以生存的根本（碼的不爽，再怎麼方便我也不用）

另外，基礎功能有其特殊性，前端 IDE 的選擇一直是個口味問題，重如 IntelliJ IDEA/WebStorm，輕如 Sublime Text/VS Code，快如 NotePad/Vim，想要用一塊糖果解決這個眾口難調的事情幾乎不太可能，所以基於開源 IDE 進行二次開發似乎成了唯一的選擇，除非有個高可用的 IDE Core 包含絕大多數 IDE 基礎功能，很遺憾，暫時還沒有這種東西（Monaco 比較接近了，但還差一些關鍵的東西，比如可擴展性）

二。成熟案例

定制化的 IDE 似乎突然之間就冒出來很多，例如：

對應選型方案如下：

名稱跨平台基礎功能實現方案
微信開發者工具NWjsmonaco-editorNWjs 手搓，IDE Core 用 Monaco
支付寶小程序開發工具Electronvscode editorElectron 手搓，IDE Core 用扒來的 VS Code editor 部分
React Native IDEElectronAtomAtom 插件合集，IDE Core 就用 Atom

最初用微信開發者工具搞過事情（見 上不了線的小程序），那種碼起來束手束腳的感覺很不舒服（怎麼連個 xx 功能都沒有啊），這就是上面提到的水（當然，因為沒得選，他們不用考慮水的問題），經過這麼久的迭代，在代碼編輯、文件管理等方面似乎改進了不少，再沒有深度體驗

支付寶小程序可能同樣考慮了水的問題，所以選擇了從 VS Code 扒一個 editor 的方案，應該是費了一番功夫的

RN IDE 就粗暴得多了，拿了一堆 Atom package（插件）過來，堆出了強依賴 Flow的 IDE，還號稱：

A unified developer experience for software development

實際情況是，項目不用 Flow 的話，連個跳轉到定義都不支持

三。可選方案

可行方案無非兩種：

  • 手搓：找個 IDE Core，集成進來

  • 二次開發：找個 IDE，擴展增強

技術上需要抉擇的有 3 個關鍵點：

  • 跨平台方案：NWjs 或 Electron

  • IDE Core：Monaco 或其它

  • 開源 IDE：VS Code 或 Atom 或其它

如果是基於開源 IDE 二次開發，只需要關心用哪個 IDE，如果是手搓的方案，則需要選擇跨平台方案和 IDE Core

NWjs vs. Electron

背景

  • NWjs

    Intel 上海開源技術中心孵化的項目（最初叫 node-webkit），允許在 Node 環境創建 Webkit 瀏覽器窗體。後來從 Webkit 切換到 Chromium，並明確了 Nodejs + Chromium 開發桌面應用的發展方向

  • Electron

    Github 開發 Atom 時採用並開源的技術，與 NWjs 有些聯繫，但實現上差異很大（進程模型、Chromium 集成方式等）

差異

相同點：

  • 以前��技術棧開發桌面應用，都有成熟案例，例如釘釘（NWjs）、VS Code（Electron）

  • 技術實現上都是 Nodejs + Chromium

區別和限制：

  • 平台支持：Electron 不支持 XP 和 Vista，NWjs 支持

  • 進程模型：NWjs 是單進程模型，共享堆內存；Electron 是多進程模型，靠管道 IPC 通信

  • 源碼保護：NWjs 支持源碼保護（把源碼編譯成 V8 快照），Electron 不支持

  • 自動更新：Electron 內建支持，NWjs 社區模塊支持

  • 開發體驗：Electron 文檔比 NWjs 更優秀一些，受歡迎程度上 Electron 55.6k star; NWjs 33.1k star

其中，比較重要的是平台支持與源碼保護方面的差異

應用場景

選用 NWjs 的原因：

  • 平台要求支持 XP 或 Vista

  • 看重單進程模型共享數據的便捷，多窗體共享狀態更容易一些

  • 同構方面的好處，NWjs 自定義的部分相對 Electron 少一些，可復用更多的同構代碼（維護一份代碼，跑在桌面和 Web 環境）

  • 很在意源碼保護的場景，比如遊戲內購

選用 Electron 的原因：

  • 「純」客戶端應用，對 web 環境沒有支持計劃

  • 看重多進程模型的安全性，進程隔離

  • 社區活躍度更高，開發成本更低

Monaco

開源，且高可用的 IDE Core似乎只有 Monaco，但存在一些難以克服的問題：

  • TSX 支持程度一般，不支持 JSX 語法高亮

  • 沒有成熟的插件生態，VS Code 插件無法低成本遷移過來

JSX 語法高亮有多難支持呢？

可以查看 Does monaco support JSX ?，16 年底的問題，現在（18 年 3 月）還 open 著。因為是來自底層正則引擎的限制，無法從.tmLanguage 低成本地遷移過來，詳細見 Colorization Clarification

P.S. 那麼 TSX 是怎麼支持的，不都差不多嘛？因為 TypeScript 也是 MS 自家維護的，不支持說不過去，沒有足夠的理由的話，沒人會去做巨量的正則轉換工作

擴展機制更重要的是生態，畢竟資源有限，我們需要「擁抱」開源，而 Monaco 恰恰缺少這個，見 Integrate VS Code extensions in the Monaco editor

P.S. 幸好微信小程序沒有造出全新的東西（只是 XML，CSS，JS），否則 IDE 團隊可能會面臨巨大的工作量

VS Code vs. Atom

開源 IDE技術實現維護者受歡迎程度插件生態
AtomElectronGithub43K star插件多，但不活躍
VS CodeElectronMicrosoft42.6K star插件多，且活躍
BracketsChrome Embedded Framework（在 Chromium 之上的定制化方案）Adobe28.6K star插件多，且活躍

單從上面的對比來看，VS Code 最具優勢。但為什麼 RN 要基於 Atom 擴展而不是 VS Code 呢？

因為，VS Code 對擴展能力限制很大，比如：

  • 定制 UI 自由度很低，僅能在一些不起眼的位置加個圖標或者選項

  • 插件進程隔離，插件運行在獨立的進程環境，除了被注入的擴展 API 外，根本摸不著 IDE 主體，意味著沒有 API 就做不了

而 Atom 恰恰相反，沒有進程隔離，允許深度 UI 定制，插件 API 都是相對底層的，不像 VS Code 只提供高度封裝的，從擴展成本來看，Atom 相當有優勢

P.S.Atom 剛推出時，性能為人詬病，給大家留下了不太好的印象，但日常使用貌似也足夠，沒那麼慢

四。抉擇

決策樹如下：

[caption id="attachment_1678" align="alignnone" width="625"]定制化 IDE 方案決策樹 定制化 IDE 方案決策樹[/caption]

5 種可行方案優缺點對比如下：

方案簡述缺陷優勢
A）基於 VS Code 二次開發VS Code 插件開發 + 盡量小修改源碼UI 定制成本高
插件能力受到嚴格限制
UI 定制型插件極少		插件市場活躍度高
代碼編輯體驗好
啟動性能高，插件按需加載
容易擴展，如 Vue 或更新的前端生態產物支持
B）基於 Atom 做二次開發Atom 插件開發 + 盡量小修改源碼核心 API 薄弱
插件能力不受限，質量沒有保證
插件市場活躍度低，後期維護成本大
代碼編輯體驗略差		UI 定制容易
插件能力不受限
UI 定制型插件很多，前期開發快
容易擴展，如 Vue 或更新的前端生態產物支持
C）修改 RN IDE純 Atom 插件開發強依賴 TypeScript、Flow
JSX 支持度不高，增強成本低
啟動性能略差		應用場景類似，實現細節都可借鑑，無技術風險
現成的 UI/交互，不用專門投入
D）Monaco + NVS Code IDE core + Electron 開發手動實現，穩定程度沒有保障
不支持 JSX，增強成本很高
TSX 支持程度不高，增強成本很高		去中心，靈活性高
開發成本比 ABC 高
E）alm + NVS Code IDE core 增強 + Electron 開發手動實現，穩定程度沒有保障
JSX 支持程度不高，增強成本很高		去中心，靈活性高
開發成本比 ABC 高，比 D 低

綜合來看，真正可行的只有 A 和 B，進一步的選擇就要考慮工作量與可用資源了：

  • 排期/關鍵時間節點：項目時間跨度，以及 Alpha、Beta 時間點

  • 人力/戰鬥力：幾人參與，能否並行，以及戰鬥力是否達標

  • 技術棧熟悉程度：上手後能否保證正常進度

  • 實際工作量：工作量是否溢出

假設只有 1 人月，那麼選 B，沒什麼風險，因為 B 是大前期，能迅速出東西，但將面臨後期打醬油的問題

如果有 2 人月，可以嘗試選 A，低風險，因為 UI 定制成本是個不確定因素，影響前期進度，可能導致 Alpha 等靠前的時間節點壓力較大，但大後期有絕對的發展優勢

五。經驗

從 0 到 1

把大象裝進冰箱需要 3 步：

  1. 首先明確種子與水各是什麼

  2. 接下來選一顆有想象空間的好種子

  3. 最後源源不斷地供水

種子與水缺一不可，極端條件下，種子 > 水 > 空間

立足實踐

過程中犯了 2 個錯誤：

  • 因為一句話，臨時調整方案。後果是 3 天白做 + 2 天返工

  • 任務分配不合理，合適的人沒有去做合適的事情。後果是浪費 2 天調研 + 2 天進度滯後

面對權威壓力，不應該動搖理性的判斷力，tell me why，我們擺事實講道理。對戰鬥力的判斷應該基於此刻事實，而不是以往經歷，只有真真切切地面對問題時，真實的戰鬥力才會展現出來

這一套東西，NB 在哪裡？

切換視角

反向推動能力

他們的電腦上可是什麼都沒有

結果之外的東西，有些時候與結果本身一樣重要

評論

暫無評論，快來發表你的看法吧

提交評論