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

[splendone]

之前问题：

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

终极目标

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

中间目标

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

准备：

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

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

流程：

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

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

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

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

看了大家的思考和讨论，补充一下心中的几个问题和我的个人想法：
1. 拖拽也是编程，核心的业务逻辑没有被压缩（目前不细究的话可以先这样接受的）。所以可拖拽的意义是否存在？现在和过去肯定没有这种可拖拽系统存在的（刻意严谨的说是我辈程序员视野范围内），可拖拽的操作是有很多的，存在于各种产品，但是都有其局限性和痛点，这些痛点和局限性就是新可拖拽的空间？是空间，但未必是意义，回到第一个问题，可拖拽真的会比写代码有优势吗？我觉得应该是有的，但是很难做到，难到给人感觉“不可能”。不怕困难，就怕没意义。

2. 如果觉得第一个问题的答案是有意义的可以继续讨论这问题，是否可行？数据层三元组表达信息关联，逻辑层的抽象可复用，UI 层的绑定拖拽，这 3 个准备是否有不可行的地方，之前的可拖拽不好用或者局限的地方是什么原因造成的？三元组 /逻辑复用是否能解决问题？

PS： 我理解的中台意义是提高开发效率降低开发成本的，和可拖拽系统方向是一致的，如果觉得中台概念太虚，可以换成“降低开发成本”。

[CBS]

这东西本身就不好搞，加上性能体验交互各种问题。

（主要是做了工作就么的，所以程序员不做这东西）

[Vegetable]

挑剔老生常谈了，技术改变的只是编码的形式，而无法改变工程师的本质

[Vegetable]

*标题老生常谈

[fanfou]

嗨，这我做过基于 uml 的

[reus]

那谁来开发可拖拽系统呢？

还是说你这个可拖拽系统自举了，自己开发自己？

我一句话说完的事情，你还要拖拽？

[wysnylc]

用乐高做房子拖过来堆起来就好,还要施工队干嘛

[matrix67]

这不就是这个里面说的。。https://v2ex.com/t/681272

[murmur]

拖拽开发简单的 curd 业务是可以的，经不起毒打

[chanchan]

老普元了

[lonelymarried]

谷歌、微软都没出这种，是有原因的

[miv]

这种在某一些业务上可以有很大作用。
比如说 BI，需要出什么图形，自己拖，后面跟上数据接口就完事。
不过，如果复杂的业务上来说，成本是非车大的。
1.如同你上面说的，业务层需要解耦，扩展性要好，这就要求设计的时候需要考虑到后面的场景，如果业务一变动，直接就 GG 。
2.产品都是在迭代中升级的，所以，一开始就把以后的都设计好、解耦出来，这个本身就比较难，不然，就不需要花需求分析、产品设计、UI 设计等，这一整个链条的人才了。
3.综上，在一个比较垂直，并且业务变动不大的领域我感觉是可行的，这要求有相对丰富的设计和开发经验。如果这是一个比较宽泛的产品，企图包含各行各业，并且要求抽象业务出来，那我不太看好。

[miv]

[产品设计者，拖拽挑选的前端模块，绑定挑选的后端模块，再绑定挑选数据模块。]
这句话我认为楼主忽略的数据处理的难度。
有的时候，数据并不是简单的直接从数据库、接口可以直接获取并利用。

[Jooooooooo]

你猜猜有了 ps 这么强大的工具后为啥还需要设计师呢?

[nianyu]

只适合套路模版化的东西。遇到复杂多变的需求无非自定义一堆然后坑了一代又一代

[liunian1004]

元编程也要编程。

[php01]

怎么就这么多人想让程序员失业呢。。。。

[Mark24]

以前用过白鹭的拖拽游戏引擎做过 Hackathon

宣传广告上号称拖拖就可以生成游戏，好有吸引力

当时就像着特别美好

结果肝到爆炸


1.拖拽形式的 UI，特别难做。能感受到。难于理解。界面复杂。

2.这种庞大的软件，BUG 奇多。

