作者 | 上坡
在 19 年 5 月，由跨阿裡巴巴經濟體的 3 個前端團隊組織在一起，經過一年的努力，産出了 IDE 的底層實作- KAITIAN 架構。與此同時，借助 KAITIAN 底層能力，體系内、外的研發場景也陸陸續續建設起來。在 IDE 架構完成了一些業務實踐之後，我們對 KAITIAN 帶來的研發場景下的業務價值以及發展的方向也有了更多的思考。
冰山一角
在經濟體體系内，許多研發體系、平台借助 KAITIAN 底層，通過 KAITIAN 插件等方式将零散的研發模式進行了統一，将原有研發工作中的研發态與部署态、本地端與線上端的流程進行內建，在面向流程更流暢、環境更統一的研發鍊路上提供了進一步更好的選擇。
業務場景概覽
通過研發平台的內建，KAITIAN 底層間接打通支撐了諸如 支付寶小程式、營銷搭建、中背景、Node FaaS 等垂直場景的研發，同時針對更加通用的例如 代碼稽核、沖突合并 等場景，借助底層能力，在體驗、效率上也較原有鍊路有一定程度的提升。
在基礎研發體驗上，我們也陸陸續續內建驗證了 100+ 的 VSCode 生态 插件，在基礎研發體驗上得到基本保障。
在 KAITIAN 項目建設之初，我們希望能通過靈活的插件機制，在相容 VSCode 生态的同時，能将經濟體前端研發生态内不斷在發展和孵化出來的研發工具、服務進行承載，有機的串聯起來整個鍊路，發揮出各個工具、服務的最大作用、價值。
垂直場景研發
例如針對電商體系下的營銷頁面研發，将 D2C 能力平台 imgcook 進行結合，在雙促中大幅提升頁面的生産效率，通過 D2C 能力進行 70% 的代碼編寫工作，在編輯器中進行調整加工後，點選立馬上線。相比之前的流程大幅提高生産效率。
在體系外，經過支付寶小程式研發同學的不懈努力，小程式開發者工具 也完整紮實地跑在的 KAITIAN 底層架構之上，同時借助 KAITIAN 兩端一緻的能力，也在短時間内完整孵化出來線上環境的 小程式線上開發平台。
通過将這些功能根據使用頻率、重要優先級進行組合，讓研發工具不隻是編碼工具，而是真正成為一個研發空間，讓使用者像飛機機長一樣，快捷觸達、操作各個研發功能，提升研發的連貫性，組成表現一緻的研發上下文，形成統一的研發産品體驗，最終達到提升研發效率。
同時将小程式研發中的 模拟器、調試器 等能力通過 KAITIAN 插件進行封裝，實作本地平台與線上平台的同步一緻。借助底層架構一緻，這些研發工具服務，也已經在内外的各個 KAITIAN 底層平台上進行內建，定制出更符合各自團隊的研發鍊路。
在阿裡雲上， 阿裡雲雲開發平台 也在緊鑼密鼓進行建設和開展訓練營，通過整合雲上研發解決方案的方式，基于 KAITIAN 體系提供針對 serverless、iot 一站式研發模式。
體系沉澱
在支撐業務的同時，我們也将內建業務的過程中遇到的問題進行總結沉澱。例如針對 Web 場景下，內建依賴基礎設施較多的情況，我們将 容器排程、資源政策、架構內建 等環節進行抽象內建，提供具備租戶式建立 IDE 能力的 WebIDE 中台，通過租戶申請，10分鐘之内提供一個可定制的 IDE 內建環境；同時針對插件研發，我們也逐漸沉澱出研發 元件庫、模闆庫、研發插件 等插件研發基礎設施。
去年一年，随着 KAITIAN 底層技術的誕生，這塊技術也随着業務場景不斷在往前，一方面我們逐漸觸達到了項目設定到的表面上的具體目标，而針對共建業務深層次的問題，也逐漸浮現出來。
冰山之下
作為開發人員，IDE 就像工作中的最佳拍檔，伴随着大部分工作時間。我們同樣也希望 KAITIAN 體系能從底層能力角度做好這個角色。于是在業務不斷發展的同時，我們也在不斷思考目前體系中所要解決和面臨的一些問題。
底層能力
目前 KAITIAN 底層從業務的內建角度來看待，可以作為一個前端采用 React、後端采用 NodeJS 技術的前後端的完整應用。在這樣的內建方式架構下，一些在使用過程中的問題也随着業務上的實踐逐漸凸顯出來。
基礎性能
KAITIAN 在最初建構的時候，選擇了 React 來進行前端頁面的開發，同時基于 mobx 來實作頁面中的狀态管理。那麼在傳統前端 SPA 遇到一些例如視圖、節點更新，渲染執行效率的一些問題，在随着不斷提升的使用者數量的同時，也在 KAITIAN 上層平台中暴露出來。例如界面渲染中的拖拽場景，對于單邊觸發多邊關聯觸發更新的場景，都是在當下界面渲染中正在不斷優化的部分。
同時在研發流程中的文法提示服務、項目研發部署日志、遠端終端等一些前後端關聯的功能都需要前後端頻繁的互動。在 KAITIAN 的底層實作中，在 web 環境下借助 websocket 協定、本地借助 socket 協定的方式進行前後端通信。那麼在 web 網絡通信的環節過程中，相比本地環境通信的能力差距，我們需要盡可能保證傳輸的高效率。例如如果當使用者輸入一個字母的時候，如果文法提示的資訊多等了 1 秒才出現，整體的體感差别是比較大的。
對于上述兩個點以及其他方向的底層性能打磨，一方面通過結合日常前端應用的性能優化政策進行驗證優化，另一方面嘗試采取更好的實作方式來達到更佳的體驗效果。
前後端解耦
目前 KAITIAN 底層作為前後端完整應用內建方案，能快速地內建出一個 Web 版本或者 Electron 版本的前後端應用。這樣對于一個工程研發平台快速內建 IDE 研發能力本身是個快速簡便的解決方案。
但随着在業務的落地過程，對于一些弱環境依賴的輕量研發場景以及在後端能力上的實作有着自有後端體系的實作的場景仍存在模式優化的空間。例如 codesandbox 這類研發場景，對于檔案的操作上，不需要對外部情況變更進行監聽以及也不存在檔案磁盤的讀寫，基本主要依靠資料庫操作，但同時具備一些研發中例如文法提示的支撐能力。
這樣的研發模式在 簡便易用 與 能力完善 之間找到一個最佳平衡點，在一些特定場景中實作最佳研發體驗。
對于這樣的場景，目前 KAITIAN 底層也在逐漸進行改造支援。在 KAITIAN 底層設計之初本身是通過 TS 來實作 面向 接口Interface 程式設計，存在着軟體依賴之間天然的抽象隔離，那麼我們通過将子產品實作之間，子產品的前後端實作之間進行進一步抽象化，完成前後端、子產品間的解耦。目前其中的部分子產品已經單獨服務到這類的研發場景中，接下來也會逐漸整理産出在這個領域場景中最佳實踐。
對于架構底層性能及其他能力來說，作為研發編碼能力和體驗的底層支撐，對底層子產品的品質優化是一個長期優化、不斷跟進、沒有終點的過程。在業務演變的同時，緊貼業務的場景和使用者的研發要求，以實際場景為目标，做好 IDE 底層體系能力的基礎保障。
插件體系
在基礎的架構能力之上，我們期望 KAITIAN 插件體系能作為未來研發模式的一艘航母，能具備承載目前和未來絕大多數的主流研發模式的能力。在插件機制實作之初，我們打通了 Node/WebWorker/UI 三個環境來最大化插件的拓展場景。在業務實踐過程中，我們也發現在插件運作的不同角度下，也有着更深度的業務需求和發展空間。
API
針對當下研發 IDE 豐富完善的功能體驗，以及面向整個阿裡經濟體體系下前端域紛繁複雜的研發工具、服務生态。在 KAITIAN 啟動之初，我們就期望能在插件運作環境上下文中，能提供完善的插件 API 調用及基礎能力。
一方面通過相容 VSCode 體系下的插件 API 來實作對研發過程中基礎研發體驗能力的補齊，能一樣擁有完整的 LSP 語言服務協定、DAP 調試适配協定等核心機制的完整實作，具備完善可擴充代碼提示、斷點調試等能力；在另一方面，我們還需要解決研發過程中全鍊路工具、服務的串聯內建，串聯整個項目的生命周期，借助在 KAITIAN 插件體系下拓展 WebWorker、UI 環境以及在環境中提供的能力，來實作體驗更順暢、自然的研發模式。
而看似完備的環境，在業務實踐過程中，也存在着一些我們需要不斷深化、完善的基礎體系能力。
API 粒度控制
KAITIAN 最初始建設的一套相容 VSCode API 的插件體系，在實際業務的"摸爬滾打"中，我們發現對于這塊基礎 API 的使用上，還需要在粒度上進一步地做分層。例如從原有 VSCode 相關 API 的角度出發，期望一方面降低原有在 VSCode 插件研發現有較高的門檻，另一方面在深度的能力上進一步提供更多的能力，滿足、促進研發模式的孵化需求。
例如目前針對以往指令行 CLI 的工具，在 KAIIAN 插件中存在着的建立終端面闆執行的場景，按照現有 VSCode 插件 API 的實作，需要經曆 3 步：建立終端、發送終端指令、顯示終端。實際發現很多使用者會直接将這個常用操作封裝成一個例如 Terminal.run 這樣的方法來友善調用。在這個層面上，我們也在着手針對底層能力的一些合并調用、組合調用從更體系化地角度進行更适當粗力度的封裝，這樣使用者可以在功能實作上，就能盡量降低底層功能細節的關注，提高研發效率，更專注到業務邏輯的開發上。
一方面是方法進一步的抽象封裝，在另外一方面，例如在 VSCode 的 task 指令空間的插件 API 實作中，暴露給使用者的 API 數量在一些場景中無法滿足，但實際使用者在一些指令任務執行時序節點需要一些更多資訊的擷取、傳遞。這塊我們在這個場景下進行更細粒度的補充透出。
在原有的 VSCode 插件 API 的粒度和開放上我們通過粗細力度的完善，逐漸優化 VSCode 能力體系插件的研發體驗，幫助使用者降低門檻，提效插件研發。
業務上下文
因為我們期望 KAITIAN 能在經濟體橫向範圍内具備足夠的通用性，是以在實踐設計之初，業務層的内容其實更多期望在業務內建側解決，底層實作完全的隔離。但是在實際業務內建的過程中，業務需要透傳一些業務上下文的資訊到插件的運作調用中，例如應用之間調用的 令牌資訊、使用者登入資訊、目前研發應用資訊、目前環境網絡資訊 等等。
在這樣需求之初，內建方通過同樣并行實作一個底層子產品邏輯，平行的将內建側的互動資訊通過與底層實作一緻的方式透出到插件環境中。這樣的方式能解決當下業務上的問題，但在背後其實仍然存在着遺留的問題。
- 研發門檻&維護成本: 對于通過內建底層子產品的方式來注入業務上下文，無論是門檻和內建方式都無法得到有力的保障，一方面內建側的使用者需要對底層架構子產品實作有着一定程度的了解，這就對整體的內建門檻有一個不小的提升，另一方面對于底層不同的了解會産生不同的內建思路，具體到代碼實作上的形式也變得不可控起來，對于後期的更新維護産生更多的成本。
- 依賴描述: 目前這些通過內建側注入到運作上下文的業務資訊，在一定層面上其實也形成了插件本身運作的依賴，通過"非官方"的注入方式，無法将這部分的插件依賴進行管理起來，那麼則無法對插件依賴進行準确的描述。一個插件如果存在業務環境上下文的依賴，但同時無法進行的準确的描述，那麼插件生态天然就多了一道屏障，無法形成互通體系。
在當下我們逐漸開開始從內建側角度，建立上層的 注入上下文 的實踐層規範，提升內建側的內建效率、體驗，同時保障插件自身的環境依賴可描述，保障插件生态互通。
KAITIAN API 體系
在 KAITIAN 插件機制中，我們有參考小程式架構實作 UI 環境與 WebWorker 、Node 環境的方法服務注冊與遠端調用能力，同時本身在 UI 與 WebWorker 環境中，我們也逐漸在建設 KAITIAN 插件體系下 API 能力。
UI 環境代表的是 IDE 整個前台界面的運作環境。例如我們期望對于上下左右面闆的控制、對于左右、底部 Tab 切換的控制以及對于自定義元件在不同插槽位置的注冊渲染等能力，都需要依賴在底層能力通過插件 API 的方式進行透出，保障插件在 UI 界面上的控制場景需求。
同時我們期望 WebWorker 環境在能承接業務邏輯的同時，更能逐漸在未來承擔起目前在 Node 環境中的能力，降低對後端資源的消耗和依賴，目前對指令、語言、生命周期控制等基礎能力的依賴，也逐漸在 WebWorker 環境中進行建設和透出。
依托插件具體的運作環境，提供不同環境的 API 體系抽象，保障業務邏輯在插件環境中的承接。
UI
面向前端研發的 IDE 插件體系，我們期望能天然借助 React 元件能力進行對業務邏輯的表達。在這塊 UI 元件領域中，看似對于前端來說非常熟悉的 React 體系，在業務實踐過程中我們也逐漸沉澱出一套适合插件 UI 環境的技術體系。
沙箱能力
在插件 UI 實作流程中，一方面由于前端 UI 實作的簡易邊界，沒有限制，我們很容易通過樣式、标簽進行界面的組織，另一方面由于當下前端環境下豐富的類庫、元件，開發者往往也會直接依賴一些開源元件來提升開發效率。簡易的實作路徑同時也容易産生 UI 元件之間互相影響。例如目前在實踐過程中，我們發現往往會因為插件 UI 中因為引入 AntD 元件的方式有誤，導緻了對整體界面全局樣式的污染。
目前我們也在逐漸借助 WebComponent 能力進行對插件渲染進行一定的容器控制，建設渲染容器的沙箱機制。将插件注冊的元件通過 ShadowDom 的方式進行控制，屏蔽掉對整體界面渲染影響。同時我們注意到原有 VSCode 插件中的 treeview 等元件布局的 序列化渲染 實作方式，也不斷在放大資料化渲染的應用場景，通過提供官方的 UI 模闆等實作形式，插件使用者隻需要進行對應的 UI 實作配置，在完成業務邏輯實作的同時，保障 UI 實作的穩定性。
在進一步，針對 JS 對環境的影響以及執行控制，目前也在參考現有社群的方案實作，逐漸驗證探索 Worker、Realm、QuickJS 等方案，在為插件開發者搭建一個自由發揮的舞台同時，建設一個堅固穩定的渲染環境。
物料體系
在 IDE 插件中的 UI 研發其實與日常開發背景頁面沒有實質的差別，對于中低複雜度的場景，在實踐過程中我們發現如果讓使用者從原子的标簽開始研發，一方面整體的實作過程需要較多基礎研發成本，另一方面在最終實作效果上，可能也無法與上下環境中的主題、樣式風格等基礎 UI 元素保證一緻。
可以從一定的角度上來了解，在 IDE 視角下的 UI 開發，可以類比于日常的中背景場景研發，具備一定的相似性。如何豐富使用者的研發手段，建設高效的研發流程，同時保障最終效果的高品質輸出可以類比在中背景場景中的實踐。
我們在架構建設的中期，開始将 IDE 體系内的 UI 能力進行抽象收斂，産出 IDE 工具領域下的視覺元件，在底層架構複用的同時，也在插件 UI 環境下進行透出。通過這樣的方式，在 IDE 插件研發的場景中，可以起到幾個比較好的作用。
- 研發效率提升: 從封裝的基礎元件研發，能快速完成鍊路産品原型搭建，在非深度業務場景下，作為基礎的研發體驗保障之一
- 視覺一緻性保障: 由于元件本身由 IDE 場景中孵化，在視覺語言表達上，會消除掉在使用其他 UI 能力時，不同 UI 體系導緻的視覺展現混亂、幹擾的情況，最終呈現到插件使用使用者上的操作體感上有了保障基礎
- 渲染穩定性: 實作 UI 元件對于目前插件同學來說容易，但是 UI 環境本身是一個較脆弱的環境，通過官方的元件實作，最大限度的降低因為業務邏輯導緻的頁面異常、甚至死循環卡死的情況
在借鑒元件體系建設之上，在業務實踐過程中，我們仍然在思考如何再進一步降低研發成本的同時，保障運作環境的高效穩定，以及在深度定制下的最佳實踐規範。
從基礎元件向上的視角，使用者在面臨界面中的插槽面闆的時候，基于基礎元件實作高階的 組合元件、布局模闆，在能适配更多研發鍊路下的布局需求的同時，依然能享受到元件帶來的基礎體系保障。在上層封裝中也逐漸孵化出更多資料配置化的序列化 UI 實作，盡量控制在 UI 基礎實作上的投入的同時，通過資料模型進行對 UI 的控制，進一步在投入與産出中找到"黃金分割"的方案。
從基礎元件向下更深度的視角，我們也逐漸建立起來提供給插件體系的主題變量 TOKEN 等更細粒度的物料體系，保證在一些複雜場景下的 UI 實作也依賴能最大限度與上下文環境保持一緻體驗。
插件生态
KAITIAN 除了底層架構實作，我們在設計之初期望通過官方提供的插件市場，來擔當插件生态的中心承接點，作為基礎源以點帶面的進行插件的上架管理、安裝更新、通路權限等基本服務功能支撐。對于不同上層業務方，可通過基于基礎源的方式進行上層業務控制。
在這樣的一個分層體系的業務實踐過程中，通過基礎插件市場提供的分組管理體系，能很好的解決掉業務間可能存在的幹擾影響場景。但對于更深度的業務邏輯、能力擴充，需要借助其開放能力進行豐富。
例如在某一上層業務上層場景中，我們需要對使用者使用的插件的版本進行灰階等管理應用，同時需要将插件的執行穩定性依托監控體系，進行穩定性的治理，比對團隊工程研發服務的品質标準。
在這樣的場景下，目前我們也逐漸将中心插件市場的能力進一步下沉和抽象，在保證基礎插件研發鍊路的同時，進一步完善開放體系，将底層無直接關聯的業務邏輯分攤到上層的實踐平台中。一方面越清晰簡化的底層越能最大化地保證底層核心的穩定性，具備服務更大場景的基本能力；另一方面對于上層各個業務場景，也能在無關聯影響的實作環境下，最大化的保證上層邏輯細節，更好的服務上層的業務研發場景。
KAITIAN 插件體系這塊作為 KAITIAN 體系中最重要的部分之一，我們也在陸陸續續從 插件研發 的視角下建設最優鍊路；在 穩定性 上逐漸建設監控、容錯的能力；在 性能上 尋求實作上的優化和突破。作為業務邏輯的基礎容器，期望在穩定性、性能基礎之上，結合業務鍊路上的催化，實作未來研發模式的基石。
業務上的探索與思考
對于當下 IDE 視角下的研發模式，我們概括為 通過 IDE 內建研發鍊路中的工具、服務以及流程，發揮鍊路整合優勢的背景下，形成新的研發模式。在這樣的主題下，在業務實踐過程中也遇到一些比較典型的例子。
鍊路內建
場景示例
在電商營銷活動研發場景中，搭建作為最核心的研發模式，日常研發主要進行對 UI 單元子產品的研發，完成頁面基礎元素的生産。在這個體系下，我們将 編譯預覽、 D2C 代碼視覺稿還原能力、工程部署上線 等幾個核心鍊路內建。使用者從原有的在各個平台操作、代碼逐行實作變成了基礎 UI 機器生成，人工代碼稽核校驗，一鍵上線的流程。在該場景的 UI 實作上大幅節省研發投入，在較大範圍的使用者上得到認可，也完成了包括雙11、雙12等較多核心大促場景的驗證。
在同樣火熱的 serverless 場景中，例如以阿裡雲上場景 雲開發工作台 為例，目前雲上環境中存在着浩如煙海的産品、服務。在一些場景下誇張的講，代碼隻是應用上線 10 個步奏的其中 1 個步奏，從産品服務的了解，到技術方案的設計，到最終上線部署的流水線搭建，每個環節可能都是精力投入成本。
在這樣痛點背景下，面向具體業務場景，設計整合解決方案，同時在 IDE 的上下文中借助插件實作的 部署面闆、日志面闆、調試驗證面闆 等功能子產品，聚集雲上的的能力，形成組合體系，讓使用者能快速、準确最優化地實作業務邏輯的同時，真正借助研發模式上的設計來提升研發體驗，同時打通在業務上的賦能管道。
使用者價值
IDE 作為日常研發最高頻的使用軟體，在一定角度上也是使用者要求最高的使用軟體。從前文提到的場景中，表面上看是基于 IDE 的模式來建設研發鍊路，實際上其中一個本質是從使用者視角下分析當下研發流程的痛點，借助 IDE 的方式來解決研發痛點。例如營銷場景中的 UI 研發的低效率、支付寶小程式場景中的 能力複雜分散 以及在 serverless 場景中的 鍊路繁瑣模糊。
對于新的 IDE 研發模式，本質我們需要做到在不斷提升底層基礎品質的同時，進一步挖掘使用者的研發痛點，從研發工具、服務的整合做到 有效的 研發工具、服務的整合。在工具庫豐富的同時，需要對每個問題庖丁解牛，用最合适的方式拿出最合适的工具來解決問題。例如在如今較為常見的多頁面前端應用，往往在調試過程中提供一個預覽路由頁面，使用者就從挨個頁面連結拼寫變成了直接點選，直接從次元上大幅降低使用者在不同頁面研發、調試之間的操作成本。
IDE 研發範式-全鍊路研發模式
在陸陸續續接入一些業務場景之後，我們思考在面臨後續更多研發模式的接入，是否存在一定的 範式。我們本身建立 IDE 項目，初心是期望借助 IDE 的體系，在内外研發能力的互通的背景下，來帶來模式上的變化，提效研發。那麼其實從 研發模式 出發，本質不是隻有 編碼環節、調試環節。研發模式需要關連整個研發鍊路來一同設計，從項目的初始化、項目的架構方案的設計，以及對項目應用架構針對性的工具、服務設計，以及到最終的應用部署上線，從一個項目的完整生命周期來設計，可能就是所謂的 研發範式。
從 項目架構選型、初始化流程、面向架構研發工具服務、上線部署流程，作為 IDE 研發模式的設計骨骼架構來設計和填充，讓一個項目在研發使用者手上借助 IDE 體系能力來完成，最終引導出研發模式上的量變到質變。
在當下在業務體系實踐在場景上，除了從複雜的例如 Antd、Egg 體系應用研發到輕量的代碼稽核、沖突合并場景不斷找到使用者價值，借助 IDE 的能力重新設計、定義研發流程這樣的使用者角度。同樣在團隊視角下的資料體系，我們借助 IDE 的基礎能力可以無死角地深入到使用者的全操作流程中統計資料、資訊，作為當選團隊的架構方案、工具服務的分析改進基礎。在技術落地上，我們期望通過多個位置的換位多角度思考，穩步營造、推進研發模式的變化。
仰望星空
KAITIAN 起源于經濟體體系内多個前端團隊的共同建設，目前除了基礎的前端研發場景。在業務上層也在後端、用戶端等研發場景中逐漸驗證，借助語言服務機制實作對 python、java、groovy、c++ 等語言的支撐。同時目前開源工作也在緊鑼密鼓的進行中，期望在未來能将其中的一些最佳實踐，通過開源的方式進行分享以及社群的驗證和打磨。
關注「Alibaba F2E」
把握阿裡巴巴前端新動向