研发工具一体化：低代码引发的效能演进

我对于无代码编程的研究也有些年头了，从国内最早的『无代码编程』相关的文章，到最近的『流程即代码：云研发 IDE Uncode』，我大抵是有资格再聊聊这个行业。

最近，我们 Inherd 开源小组推出了『云研发 IDE：Uncode』的预览版，然后便与不同企业的人进行了一波的交流。在这些观点的驱动之下，我觉得我们有必要再写一些文章：好好介绍一下一些相关的理念。这些理念用于帮助这些企业，好好思考一下研发平台的下一站。

再谈云开发平台

对于开发平台来说，转身为一个云开发的平台，是行业内的一个大趋势。这也就是为什么国内的各大云厂商都在兜售它们的平台。从我与他们的交流情况来看，尽管它们自称有一个“完整”的平台，但是客户只买单其中的一两个。其中的原因颇多，其中的一些主要原因是：

企业自身已经开发/采购一部分环节的工具、产品。
平台本身缺乏足够的亮点。

而位于其背后的主要原因，我个人的观点是：它对于效能的提升是极小的、有限的。这些平台缺乏一个完整的回路，以提升整体的体系与交通。

1. 平台没有『闭环』

首先，让我们来看某国内领先的云公司的案例。它们宣称：通过整合云原生产品和云效，完成了云原生开发闭环。其所谓的闭环是，它们有：

在线协同工具
代码托管工具
在线 IDE
在线构建
在线部署
在线运维

然后，他们宣称这是闭环。嗯，作为一个工程师，我在大学是学过自动化相关的课程，所谓的闭环是：