3.拓展性依旧不行，遵循模式。一旦你想突破——你能想象你无法办到某些事情，你不得不在 Input 框里注入代码么

4.这种软件用了超过 24h，掉了无数头发，你会开始思考程序的本质

本质依然是造程序，UI 只不过是个壳子。

我想出一个词儿——逻辑守恒。

就像能量守恒一样，你想要造出的东西，不管你用什么工具，逻辑必然也守恒。

UI 可能帮你做了一些场景。

但是完全自己设计的场景，需要的是灵活的支持。

这时候，其实你就会发现，能够完成需求本身的工具——就是编码语言本身。无他。

其他能做到的，就是编码语言的逻辑等价，或者子集。


然后我就觉得，这些玩意都是虚的。没什么卵用。

如果真的有比 计算机语言还要好的工具，这些语言造就成摆设了。之所以 30 年以来，语言还是主力。只能说明，目前没有更优秀的解决方案。

太阳下面没有新鲜事，很多的想法，无码化，不是今天才被提出，已经被很多人实现过又抛弃。

只不过人们不断一次又一次重演历史。




虽然我自己目前也做前端。什么中台，无码化，假的,KPI 而已。你问他们，他们自己信么？
无非是，一件事情拆成 2 件事情做，简单的事情变成复杂的事情做。
如果小公司也学，那就可笑了。没有大公司的钱，可是得了大公司的病，会被自己内耗死。
业内已经形成不良风气，为了追求影响力，发明新词，不断地新瓶装旧酒，十分没意思。大家要擦亮眼睛

[chendy]

拖拽一时爽，重构那啥啥
套路固定的领域很适合这种东西，甚至都不用拖拽
套路多变的领域快速出 demo 或者代码生成也行，长期肯定不用

[laminux29]

我随便讲 3 个需求：

1.领导觉得当前界面不好看，给了一个模板，要求按这个模板进行修改。题主用 Draw.IO 试试？

2.今天系统做投票活动，有用户去淘宝买刷单服务，卖家先是用大量不同 IP 进行投票，投票完毕后对系统进行 DDOS 攻击来阻止别人投票。请用题主用 Draw.IO 来解决这个问题。

3.12306 网站，有大量用户反映说购买车票页面，经常打不开，导致购票失败。请题主用 Draw.IO 来尝试解决这个问题？

[tcpdump]

说个笑话，美军的中台战略

