華為的IDE技術探索之路

我所在的部門“華為云 PaaS 服務產品部”在軟件開發工具領域肩負著兩大使命：一是為華為內部各產業開發者提供軟件開發工具，提升開發效率；二是以華為云為承載平臺，將華為內部優秀的軟件工程工具和研發實踐服務于廣大外部開發者。

縱觀華為公司的 IDE 發展歷程，大致經歷了三個階段：插件開發，自研內核，商業化探索。

華為從 90 年代起開始投入通信產品的研發，有著豐厚的嵌入式軟件開發底蘊。華為嵌入式軟件開發有幾個顯著特點：代碼量巨大，可達千萬行級別；運行環境強依賴特定平臺，調試驗證困難；過程質量要求高，有集成各 IT 系統訴求，以滿足研發流程要求。彼時華為仍是一家以通信產品作為主要方向的設備廠商，對 IDE 領域并未過多投入，加之市場上已有一些成熟的商業和開源軟件，能基本滿足華為軟件研發需求，此階段 IDE 策略主要是基于以采購商業軟件和使用開源軟件為主。同時，由于公司對研發過程的質量要求高，大量研發流程需要在 IDE 中承載，這就對 IDE 提出了定制擴展的訴求。因此，各產品團隊結合自身業務特點，開發了多款 IDE 插件。

時間來到了 2019 年 5 月，由于眾所周知的原因，華為內部研發工具需要進行大面積的自研，以保障研發作業的安全性。面對巨大的生存風險，我們做出了艱難但正確的戰略決策：自研 IDE 內核。隨后，我們聯合各個產品線基于統一底座 + 插件生態 + 語言支持的框架，建設公司的 IDE 解決方案。IDE 是一個復雜的軟件系統，要實現所有組件的完全自研不現實也沒必要，我們只需要找到最硬的那幾根“骨頭”把它們啃下來。到 2021 年底，我們基本實現了內部嵌入式軟件開發領域 C/C++ IDE 工具的自研替換，部分能力甚至實現了對原有商業工具的超越。

解決自身生存問題的同時，我們也在積極地進行商業化探索。華為云軟件開發生產線 CodeArts 就是華為軟件研發能力外溢的第一次成功嘗試。經過多年持續研發投入，CodeArts 從最初的云上軟件開發平臺 DevCloud 成長為覆蓋軟件開發全生命周期的生產線，并一躍成為中國 DevOps 平臺市場領導者。而本文的重點“CodeArts IDE系列產品”，就是 CodeArts 產品族中的核心之一。

WebIDE vs 桌面 IDE

也是在 2019 年 5 月，我們開始做 WebIDE 服務（本文 WebIDE 指代所有在瀏覽器當中完成編碼調試測試的 IDE 產品形態包括后端部署在云端虛機、容器中的 Cloud IDE），當時目標的細分場景是云原生應用快速開發和部署。2020 年 HDC（華為開發者大會），我們推出了與華為鯤鵬芯片協同的云端開發環境“華為云 CloudIDE”，成為鯤鵬原生應用開發的首選平臺，用戶反饋正面。

隨著應用現代化、云原生的發展，云端開發場景越來越豐富，CloudIDE 再次被推到舞臺中央，這次主打輕量級云原生應用開發部署。我們開發了大量打通云服務開發、調試和部署的插件，并于 2021 年推出了 ToB 的云原生應用集群調試服務 CloudDebugger 和面向云資源租戶的 CloudShell 服務。2019 年到 2022 年三年艱難的探索，我們其實做到了不忘初心，并且深刻認識到：“隨時隨地編碼”可能并非高頻剛需場景，WebIDE 一定要服務于某個細分場景才能發揮其最大價值。事實上 WebIDE 在華為內部某些嵌入式開發場景已經規模應用起來，特別是開發環境配置復雜，編譯構建環境特殊，提供一個開箱即用的 WebIDE 托管服務，對于開發者特別是新手非常有價值。

但是，單純從一個效率工具的角度看， WebIDE 的還是有一些明顯的痛點：首先是性能，托管服務的資源規格相對固定，算力可能不如本地環境強大；其次是靈活性，由于安全合規的要求，云端環境通常不能隨意安裝組件；再次是安全感，WebIDE 實例隨時創建隨時銷毀，讓開發者擔心開發較大項目時數據會丟失。最后是使用習慣，在瀏覽器中進行開發作業需要適應，網絡連接也要足夠穩定。鑒于這些明顯的痛點，我認為下一代 IDE 的主流產品形態應該還是類似傳統桌面 IDE，但內涵更廣泛。具體來說，下一代 IDE 除了具備傳統桌面 IDE 的主要特征外還應該具備以下特征：

第一，智能化全面融入編碼、瀏覽、調試、搜索等各個開發環節。

以代碼補全為例，這里大體會有兩個方向，一個是類似 GitHub Copilot 和 CodeArts IDE Snap 所謂的 AI 配對程序員，開發者用自然語言注釋描述，AI 自動生成代碼；一個是短符號的“Tab Complete”代碼生成。

