数字中台发展到可拖拽系统，就不需要程序员编码了吧

[splendone]

之前问题：

为什么不能通过类似 draw.io 这样的原型工具拖拖拽拽组件来直接生成系统？

终极目标

通过拖拽生成软件产品，开发成本趋近于 0 ？

中间目标

数字中台，降低开发成本，提高开发效率。

准备：

1. 数据层存储使用知识图谱的三元组保存有效信息（可否这样理解，所谓信息就是关联关系？），使得数据与具体业务解耦，打破项目之间的壁垒，信息可以通用，信息可以扩展，信息可以融合。使数据可以‘拖拽’。
2. 逻辑层，空缺，暂时没有搜到相关。类似 UI 层将逻辑抽象沉淀成可复用模块，与业务解耦，抽象细分的力度和分层需要好好考虑，挺抽象，不好把控，可行性待定。使逻辑可以‘拖拽’。
3. UI 层基于 ant design pro，将前端的模块抽象沉淀成为可以复用的模块，要可以关联绑定逻辑模块和数据模块。使前端可以‘拖拽’

以上数据 /逻辑 /UI 各个层面都是业务解耦，业务耦合是产品设计者拖拽过程耦合到软件产品的。可拖拽系统是业务无关的，应该是个工具，或者工厂，好比 draw.io 这样的软件产品，具体画出来什么图是画图的时候决定的。

流程：

产品设计者，拖拽挑选的前端模块，绑定挑选的后端模块，再绑定挑选数据模块。

正常开发过程：产品设计 -> 开发 -> 测试发布 -> 更新迭代 -> 产品设计 ……

可拖拽过程：产品设计（拖拽) -> 测试发布 -> 更新迭代 -> 产品设计（拖拽) ……

都在设计，编程不需要了……

[miao666]

一个复杂点的 SQL 拖三天未必能拖出来

[Phariel]

你这个想拖拽就能完成目标的想法 十六七年前就有人想过做过 你想想为什么到了今天这个目标还没有实现？

给你举个例子 .NET 的 Web Forms

Initial release 2002; 18 years ago

Initial release 2002; 18 years ago

[splendone]

@miv 确实我忽略了数据处理的难度，这里我想当然了，不过现在拍脑袋先想一想，看这样是否可行：
将数据处理的流程抽象成逻辑模块的拼接，处理完数据再绑到前端，就是说前端绑定的逻辑模块使设计者自己通过更细化的逻辑模块拼凑的，换句话说，拖拽者拖拽的使逻辑，好比程序员敲代码，换了一种形式，改成拖拽逻辑模块了，最粗粒度的拖拽是，这是订单模块，这是支付模块；最新粒度的模块是打回原形，程序员敲代码了。

[liprais]

这东西雾件了多少年了，随便你做，做的出来算我输

[splendone]

@Mark24 我也找过一些拖拽的系统，确实前端拖拽很方便，但是逻辑拖拽和数据拖拽就不好办了，如你所说第 3 条所所，注入代码是不行的，这部分代码也需要可以拖拽，让设计者拖拽一块逻辑绑定到前端组件上才完成的可拖拽。确实逻辑可拖拽太抽象了，是否有可能，把程序员一个字符一个字符的敲代码来表达业务逻辑的过程，改成拖拽逻辑模块，这个抽象的过程是否可行，是否有意义（提高效率），我也不是很确定的……

[kvkboy]

