上周的某一天，我在浏览IT新闻的时候，无意间被一篇来自阿里团队的文章刷屏了。关注的好几个平台都转发了名为“阿里 & 蚂蚁自研 IDE 研发框架 OpenSumi 正式开源”的文章。
OpenSumi定位是垂直领域的IDE研发框架。请注意，它本身不是IDE，而是一个辅助开发IDE的框架。除了内置常用的开发工具，如资源管理器、编辑器、调试、Git 面板、搜索面板等模块，重要的是，它可以支持开发者通过简单配置就搭建属于自己的本地或云端IDE产品。
OpenSumi的思路竟和我之前分享的“开发者工作台”的思路如出一辙。
开发辅助小工具与敏捷的下半场
为什么会有这样的产品出现呢？回顾经历过的大量的项目，我发现，随着项目逐步成熟，大多数项目都出现了同样的情况。那就是开发者会不断创造适合自身项目的开发工具。
在我加入Thoughtworks的第一个项目中，项目采用了微服务的架构，各个服务的版本、可用性、配置等问题常常导致集成环境失败，开发人员在查找问题时，需要在多个地方查找日志，多个微服务也难以联合起来调试。究其原因，是对多个微服务的管理能力不够。于是，我们借助了开源的SpringBoot Admin项目，在对该项目进行了一系列定制之后，将其适配到当时的项目中。有了这个工具之后，我们可以在线查看和修改微服务的当前配置，集中式的查看日志，在线打印程序调用栈等。从而大大改善了开发人员查找与调试问题的体验，提高了项目交付效率。
在我转移到其他项目时，常常发现，从零启动一个项目是比较困难的，因为很多基础设施都需要重新搭建，项目的基础架构需要重新确定。此时，很多团队都会尝试开发一个脚手架项目，从而缓解这个问题。我和很多团队TL交流的时候，发现他们很多都做过此类的脚手架。
在当前的环境下，几乎所有的软件项目都需要和周边的其他软件系统进行集成。这些集成工作大多数都因项目不同而带有强烈的项目特有的特征，难以适用到其他项目中。于是，为了提高开发效率，开发者会自主构建很多的项目特有的开发者工具。
随着项目越来越成熟，项目特定的开发工具会越来越多。这大概就是敏捷的下半场。
采用极限编程和敏捷开发的思想，软件开发取得了卓越的进步。但是，当IDE快捷键和键盘手速到达极限，跟不上我们对开发效率提升的要求时，下一步就是开发项目特定的开发工具了。这些工具通常可以使开发变得非常高效。并且，在工具的实现上，由于可以只做到刚刚好解决项目中的问题，故工具本身的实现也不难。
由于这些工具的目的都在于辅助开发，并且通常都非常精巧，我们可以将这些工具称作开发辅助小工具。
回到开头关于IDE的故事，我们会发现，开发辅助小工具就是IDE的一部分！而这一特殊部分是不能被通用IDE支持的，所以，一个IDE开发框架就变得有价值了。
通用IDE插件开发不易
有人可能会说现在的大多数IDE都支持扩展，比如流行的Intellj系列IDE，或者VSCode，它们都可以很容易的支持插件。直接基于这些IDE开发插件是不是就可以了。
这里的问题在于，想要为这些成熟的IDE开发插件并不是一件容易的事。原因在于：
- 插件开发有难度。成熟的IDE本身非常复杂，开发者需要理解这些IDE中的一些核心概念、使用的技术框架、API等才能开始开发，但是开发者通常都专注在自己的项目中，很少有人能跨越到IDE开发领域。
- 开发基于IDE的插件带来的成本和收益不成比例。原本的开发辅助小工具本就可以通过命令行调用，但为了获得在IDE中调用的能力，开发者需要投入很大的精力才能完成。
开发者工作台
“开发者工作台”解决这一问题的思路是提供一些通用的UI组件，并且使得这些组件可以轻易的和命令行工具进行整合。这样一来，开发者就不用费力的去将开发辅助小工具集成到现有的复杂IDE中去了。而是通过几个简单的配置就可以在“开发者工作台”中使用。
“开发者工作台”定位是一个IDE框架，与OpenSumi一样，内置了常用的开发工具，如资源管理器、编辑器、调试、Git 面板等。同时还专门为命令行工具集成提供了步骤组合器、任务执行器模块，使得我们仅需要几行配置就可以实现将开发辅助小工具整合到“开发者工作台”。
比如，在数据项目中，我们实现了很多的“ETL代码生成器”工具。此时我们就可以将这些工具通过“开发者工作台”整合到一起，打造项目特定的一个IDE。
上述UI界面可以完全通过配置定义出来，配置代码以TypeScript语言编写，可以获得良好的类型检查和智能提示。
在上述数据项目开发者工作台中，使用步骤组合组件，我们将数据接入的开发任务分为了三个步骤：配置接入信息，生成数据接入代码，运维数据接入任务（包含部署代码，手动运行任务等）。
在这些步骤中，配置步骤通过一个表格配置来实现，生成代码及运维任务均通过与已实现的辅助开发小工具对接来实现。
随着项目继续演进，开发者工作台的功能将日趋稳定和完备，最终将形成项目特定的一个IDE。
研发云平台
近两年，业界有很多团队提出了“研发中台”或者“研发云平台”的理念（后统称“研发云平台”）。在最终目标上，这一理念与“OpenSumi”和“开发者工作台”的理念是一致的。
但是业界很多的“研发云平台”的实现却是出现了一些问题。大多数公司过于看中“研发云平台”带来的降低开发者门槛的作用，他们寄希望做出了这一套平台，就可以靠低成本招到一些能力不足的开发者来完成原有的开发任务，从而降低成本。这里的问题很大！他们忽视了一个重要的事情，那就是开发者的主观能动性。
事实上，“研发云平台”通常都是项目特有的“研发云平台”，没有一套“研发云平台”可以适用于各种不同类型的项目。同时，“研发云平台”是开发者自己打造的“研发云平台”，并不是需要有一个“研发云平台”开发团队，为其他项目开发这一套平台！
如果我们一味去降低门槛，将适得其反，开发效率不仅没有提高，反而由于笨拙的工具迫使开发者想出各种奇技淫巧来绕过工具本身的限制去实现高级功能。这样一来，很多开发者对这类“研发云平台”产生负面评价就是自然的事了。
与此相反，我们应该做的是，鼓励开发者持续学习新技术，持续创新，并为他们的创新提供一些他们真正需要的工具，帮助他们构建属于自己项目的“研发云平台”。