關于第一個方向，我個人觀點：類似 AI 配對程序員的技術在中短期來看，重點是編程輔助，而不會進入主流開發流程，也不會成為高頻剛需場景。究其原因，還是在于“安全感”，AI 生成的大段代碼沒人敢不做檢查就直接提交到代碼倉，而代碼審核可能更耗時耗力。

關于第二個方向，我們進行了一系列概念驗證，發現開發者喜歡“一切盡在掌握”的感覺。在短前綴或者無前綴的情況下，輕量級的 AI 模型對不同場景下的補全結果進行排序，讓開發者通過敲擊 Tab 鍵，連續多次完成短符號的代碼生成，這種 Tab-Complete-Done 的體驗讓人愉悅。并且由于是短符號推薦，Top1 命中率遠高于多符號補全。當然在推薦列表里也存在當前上下文的可能的長結果（整行補全），開發者可以通過上下鍵自己選擇。

舉個“Tab Complete”的例子，比如下面這段代碼，理想情況下開發者敲擊‘D’+Tab，‘.’+Tab，‘.’+Tab，‘.’+Tab 共八次按鍵，IDE 連續完成四次函數補全。

“Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();”

第二，隨時創建并連接到短暫的、可擴展的遠程異構環境。

簡單來說，如果開發者需要一個 MySQL 的環境，他不需要在自己 IDE 環境中安裝 MySQL，只需要通過 IDE 創建并連接到一個臨時的遠程 MySQL 環境進行開發測試，環境使用完畢即自動銷毀，遠程環境的生命周期管理對于開發者來說是透明，開發者也不用關心環境的可獲得性。當然，這個能力光靠 IDE 還不行，還需要遠端環境服務的支持。事實上過去三年我看到的趨勢是，同時做云和 IDE 的廠商持續加強其工具和云服務的聯系，只做云或者只做 IDE 的廠商正在嘗試加強合作。

第三，技術上同時兼容 WebIDE 和桌面 IDE 兩種使用方式。

隨著遠程開發技術的成熟，技術上實現一個 IDE 支持兩種模式（服務器和桌面模式）已經成為可能。這種架構可以給開發者提供足夠的靈活度，徹底解耦編碼和編譯構建調試環境，也避免交叉編譯可能帶來的痛苦。

第四，豐富的插件生態、多語言支持和擴展的能力。

Visual Studio Code 插件已然成為事實的標準，下一代 IDE 只要能兼容該標準就能迅速獲取海量插件。云原生應用的微服務、容器化、分布式架構等特征也帶來了多樣化技術棧和多編程語言支持的需求。新場景新編程語言的出現也要求 IDE 能提供擴展語言支持的能力。
IDE 的核心技術是什么

這里首先澄清一點，以 Visual Studio Code 為代表的代碼編輯器即使搭配語言插件也并不等同于傳統桌面 IDE。代碼編輯器以文本編輯為中心，以文件和目錄為訪問對象，而傳統桌面 IDE 以代碼編輯為中心，以項目為訪問對象，二者有本質區別。那么 IDE 的核心技術是什么？圖形用戶界面 GUI？文本或可視化編輯器？編譯構建調試工具的集成？其實都不是。IDE 作為一個效率工具最核心的部分是代碼模型的處理引擎，其處理代碼的性能，內存占用，索引大小，API 好壞直接決定了上層特性如語法高亮、瀏覽、補全、重構、檢查等的易用性和整個 IDE 的體驗是否“絲滑流暢”。

一個完整的代碼模型處理引擎至少包括如下四個子系統：

一、項目模型（Project Model）。該子系統主要負責構建項目結構的高級視圖，并提供接口訪問當前工作空間的項目及其依賴關系、代碼在磁盤上的文件夾和文件如何組織的數據結構。以 Java 項目模型為例，其最核心的組件是一個稱為代碼根（Code Root）的底層接口實現，代碼根從邏輯層面代表 Java 項目所有代碼的可能來源 – 本項目源代碼、底層運行時依賴或第三方依賴包，并提供分析和處理上述代碼和生成索引的功能。

二、索引（Index）。每次打開項目，IDE 都要需要花費時間來解析和處理所有源代碼，這種處理的中間結果就存儲在索引子系統中。項目第一次打開將構建完整的索引，一旦索引構建完成，所有后續的項目加載只需要對增量改動進行索引。索引又分基于文本的索引和基于語義的索引。前者很好理解，創建索引的信息是基于文本的，它不依賴于任何特定于語言的語義，因此是完全本地化到源文件中，該類索引的更新完全基于增加 / 刪除 / 改動的文件。而基于語義的索引就比較復雜，它包含的語義信息可能涉及多個源文件。比如“所有返回類型為 A 的方法”的索引就是基于語義的，它給出了一個返回類型為 A 的方法列表。該索引的生成就要依賴于對該項目模型所有源文件的名字解析的過程，并且僅僅考慮添加 / 刪除 / 修改的文件來進行更新也是不夠的，因為語義依賴信息可能并不僅僅存在于改動的文件中。