简单的都好办，大学生的问卷调查啊，行政的请假流程，财务的报表，基本只是普通的数据库操作，用这种低代码平台确实很方便，但凡复杂一点，都不用很多，一点点，就发现这玩意没卵用....(来自也要准备搞低代码平台，调研了两天的匿名者内心吐槽

[Chen332076]

所以催生了一个新的职业叫“数据拖拽工程师”？

[bilibilifi]

感觉像是 formal method. 开发确实特别快，但是对设计人员的要求过于严苛

[splendone]

@laminux29
1. 界面的问题，前端模块是需要不断开发的，UI 设计还是不能缺少，算是可拖拽系统的持续扩展吧，美工的创造性不可取代，当然不是只有 draw.io 一个前端样式的。
2. 逻辑层的模块是业务解耦的，如果需要过滤一部分输入数据，是否可以扩展开发相应的算法或者策略的逻辑模块，再拖拽到系统上？
3. 同 2，逻辑模块是可以扩展的，根据具体业务需要，如果是大并发情况，缓存，分流，流数据处理等操作是否可以抽象成逻辑层的可复用模块？

我也不知道可行性的，我想象不到所有场景。逻辑层的可拖拽还是个空白，我现在是想当然了

[xwhxbg]

你想多了，你以为产品和领导会自己动手拖么？还不是要我们码农帮他煮好饭喂到嘴里，然后我们发现拖拽还不如直接写代码呢，又回到写代码了

[Yoock]

这种东西做不到图灵完备😆

[splendone]

@kvkboy 低代码平台前面 @matrix67 有提到，可以参考一下 https://v2ex.com/t/681272
我之前的问题 https://www.v2ex.com/t/639230，也有很多朋友回复推荐相关产品。

[rockyou12]

我觉得不现实，人人都会 if 、for 来写控制逻辑后，搞这些玩意才靠谱。拖拽做业务其实是非常非常低效的，写过过 html 的人再去用其它的拖拽画前端界面就感受得到，开发效率首先就不在一个层次。拖拽对生产级别的开发始终只是辅组。

[javaWeber]

这种破玩意，出了 bug，找到你哭都找不出来。。

你用个开源的技术，一搜索一大堆答案。

[ksssdh123]

历史已经告诉你，拖曳式的结局->dreamweaver

[ppgs8903]

刚做了一个，拖拽可配置的中台系统，结论后续基本没办法维护，你需要写好多东西保证这东西不是环。
咋说呢，如果你只要个流程那就做，如果你要流程，要配置，要校验，要 xxxx 。你用拖拽图简直是找死。
不是说做不出来，维护成本几何级别上升。

[eGlhb2Jhb2Jhbw]

之前待过一家是做类似的平台，然后卖授权的。
问题很多，不能做的那么完美。简单说两个，第一个是因为高度抽象，逻辑层支持的比较的简单，不能每一个 if 都拖一个线框图出来，所以只能 append 一些用户可自定义脚本。经常有一些逻辑错误在脚本中，很难 debug 。第二为了保持一定的可定义性，基本都是原本概念 UI 化，比如“字段”、“视图"、“实体”等，这就导致了不经历一个很晦涩的培训是不会使用的，上手难度较高。

[kop1989]

拖拽式其实也是在“编程”。
只不过从写英文改成了拖拉拽，但依然表达的是业务数据化，数据信息化的逻辑。
这就跟你说键盘是不是终结了纸带程序员？不是，纸带时代优秀的程序员用键盘会更优秀。因为效率提升了。
你会担心电起子的出现让当前用改锥的电工丢掉工作么？只能会让电工更有效率的工作而已。

更何况你说的“拖拉拽”其实是一种效率的下降。
从开车变成了骑自行车，从需要驾照变成了不需要驾照。看似好像谁都能骑，但是开车是个人就能跑到 120km/h 。
与其余寄希望于拖拉拽，不如寄希望于脑机 IO 或者是 ai 业务学习。

[jswh]

scratch ？

[wupher]

在职业生涯中不幸多次参与类似项目。

从一键生（成）表，一键建站，业务原语，后端模块化，最后到 App 应用工厂。

从 CS 的 VC++ 到 BS 到纯后台，再到 App 端，众多血泪。

感觉国人特别喜欢这个，可惜，无论是我先后就职过的公司，到业界，都没有成功的产品。印象里，有半成功的产品，360 有搞过一键建站，但也就那样。

你猜原因是什么 ？