如何看待deepin推出中国首款信创生态自研IDE?

图灵的猫

给岁月以文明，给时代以AI | CDA I级持证人

这波是贴脸开大，但不得不说，开的好，就该打隔壁某些骗经费项目的脸。

说回IDE本身——Deepin的仓库我之前是关注过的，社区里非常活跃，开放生态做的很不错。

虽然底层是用到了scintilla以及一些开源部件，但deepin也做了很多本地化的适配和魔改，核心代码是自己写的——以任何社区的标准来看，它都属于纯纯的自研。

就我使用过的版本来看，deepin-IDE除了包含IDE最基本的智能编辑器之外，还包括：

• 支持主流版本控制系统Git、SVN；

• 支持C++、C、java、python、javascript五大类常用编辑语言，支持常用构建工具CMake、Maven、Ninja、Gradle等；

• 支持反向调试、实时性能分析工具

• 支持高可扩展命令系统、工程管理、代码版本管理集成、构建管理、插件系统

以及一些比较新的IDE特性，比如代码迁移、语义补全、语法高亮、重构支持等。

东西这么好，为啥现在才端上来？

我查了下开发日志和commit记录，发现deepin-IDE 并不是突然冒出来的，而是悄咪咪的封闭开发了很久——期间都不断完善功能、攻克一些技术难题，只是因为还没有达到非常完善的地步，所以一直捂着不对外（游戏科学：”我彷佛听见有人在说我“）。

IDE整体采用基于模块化框架开发，支持 C/C++、Java、Python等多种编程语言，每一种开发语言均是以插件的方式接入：

如上图所示，带颜色的模块均和特定的语言相关，对应通信中间件用的是 LSP（Language Server Protocol） 语言服务协议，可以基于该协议实现语法高亮、符号树、语法树等功能；

调试相关的用的是 DAP（Debug Adapter Protocol） 调试适配协议，可以基于该协议实现被调试程序的启动、运行、断点命中、单步跳入跳出等常用调试功能（很常见的功能，但自研难度并不低）

为了进一步提高扩展性，前、后端均以插件方式实现。

在前端通过接入一个新的语言插件来实现新语言的扩展，该插件用于实现语言相关的、特殊的业务逻辑，不用编写全量的代码，从而减轻了语言插件的代码负担。

在后端，通过插件方式可以更容易接入一个语言服务提供者。语言相关的顶层数据流图如下：

开发库方面，Deepin官方是这么说的：

操作系统已经拥有了自己的 DTK（Development ToolKit）开发套件，具备4个核心模块、220+个类、2300+函数接口、11个辅助功能模块、10+个扩展接口模块，已经能够满足日常图形应用、业务应用、系统定制应用的开发需求。

虽然跟VS Code这类老牌IDE还有一定差距，但毕竟刚起步，跟麒麟9000S一样，自研水准做到这样已经很不错的。从目前公开的资料来看，Deepin 操作系统上自研的浏览器、音乐、邮件等 40 余款原生应用全部使用 DTK 开发，说明在开发生态上已经相对可用，并不是纸上谈兵。

当然，它目前的问题也很多，除了官方自己调侃的”缺一个设计师“外，还有

• 文件描述符占用过多导致崩溃

• 存在部分翻译缺失的问题

• 底部交互区暂不支持多页面

• 符号树解析精度不高

等等问题——但瑕不掩瑜，也感谢同行衬托，这个IDE目前显得格外和蔼可亲，想来开发者社区也会抱有更大的耐心，等待deepin逐渐迭代完善。

至于为什么直接开源，他们自己也说了，IDE能做出来是站在了“开源”这个巨人的肩膀上，为了避免重复造轮子，采用了一些开源终端组件、功能组件，所以希望更多开发者加入进来，一起来完善这个IDE：

• GitHub: https://github.com/linuxdeepin/deepin-unioncode

• Gitee: https://gitee.com/deepin-community/deepin-unioncode

最后，现有的集成开发环境存在不支持国产软硬件适配、调试性能差等诸多问题，加大了国产操作系统上应用开发的难度，阻碍了国产软件发展。现在的市场迫切需要一款自主可控的集成开发环境，这也让蛀虫们有空可钻，把真正需要的经费拿来中饱私囊，实际既没有满足需求，还对国产IDE的自研之路造成了毁灭性打击。

我觉得deepin-IDE的路子能走通，才是最能说明问题的——我们国家从来不缺优秀开发者，只要脚踏实地去做事，一定会有人支持。虽然这套IDE现在还是个蹒跚学步的小孩，但未来随着越来越多人的加入，社区逐渐壮大后，统一软件开发方式和开发库，降低软件开发成本，最终解决集成开发环境领域卡脖子问题，可能就不再是个调侃了。

发布于 2023-09-05 21:03