三、語法（Syntax）。語法是編程語言的底層結構和規則。IDE 使用抽象語法樹（AST）來理解編程語言的源代碼，而 AST 的訪問是高頻操作，所以語法子系統的任務就是提供高效和方便的 AST 訪問接口給 IDE 其他模塊使用。

四、 語義（Semantics）。給出一個表達式“a = x;”，如何判斷‘x’的種類？是本地變量、函數參數、類字段還是方法名？如何判斷‘x’的類型？int，long，string…? 語義子系統可以回答這些問題。一般來說，AST 是一種低層的代碼文件結構，用于表示特定的源文件，AST 節點通常不具備具體的類型信息。還有一類數據稱之為符號（Symbol），從 IDE 角度看符號是一類更高層的數據結構，它是從多個源文件的 AST 或者二進制依賴包中生成的，代表的是 AST 節點跨文件的類型信息，它可以告訴你某個方法是否是構造函數，某個變量屬于哪個類型申明。語義子系統會構造完整的符號表并把對應符號附著到 AST 節點上，使之成為具備類型信息的 AST（Typed AST）, 這個過程稱為類型綁定（type binding）。而基于 Typed AST 回答上述“如何判斷”的問題的過程稱為名字解析（name resolution）。

講了這么多，那下一代 IDE 的代碼模型處理引擎是什么樣的呢？這個問題我也沒想清楚，但我們在探索一種基于統一架構的代碼模型處理引擎，架構大致分為三層：語言解析層：語言相關，不同語言不同的解析邏輯；語法、語義適配層：語言無關通用接口；索引持久化層：語言無關，基于索引元數據的高性能存儲系統。這樣設計的好處是最大化重用各子系統，并且可以快速支持新編程語言。技術指標層面，下一代代碼模型處理引擎應該在補全或引用查找等高頻特性方面有指數級的性能提升。

商業價值和產業機遇

最后我想聊聊 IDE 未來在我國市場的商業價值和產業機遇。去年（2022 年）是微軟 Visual Studio 誕生 25 周年，從第一個版本 Visual Studio 97 到 Visual Studio 2022，其主要商業模式一直都是訂閱或者許可售賣。Visual Studio 對于微軟的商業價值是否只是銷售收入？如果是，后來的代碼編輯器 Visual Studio Code 是免費產品，它的商業價值又是什么？

微軟于 2008 年左右開始做云，2014 年薩提亞成為微軟 CEO 后，提出“移動為先、云為先”戰略，并且徹底擁抱開源，“Windows is the air we breathe”被扔進歷史的垃圾堆，隨后.NET 開源，2016 年發布 VS Code 1.0 并開源，2018 年收購 GitHub，最終組成了軟件開發工具（VS/VS Code）+ GitHub + Azure 的強大的開發者生態價值鏈，成為驅動微軟營收持續增長的引擎。微軟在云這個戰場開辟了一條新賽道：

云服務供應商必須打通開源軟件到云服務的價值鏈。

軟件開發工具（特別是 IDE 或類 IDE 產品）是這條商業和生態價值鏈的起點，云服務是終點。

在轉化率不變的前提下，工具的用戶越多，生態入口越大，云的生態越繁榮。

回到我們自己，咱們國家軟件產業是否需要一個擁有自主可控核心技術的 IDE？這個問題沒有統一答案，不同行業差異很大。但軟件供應鏈攻擊的問題（大家有興趣可以關注下 SolarWinds 供應鏈攻擊事件）讓我始終堅信：信創基礎軟件工具鏈對于我國高科技企業來說是一個巨大的產業機遇。因此，關乎國家安全的戰略性產業，對技術自主可控要求高的企業，這個問題的答案就顯而易見。對于需要構建開發者生態的企業或產品，擁有自己的 IDE 可以打造定制化的開發者體驗和工作流，降低應用開發難度方便開發者，同時也可以避免將生態構筑在別人的平臺之上，在當下這個脆弱的全球產業鏈大背景之下，這點尤為重要。

未來不管技術如何發展，軟件架構如何演進， IDE 作為開發者的效率工具其核心的編碼調試測試等功能不會改變。在不同細分領域如 AI、智能汽車、芯片等，其集成的工具鏈會更廣泛，開發場景也會具備更多的業務屬性。

作者簡介：

王亞偉，華為云開發工具和效率領域首席專家，華為軟件開發生產線 CodeArts 首席技術總監，當前領導一支國際化軟件專家團隊負責 CodeArts IDE 系列產品的研發和華為云開發者生態能力建設。加入華為前，曾任微軟開發者事業部資深開發經理，在微軟全球多個國家地區工作 13 年。近 20 年的云和開發工具的行業經驗讓他具備從底層技術、產品規劃到開發者生態能力建設洞察的能力。王亞偉先生發表和被授予 20 多項軟件開發技術相關的發明專利。

審核編輯黃宇