随着前端開發的發展更疊，前端日常開發工作變得愈發複雜愈發深入，同時前端工程中從項目初始化、編譯、建構到釋出、運維也變得細化而成熟。日常前端工作的每個環節都湧現出豐富的工具、服務和解決方案來解決工程效率的問題。那麼，前端工程化的下一階段的突破口是什麼，我們期望通過 IDE 的方式和視角來找尋答案。
行業分析
行業趨勢
其實 IDE 本身不是一個新興的概念，在維基百科上能找到第一款的 IDE 是來自 55 年前為 BASIC 語言提供研發能力的一款
軟體工具，而最近的一到兩年時間内，IDE 的業内動态突然呈上漲趨勢。
從外部視角來看，可以看到有兩個趨勢浮出水面，一個是 IDE 領域相關的創業公司逐漸浮現出來，出現了許多相關的創業明星公司：
- 起初由前端腳本編譯項目到現階段容器化能力支撐編譯服務能力、不斷突破倍受好評的 codesandbox 平台；
- 出自 Eclipse 研發老牌團隊研發，目前被各大公司、廠商，包括谷歌計算服務(GCP)采用 theia-ide 解決方案；
- 以及号稱相容 VSCode 程度最高的 coder 項目；
除此之外還有很多小而美的 IDE 落地場景，如 RN 研發明星産品
expo的配套雲端工具，發展成 npm 官方配套的
runkit平台。
另一個趨勢是雲廠商市場上巨頭的投入也開始增加：
随着 AWS 完成對老牌雲端 IDE 工具 Cloud9 的收購之後，國内騰訊雲也完成對 Coding 的戰略投資，而近期也完成對 Coding 公司收購。而近期微軟也拿出了自己的解決方案，推出了雲端版本的 VSCode。
從阿裡體系視角來看，與內建研發環境相關的工具平台也在這段時間周期内如雨後春筍湧現出來：
随着近年不斷發展的支付寶小程式、函數服務、中背景、智能化等前端技術的發展，在不同前端技術方向，都湧現出了通過內建研發環境的方式來整體研發過程中的工程工具服務，來提升整體研發的效率和體驗。
起因分析
面對目前的趨勢，為了更好地到 IDE 共建的研發落地思路，我們從 業務側、技術側兩個角度來分析内在的起因。
業務側
業務鍊路承接: 針對許多與研發強相關相關的如小程式、函數計算等場景，技術産品鍊路背後都有一個完整技術、産品體系需要一個承接主體，來完成對産品功能、資訊、能力的傳達。通過日常研發人員熟悉的 IDE 形式，将各個研發體系中的關聯功能進行內建，向使用者透出。通過內建方案降低開始成本與門檻，提高品牌、産品的觸達效率。
體驗效率更新: 随着工程化的發展，代碼研發模式也從較單一的編輯工具編輯延展到 終端指令、本地工具、線上研發平台 互相穿插交織的方式。而 IDE 剛好能作為研發編輯工具與研發工具服務的結合平台，提高工具、服務之間的串聯效率，提升鍊路的完成性和互動體驗，最終完成研發鍊路的效率更新。
業務側來看，可以看出兩個觀點其實相輔相成，正式由于通過 IDE 這種形式，能更好地完成業務鍊路和産品細節的整合，将複雜度和銜接成本降低，同時能提供良好的流程體驗，更有利于業務場景的落地和推廣。
技術側
一項技術産品站上舞台往往是技術的底層設施的完善程度有一個裡程碑式的提升。随着目前線上線下領域中底層技術的成熟與開放，為搭建 IDE 相關的技術工具、平台降低了門檻，這裡舉兩個代表性的例子：
随着在容器、本地、基礎依賴技術體系的不斷成熟和得到開發者的認可，搭建 IDE 內建環境的效率和門檻進一步提升和降低，促進 IDE 在不同研發場景中的落地和發展。
分析小結
由整體行業的發展我們可以窺見，當下一體化的研發模式會逐漸随着業務上的訴求以及 技術上的成熟的趨勢 ，通過 IDE 內建研發環境整合的方式在各個業務場景上鋪開。
而回過頭來，當下研發模式面臨的問題和痛點是什麼，是我們 IDE 共建項目的目标和出發點。
起因與目标
起因
一方面當下的工程體系、平台很多更關注于線上資源的編譯建構、稽核檢查以及上線釋出流程，而對于研發态的幹預和定制能力有限。
代碼研發過程往往與上線過程存在一定的隔閡。面向未來的理想全鍊路工程體系，可以将研發态的能力與服務也進行鍊路整合，完成從倉庫建立到倉庫資源釋出的整合，最大化的內建研發過程中的能力與服務，提升研發效率。
另一方面，由前文提到，當下其實在公司内外部的很多産品中，都有各自自研或者基于開源項目進行 IDE 能力研發與定制，同一個功能點，例如基于
monaco-editor代碼語言提示等功能在現有的産品中的實作都大同小異，而這塊相同的功能的投入每個平台都需要投入一定的精力，存在 重複建設的問題，而向更深層的探索了解和研發投入也受到限制。
目标
從目前的現狀出發，引申出共建 IDE 項目的目标:
>面向經濟體業務研發場景，打造雲端與本地端一緻，内外統一的 IDE 通用底層能力，支撐研發場景的 IDE 能力的快速搭建與內建
基于 IDE 底層能力，業務場景研發平台能快速地完成 IDE 能力的搭建或內建，同時通過底層的插件體系能力完成業務研發鍊路的能力的定制內建。
通過通用統一體系的建設，将重複投入的精力進行收斂，讓更多的精力基于統一的研發底層投入到更深層次能力的建設和創新中去，形成技術生态的良性循環，在内外部各個系統之間形成扭轉，讓技術産出發揮最大化的價值。
方案與政策
項目定位
IDE 的本意是內建開發環境。從狹義上了解就是我們日常研發的代碼開發工具，例如以 VSCode 舉例，內建研發環境中包含的代碼編輯器 Editor 、資源檢視 Explorer、終端 Terminal`等相關的功能子產品。
目前實際業務場景的訴求上所期望的是作為內建開發環境角色，研發平台需要支撐的除基本編輯研發能力相關之外，同樣需要将使用者在研發流程中所用到工具、服務都進行串聯和內建，才能讓研發流程在一個環境或者體系中運轉，發揮工具、服務的最大效應和價值。
是以 IDE 共建底層項目需要做的，一方面往技術底層走，需要在正常的 IDE 基礎子產品能力方面提供完整的通用體系能力。另一方面往上層走，面向業務場景提供 IDE 服務內建解決方案，友善快速完成業務場景中研發工具、服務的整合與落地。
基礎能力
在開展上層建築業務價值之前，需要将最底層基礎的基本能力進行夯實，我們将現有傳統 IDE 領域中所關聯的一些子產品能力進行分成劃分：
目前大緻化為三個部分。
基礎能力層：有建構 IDE 功能的底層依賴子產品組成
- 例如基于布局能力來完成整個 IDE 應用界面的搭建；
- 基于最底層的檔案服務子產品完成目錄浏覽的資料讀取支援和進行目錄和檔案的浏覽檢視，同時也向文檔Model 文檔定制子產品提供相應的檔案監聽能力，用于前台編輯文本的狀态同步；
封裝能力層：這一層與基礎能力層一樣，也是屬于共建底層能力的一部分。而這層則是着重通過基礎能力層提供的能力，來實作在 IDE 領域相關的一些核心子產品。
- 例如核心編輯器子產品的運作需要依賴底層的檔案服務、通信能力、指令機制、快捷鍵綁定等一系列的子產品；
- 而在終端子產品的協定适配過程中則需要通信能力提供底層的協定适配能力；
支撐服務層：除了 IDE 內建需要的底層子產品能力，這層主要是針對 IDE 的運作态所需要具備的一些線上服務。
- 例如通過插件市場進行插件的下載下傳安裝；
- 通過容器服務來提供雲端版本 IDE 的運作時環境等；
目前共建項目現階段主要的精力就是投入到基礎 IDE 底層子產品及支撐服務的研發中，保證功能在符合現有落地的場景下，達到現有 IDE 體系一線水準能力。
業務能力
在業務能力話題中，前文提到 IDE 的核心價值其實對業務場景研發鍊路的整合，完成研發效率的提升，在現有的環境中确實有非常多這樣的場景：
在業務內建能力的采取的政策方案上，因為我們期望想實作内部與外部、本地端與雲端的同步一緻，我們期望通過插件的方式來解耦打包內建能力，形成技術生态服務業務。
以微信小程式、支付寶小程式舉例，相比現有VSCode體系中的插件主要是針對研發流程中的編輯體驗增強，業務上的場景往往是研發鍊路界面、入口的內建來實作鍊路的串聯。
是以在目前設計的插件體系中，在相容
VSCode 插件生态的基礎上，擴充出插件對UI 元件定制的邏輯，針對插件中的業務邏輯，底層提供提供可選的浏覽器 WebWorker 環境與 Node 環境 運作時環境，并在運作環境時中注入底層能力中一些響應 API ，提供業務邏輯運作時與 UI 元件的雙向調用鍊路。完成 UI 元件定制與業務邏輯的響應。
在插件中可以在邏輯服務側進行對界面中注冊的通過不同元件注冊進行 API 調用，回報到元件的展示上，同時在浏覽器中不同的 UI 元件也能對插件服務邏輯提供出來的服務接口邏輯進行調用，分離邏輯執行，提高整體的業務邏輯執行性能和穩定性。
在從業務場景中去碰撞汲取經驗、沉澱技術的同時，我們也對接下來的發展有既定的計劃。
下一步
我們期望在随着底層的成熟和穩定，在明年的時間點能在下一步進行更多場景的嘗試。
一方面進行外部開源開放，使用者也可以借助底層能力來做符合自身日常工作的內建研發解決方案，并也親身參與到底層能力的改造優化中。
另一方面在阿裡雲上基于KAITIAN-FRAMEWORK雲上也會提供開發者工作台串聯雲上研發流程的産品，來內建掉開發調試與部署釋出全鍊路流程，提升整體雲上服務的研發體驗，提供未來研發模式的探索體驗。
我們期望能通過 IDE 項目，凝聚合力，形成生态環境，借助集體的力量，一步一個腳印疊代完成從輕量級研發到主要研發模式的逐漸替換，形成未來日常工作的基礎設施。
以上就是我們在第十四屆D2前端技術論壇中分享的所有内容。
PPT連結。關注「Alibaba F2E」
把握阿裡巴巴前端新動向