カスタマイズ IDE 選定ノート

零.なぜカスタマイズするのか？

IDE のような巨大なブラックボックスの一角をめくり上げて、深層カスタマイズを企てるのは、それは本当に愚かに見えます。プラグインを書くだけではダメなのでしょうか？このようにする主な理由は 2 つあります：

より高い柔軟性：拡張機制の制限を受けず、既存機能のカスタマイズでも新機能の拡張でも実現可能です
より細かい制御粒度：深層の二次開発により、細部まで完全に制御可能で、細粒度のカスタマイズニーズを満たせます

実際、柔軟性収益の多少は拡張機制の制限程度に依存します。プラグイン機制が完全に開放されていれば、二次開発による柔軟性向上はそれほど必要ではありません。例えば Atom の拡張機制はほとんど制限がなく、プラグイン機制だけで完全に新しい IDE を作成できます。例えば Nuclide

制御粒度はカスタマイズ能力に重点を置き、例えばテーマスタイル、UI レイアウト、構文拡張などです。二次開発はプラグイン機制がカスタマイズを許可しない部分をサポートでき、アプリケーション名/アイコンから UI レイアウト/インタラクション操作まで様々です

一方、ニーズシナリオから見ると、専用 IDE にはいくつかの利点があります：

ワンストップツール：統合。葫蘆小金剛の感じで、他の 7 つの娃のすべての能力を持ちます
没入型体験：接続。ツールチェーンを有機的に組み合わせ、スキャフォールディング - 構文ヒント -Lint 検査 - 構築 - プレビュー - デバッグ - パッケージングのワンストップサービス
プラットフォーム化建設：整合。ツールの細分化、体系化されていない問題に対応し、ツール体系建設を促進
標準化開発：制約。書き方の柔軟性と车间流水线協力は矛盾し、統一された開発環境はより強い制約力を提供

这也是 ReactNative、Weex、微信ミニプログラム、支付宝ミニプログラムなどの特殊シナリオが専用 IDE を提供する理由です。1 つ目は開発をより便利にし、体験をより良くすること。2 つ目は書き方をある程度標準化し、スタイルを統一することです

一.予想特性

利用可能なカスタマイズ IDE はどのような能力を持つべきか：

基本機能：少なくとも主流フロントエンド IDE の大多数の能力を持ち、コーディングの変態欲望を満たせる必要があります
統合能力：既存の常用ツールを統合できる必要があります。規範検査、構築、プレビュー、デバッグ、API ドキュメントなどを含みます
拡張性：一方では開放的なプラグイン生態サポートがあり、他方では将来の新しいツールを落ち着いて統合できる必要があります

その中で、各能力の地位はそれぞれ：

空間/発展 拡張性
-------
種子/成長 統合能力
-------
水/生存 基本機能

統合能力と基本機能はどちらも欠かせず、拡張性は想像空間です。種子がなければすべて空論で、水がなければ迅速に生命力を失います。種子と水があれば、草になるか木になるかは空間次第です。発芽後、水は継続的に供給する必要があるため、基本機能こそが生存の根本です（コーディングが不快なら、どんなに便利でも使いません）

さらに、基本機能には特殊性があります。フロントエンド IDE の選択は常に趣味の問題で、IntelliJ IDEA/WebStorm のような重厚なものから、Sublime Text/VS Code のような軽量なもの、NotePad/Vim のような高速なものまで、1 つのキャンディーでこの衆口難調の問題を解決するのはほぼ不可能です。そのため、オープンソース IDE を基に二次開発するのが唯一の選択のように思えます。高可用な IDE Core が大多数の IDE 基本機能を含む限り残念なことに、暫時そのようなものは存在しません（Monaco は比較的近いですが、拡張性などの重要なものがまだ不足しています）

二.成熟事例

カスタマイズ IDE は突然たくさん現れたようです。例えば：

対応選定方案は以下の通り：

名称	クロスプラットフォーム	基本機能	実装方案
微信開発者ツール	NWjs	monaco-editor	NWjs 手搓、IDE Core は Monaco を使用
支付宝ミニプログラム開発ツール	Electron	vscode editor	Electron 手搓、IDE Core は VS Code editor 部分を剝がして使用
React Native IDE	Electron	Atom	Atom プラグイン合集、IDE Core は Atom を使用

最初に微信開発者ツールで事を搞しました（上不了線的小程序参照）。あのコーディング時に手足が縛られるような感觉はとても不快でした（どうして xx 機能さえないのか）。これは上で述べた水の問題です（もちろん、選択の余地がなかったので、彼らは水の問題を考慮する必要はありませんでした）。これだけのイテレーションを経て、コード編集、ファイル管理などの面でかなり改善されたようです。再度深層体験はしていません