闭环(闭环结构）也叫反馈控制系统，是将系统输出量的测量值与所期望的给定值相比较，由此产生一个偏差信号，利用此偏差信号进行调节控制，使输出值尽量接近于期望值。

简单来说，闭环的一个重要标志是：输出改进输入。而闭环本身又分为整体闭环和链路闭环：

整体闭环：系统的线上运营指标，可以指导需求的创建。
链路闭环：系统的两两之间可以形成闭环，加快反馈回路。如代码的修改，可以反馈到设计和需求。

所以，回到上述这个案例里，如果要完成整体的闭环，它还需要加入在线运营的环节，才能完成整体闭环。

2. 工具间的割裂

对于这一点，我相信大家都有体验。我这里主要以云厂商和大型 IT 团队为例：

云厂商单工具可零售

继续以国内的云厂商为例，它们为了让企业能用上自己的云服务，便上线了大量的研发相关的工具，如云 IDE、看板、代码托管等等。它们存在的一个问题是，为了卖出更多的云服务，每个工具本身是可单独售卖的，所以每个工具本身是包含大量的可定制元素。也因此，这个系统中的每一部分都相当的臃肿，更难以形成一个完整的方案。

如果基于这些云服务、工具去构建一个开发平台，那么它将带来 M ^ N 的复杂度。反而不如，推出一个一体化的版本更为容易。

大型企业工具部门墙

作为一个技术咨询师，我在内部材料、咨询项目中见过大量的平台和工具。它们有着大量的重复性的工具，还有着工具间的隔离问题。如 A 团队开发了一个工具 a，而 B 团队开发了一个工具 b，这两个工具相结合可以创造出更大的生产力。但是，你懂的，他们出于部门墙的缘故，往往难以结合到一起。

3. 还有，开发者的体验呢？

这是另外一个大话题。（有兴趣可以读一读『开发者体验 —— 内部工具的“最后一公里”』。）

一个常见的问题是：在设计工具的时候，由于面向领导的需求，往往面向使用者考虑的优先级会低于领导使用时的优先级。

低代码对于研发平台意味着什么？

在这里，我把研发平台和低代码做了一个简单的绑定，其中的缘由是：人们对于低代码的实践和思考，必然会引发下一步对于研发平台的改造。

低代码平台的意义：流程优化的思考

对于当前流行的拖拉拽低代码平台，我提不起任何的兴趣。在整体方案上，我喜欢于构建基于 DSL 的低代码平台。在这一篇文章里，我不展开对于这两者的讨论。

不论是拖拉拽低代码平台，还是 DSL 低代码，它们让越来越多的开发人员、管理者开始思考一个问题：如何优化当前的流程？

低代码是从需求到线上代码的直接转换，作为平台的用户，他们本身理解真实的需求，可以作为直接的创作人员。在流程上，它省略了需求电子化，需求转换为验收条件的一系列过程，与此同时，它还可以让应用直接上线。整个过程中，它大大加速了应用的设计和开发过程。

那么，作为一个企业的研发平台，我们也理所应当的加速当前的这个流程。

研发工具一体化

基于云研发和低代码的思路，我们定义了第一个版本的研发工具一体化：

研发工具一体化，即构建从需求、设计、编码、构建、测试等完整研发体系的研发工具上的链路闭环。链路内的两个结点相互影响、相互关联，如系统的需求的创建将关联到设计的创建，设计的完成将生成对应的代码生成。在完成整体的闭环时，代码的变更将影响到设计的变更和需求的变更等。

即，我们要做这么两件事：

形成工具间的反馈回路。
完善工具间的关联设计和用户体验。

基于这两个目标，我们能：

在看板上创建一个需求时，可以将其与设计进行关联。
完成模型设计时，可以自动生成代码到代码库中。
完成 UI 设计时，可以生成代码到代码库中。
代码库的模型发生变化时，将自动变更 UI 设计和模型设计。

这就是我们当前在 Uncode IDE 做的事情。

与研发中台的关系

正是人们建立了后端服务的中台，促使人们在构建低代码平台时，拥有一个强有力的技术后盾。同样对于研发体系也是如此，在中台热潮里，人们定义了『研发中台』：

软件开发是一项工程，涉及到管理、流程、测试、团队协作等等方面。如何将企业的开发流程、最佳实践沉淀成可重用的“能力”，从而助力创新性应用的快速开发迭代，也是我们看到的很多企业正在做的事情，我们可以管这种关注开发效能管理的平台叫作研发中台。

对于那些已经建设研发中台的组织来说，它们可以进一步往前进了。

研发工具一体化的难点

要搞研发工具一体化并不是一件容易的事情，毕竟我设计了这么多年，才有了个大概的雏形。从企业来说，这些痛点主要是：

组织内的部门墙
缺少代码专家
KPI 制度难以驱动长期目标
……

与此同时，这个市场上并没有一个可以参考的成功案例。

构建研发工具一体化的核心

对于研发工具一体化来说，我们关注于两个点：

抽象设计，即 DSL@Core。使用特定的语言来描述工具，以确保工具与具体实现无关。
反馈设计。即系统的所有输出能影响到输入层面，用于确保各步骤的一致性。

抽象设计：DSL@Core

借助于抽象，而非具体实现，DSL（domain specific language，领域特定语言）就这样的一种模式。如在《云研发：研发即代码》中，我们引入了一系列代码化的方式，用于描述不同环节的抽象。

当然了，设计一个使用自然语言描述的 DSL 不是一件容易的事情。为此，我们可以数据描述的 DSL，如在低代码平台流行的 JSON Schema，类似的还有 Database Schema。

使用何种形式的 DSL 并不重要的，重要的是用它来描述流程与设计。如我们可以用 BDD 的方式来描述需求：

Given I visit "/login"
When I enter "Bob"in the "user name" field
And I enter "tester"in the "password" field
And I press the "login" button
Then I should see the "welcome" page

再将其转换为 UI 设计的 DSL：

flow 登录{
SEE 首页
DO [Click]"登录".Button
REACT Success: SHOW "Login Success".Toastwith ANIMATE(bounce)
REACT Failure: SHOW "Login Failure".Dialog
SEE "登录失败".窗口
DO [Click]"忘记密码".Button
REACT: GOTO ForgotPasswordPage
}

以诸如此类的方式作为中间承载类，完善整个系统的设计。

PS：如果你对这一系列 DSL 有兴趣，可以参与到 Inherd 开源小组的一系列开源软件中来：https://github.com/inherd

反馈式设计

在设计需求、设计、代码时，我们使用 DSL 来隔离实现。在实现之后，我们需要对实现进行分析，看其是否与设计出现偏离。因此，我们要进行反馈式设计。

如在架构上我们可以采用 守护式编程 / 限制性编程。当设计与代码不对应，则修改设计。需求与代码不对应，则修改代码。如下是我们基于 ArchUnit 设计的适用于主流语言的架构守护的 DSL：

class(implementation "Connection.class")::name should endsWith "Connection";
class(extends"Connection.class")::name endsWith "Connection";
class(assignable "EntityManager.class") resideIn package("..persistence.");

这里我们定义了一系列包、类等的访问规则，随后在提交阶段，通过对代码的分析来看代码是否出现架构上的越界？一旦访问了规则限制的 DSL，则限制其提交代码。

又比如，我们在 Uncode 中引入了 modeling 分析工具，将代码中的模型关联到设计模型中，以判断模型是否偏离原有的设计，并进行调整。

其它

就时间而言，现在并非是建立研发工具一体化的最好时间。但是，是时候采取对其的预研。

欢迎与我们进行交流。