從華為投入研發(fā)基礎開發(fā)工具看國產IDE的未來和商業(yè)模式

| 華為的IDE技術探索之路

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

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

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

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

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

|WebIDE vs 桌面 IDE

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

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

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

第一，智能化全面融入編碼、瀏覽、調試、搜索等各個開發(fā)環(huán)節(jié)。

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

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

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

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

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

第二，隨時創(chuàng)建并連接到短暫的、可擴展的遠程異構環(huán)境。

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

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

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

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

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

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

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

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

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

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

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

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

| 商業(yè)價值和產業(yè)機遇

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

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

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

• 軟件開發(fā)工具（特別是 IDE 或類 IDE 產品）是這條商業(yè)和生態(tài)價值鏈的起點，云服務是終點。

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

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

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

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