支付宝ミニプログラムもおそらく水の問題を考慮したため、VS Code から editor を剝がす方案を選択しました。おそらく一苦労したでしょう

RN IDE はもっと乱暴で、Atom package（プラグイン）をたくさん持ってきて、Flow に強依存する IDE を積み上げました。さらにこう主張しています：

A unified developer experience for software development

実際の状況は、プロジェクトが Flow を使用しない場合、定義へのジャンプさえサポートされません

三.選択可能方案

実行可能方案は 2 種類しかありません：

手搓：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 より少なく、より多くの同構コードを再利用可能（1 つのコードを維持し、デスクトップと 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	技術実装	メンテナンス者	人気度	プラグイン生態
Atom	Electron	Github	43K star	プラグインは多いが、活発ではない
VS Code	Electron	Microsoft	42.6K star	プラグインは多く、かつ活発
Brackets	Chrome Embedded Framework（Chromium 上のカスタマイズ方案）	Adobe	28.6K star	プラグインは多く、かつ活発

上記の対比のみから見ると、VS Code が最も優勢です。しかし、なぜ RN は VS Code ではなく Atom を基に拡張したのでしょうか？

VS Code は拡張能力の制限が非常に大きいためです。例えば：

UI カスタマイズの自由度が非常に低く、目立たない位置にアイコンまたはオプションを追加するのみ
プラグインプロセス隔離。プラグインは独立したプロセス環境で実行され、注入された拡張 API 以外では IDE 主体に全く触れられません。API がなければ何もできないことを意味します

Atom はまさに逆で、プロセス隔離がなく、深層 UI カスタマイズを許可し、プラグイン API は比較的底層的で、VS Code のように高度にカプセル化されたもののみを提供するのとは異なります。拡張コストから見ると、Atom は相当優勢です

P.S.Atom が剛推出された時、パフォーマンスは人から非難され、あまり良くない印象を残しましたが、日常使用では十分で、それほど遅くありません

四.決断

決定木は以下の通り：

[caption id="attachment_1678" align="alignnone" width="625"] カスタマイズ 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 + N	VS Code IDE core + Electron 開発	手動実装。安定程度保証なし JSX をサポートせず、強化コストが非常に高い TSX サポート程度が高くなく、強化コストが非常に高い	脱中心。柔軟性が高い開発コストは ABC より高い
E）alm + N	VS Code IDE core 強化 + Electron 開発	手動実装。安定程度保証なし JSX サポート程度が高くなく、強化コストが非常に高い	脱中心。柔軟性が高い開発コストは ABC より高く、D より低い

総合的に見ると、本当に実行可能なのは A と B のみです。進一步の選択は作業量と利用可能資源を考慮する必要があります：

排程/重要な時間ノード：プロジェクト時間跨度、および Alpha、Beta 時間点
人力/戦闘力：何人参加、並行可能か、および戦闘力が达标しているか
技術スタック熟悉程度：着手後正常な進度を保証できるか
実際作業量：作業量が溢出しているか

1 人月のみと仮定すると、B を選択。リスクはほとんどありません。B は大前期で、迅速に物を出せますが、後期に酱油を打つ問題に直面します

2 人月あれば、A を選択可以尝试。低リスク。UI カスタマイズコストは不確定要因で、前期進度に影響し、Alpha などの靠前の時間ノードに圧力が大きくなる可能性があります。しかし、大後期には絶対的な発展優勢があります

五.経験

0 から 1 へ

象を冷蔵庫に入れるには 3 ステップ必要：

まず種子と水がそれぞれ何かを明確
次に想像空間のある良い種子を選択
最後に絶え間なく供水

種子と水はどちらも欠かせず、極端条件下では、種子 > 水 > 空間

実践に立足

過程で 2 つの間違いを犯しました：

一言のため、臨時に方案を調整。結果は 3 日無駄 + 2 日手戻り
タスク分配が不合理。適切な人が適切なことをしなかった。結果は 2 日調査無駄 + 2 日進度遅滞

権威圧力に直面し、理性的判断力を揺るがすべきではありません。tell me why。事実を並べて道理を説きます。戦闘力の判断は此刻の事実に基づくべきで、過去の経験に基づくべきではありません。真真切切に問題に直面した時だけ、真实的な戦闘力が現れます

この一揃いのもの、NB はどこにある？

視点切換

反向推進能力

彼らのパソコンには何も入っていない

結果以外のもの。ある時は結果自体と同じくらい重要です