[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 有搞过一键建站，但也就那样。

你猜原因是什么 ？

[KingPL]

我看评论精彩多了

[miv]

@wupher 老哥感触很深，其实我们之前公司也是弄个类似的，老板主张弄一套，针对某一个行业。
后面发现拖拽的时候，涉及到字段匹配、逻辑判断这些问题，基本是很麻烦处理起来，后面也没做起来。
当时开发的时候，感觉一言难尽，自己尝试用了下自己开发出来的这套软件，难用的一匹，而且功能也达不到，太难了。
如果，真的有好用的产品，滴滴我，我还是会瞅一瞅的。

[taigu]

@jswh 刚想说这不就是前两天给小侄子报的“scratch 编程”吗

[Mark24]

看到各种经历。这个帖子具有历史价值。


后人哀之而不鉴之，亦使后人而复哀后人也。

[kemistep]

这么说吧：quickbi 、 帆软等等一系列的 BI 工具，不都是你这个具体化嘛？ 可以搜一下 BI 工具，看看是否满足你

[wangyzj]

你是不是没被产品经理毒打过？

[kemistep]

技术不是难点，难的是业务，以及基础的宽表，和多维度的分析；

报表不是展示好看的，是为了解决一些列的问题而存在的；

现在大公司的底层宽表，100 以上的字段宽度，依然满足不了业务需求，

业务的复杂性，不是这么简单的

[kemistep]

@miv 部分公司在做这块，比较好的就是：growing IO 诸葛 io 等相关公司，开始做这块，但不是拖拽； 拖拽是结果展示层，主要还是底层的业务要处理好，以及有一套业务框架，解决通用问题；

[HeyWeGo]

www.pinterest.co.uk/alexdrinkwater/node-based-development-environments/

很多复杂软件里，都会有这种节点式的操作方式。我感觉这算是一种中间形态

[youyouyou0123456]

做过，也用过其他一些拖拽系统，国外不少公司有这种产品，阿里百度也有拖拽的系统。但是这种东西没办法通用，一般在特定的业务领域比较好做，效果的话，就是凑活，我觉得给业务用在一些不是特别重要或者内部系统上还挺好使。

[soulmt]

做过 ios 开发的话可以看看 swift 那拖拽功能都牛逼成什么样了，不依然需要代码开发， 拖拽只能解决重复性，可预见的功能， 增量可变，搞不了的，除非你写个机器人帮你写代码
不过我认为这是趋势， 将来前端应该是面向这类工具开发， 重复造轮子的日子，已经 没多久了。到时候也会洗牌前端，可能会出什么前端运营类似的职业吧

[BadAngel]

@laminux29 仅个人随便乱想，模块化项目开放固定类型的接口，添加这类需求以插件或者 mod 的形式：1.前端模块上加个皮肤 mod ； 2.网络模块上加个防火墙组件； 3.K8S 的 NODE/POD 已经可以在后台实现了吧。

[inwar]

程序系统设计一定意义就是建模,目前应该没有人能抽象出图形化的通用语言,可能通用到一定程度就会到文字编程语言一样的复杂度。建模的层次和范围限定了它的适用性,比如中间件,比如 arduino 的图形编程

[pabno]

产品经理的脑回路你是抽象不出来的

[xyjincan]

那大佬拖个微信，淘宝，京东吧

[XanderChen]

你去找 Microsoft 出品的 blend for visual studio 看看，专门用来设计 wpf 或者是 uwp 界面的工具。

别的也行，其实这种拖拽控件生成界面的工具已经有一大把了。

希望你能做出一款真正能不用写后台代码来实现各类功能的工具吧。

[murmur]

@XanderChen 不写代码实现各种功能有的是，国产所谓快速开发平台一大把一大把
这东西他是有场景的，国企什么都讲究合规，都得有个审批，今天用车，明天用船，后天用章，大后天用啥，这业务一天都没几个人用，可能就那几个人用，那这功能要写代码干嘛，拖拖拽拽上线不是最方便，不做索引坚持个几年都不带卡的

[cedoo22]

我记得 10 年之前 IBM 就有类似 通过后台管理界面点点点，直接生成系统页面和流程的一个技术， 复杂而且界面难以描述。

[momocraft]

rpg maker

[singerll]

不是不用，是不用低级程序员了，像几万块的小项目完全不用开发了。就像云计算推的数据库智能管理，大公司是用不着，小公司完全可以抛弃 dba 了

[XanderChen]

@murmur

不写代码实现各种功能，，，你提几个工具我听听，，，

[murmur]

@XanderChen jeecg，我知道的有这个，开源的，还别说各种国产定制的，连我们公司都开发出配一下就上功能的东西来，这东西很难实现么，都不用什么 nosql 动态 scheme 这么高端的技术，各种基础字段预留他一堆，什么 int1-int10，string1-string10，就可以搞定

[XanderChen]

@murmur

还不都是预先封装好的功能。

这...和我说的有什么关系吗...

搞不懂你为什么回复我...

[murmur]

@XanderChen 那你就是纠结概念么，我只是想告诉你除了可以拖拽界面，功能也可以拖拽

----------

然后下面是回楼主的，本身中台就是个折腾出来的概念，前台后台不够炫酷，里面东西一多就想分层，所以折腾出一个中台来

那么有没有拖拉拽就能把一个东西覆盖大量需求，而且稳定可靠高性能而且做到行业标准呢

答案是有的，要求很高

1 、首先每个模块要封装的足够先进，因为组合到一起，任何一个模块出问题都会成为系统瓶颈

2 、这个产品要能覆盖行业的大量需求

那么，这个东西就是最近热门讨论的，matlab 的 simulink，真的拖拉拽做实验，不写代码，而且性能不差

[XanderChen]

@murmur

好的，我知道了…

另外你回楼主你咋不艾特他…

[Cbdy]

复杂度不会凭空消失，只会从一个地方转移到另一个地方

[linZ]

@splendone 复杂需求还是不得不写代码

[mreasonyang]

简单的 M 端管理系统我觉得没问题而且现在也已经有一些方案可用了。但非 M 端的系统对性能和体验是有要求的，对于自动化系统来说这种调优能力即使是未来也很难实现。另一个就是业务逻辑复杂的系统，复杂到流程图能画两三页、各种状态机流转，这种业务如果用可视化的方法去拖拽我觉得和写代码也没什么区别了，调试和维护体验上还不如写代码，所以这种场景也是不适合的。

[vincent321]

拖拽做出来的东西 不够强大

[glfpes]

当年用 vs 拖过控件，但稍微熟悉一下就放弃使用拖拽式而直接编辑 xml 了，原因很简单：拖拽式只能最简单实现功能，稍微需要定制这些自动生成的代码可读性和编辑效率就很差。

[love]

编程信息逻辑本质无法压缩，把操作性强可版本化高可靠性的文本形式，等量转化成操作繁琐不能版本化的拖 ui 方式，这图啥啊

[laike9m]

相对于你提到的这种抽象，个人觉得 dark lang 现在的做法更可能是未来业界的发展趋势

[leishi1313]

老是在这站里看到满是各种名词堆砌，但是一点逻辑不讲的帖子

[leohxj]

可视化搭建是一个大家都能想到的中台方案而已，可用性看怎么吹了。

[MoccaCafe]

甲方只想告诉你需求，不想自己亲自用“可视化”去搭建系统，就算再智能再合理，终究是需要人手去做的

[MoccaCafe]

在资本面前，人其实是非常智能的机器，比所谓的中台可视化搭建什么的高级不少，还能随时沟通协调修改，而且费用相对来说也不是很高

[herozzm]

历史中出现过类似的拖曳设计，早期的微软开发套件和 dreamweaver 等都是这样干，还有一些 web 网站生成系统也是这样刚，生成的冗余代码实在太多了，已经被历史淘汰

[weiqk]

@wysnylc 轻钢别墅了解下，话说大部分人都不是追求软件用几十年，而是满足当前需求

[abelmakihara]

你去拖拖 winform wpf 不就知道了 产品用用拖拽还行
写代码不说冗余的 效率其实也并没高多少
还不是要写逻辑

[whywhywhy]

刚才看了下金蝶 CLOUD 的 BOS，就是无代码设计界面和 ERP 功能，自己就能把 ERP 一个个的单据配出来。

讲师在操作的时候，我看了下，它把 ERP 用到的功能拆分成很细的配置，配置一个单据还是麻烦的，但是感觉到一个好处，就是代码不用开放了，用户也能自己通过配置实现各种功能。。。。

但是遗憾的是，价格贵，配置复杂，具备这个能力的，或许自己就写代码搞定了。。。

[whywhywhy]

说真的，各个软件最核心的不是拖拽控件，还是背后的代码，拖拽只是第一步，要是能在拖拽的背后，无代码让用户配置，这样才算厉害的。

[yangbonis]

拖拽本身不也是一种码代码吗？ 拖拽真的比写逻辑简单吗？

[ericls]

楼主忽略了最大的一点，拖拽也是编程。
只是用了一种不大常规的编程语言而已。

不会写代码的人也不会拖拽。

[CuVee]

这玩意用是好用，然而开发成本太大

我之前的 2B 公司就是玩的这个

[buhi]

拖拽还太复杂了, 不够简便, 应该有一种通过语音就能直接编辑业务逻辑的工具, 可见老罗的 TNT 超前了业界十年!!!!老罗🐂🍺