你如何看待无代码运动？

[moremoney]

这些应用程序 /平台使非开发人员能够解决一堆原本需要软件工程师的问题,这是范式转变吗？

无代码工具生成的代码总是更复杂，因为它包含了无代码开发环境 + 设计工具 + 解释器或运行时 + 集成器 + 实际生成的代码。如果出了问题，所有部分可能都需要排查。

无代码工具最好只用来生成原型产品。当你确切想清楚想要什么，再找程序员将它写出来，这样可能更快，有利于以后的升级和排查。

[qq73666]

参考无人超市

[Leonard]

看成无码运动

[abigeater]

我认为这总归是好事，能把重复的可配置的事情交给非专业人员也能做。
但是如果考虑到如何培训开发者以外的人使用这一工具，最后使用的可能还是交给了开发者去做了。（例如现在的我）
（后面两句话还挺眼熟的）

[leven87]

简单的应该可以，复杂定制化的东西比较难。

[christin]

那生成无代码工具是不是代码开发出来的？

[Cbdy]

软件工程没有银弹

[jorneyr]

特定业务需求很好用。

[sgissb1]

资本家又多了一个打压程序员工资的理由和借口了。
培训机构又多了一点焦虑贩卖的理由和借口了

[gimp]

无码开发推荐个仓库： https://github.com/kelseyhightower/nocode

[ch2]

ASP.NET：历史是个轮回

[Macstu]

我觉得最后还是让开发人员去使用无代码工具去进行开发才是最可笑的. 这跟纯代码开发相比 , 优势很大吗? (当然 , 前提是当前团队的纯代码开发工作已经完成了工具框架高度封装以及云原生) . 只能说这是另外一个软件开发的另一个极端 . 也不能否定 , 特定业务领域让非技术人员使用组件生态及其丰富低代码平台(不是无代码) , 会很好提高迭代效率.

[Chad0000]

@ch2 #10 我正好也要说这个了，.net 这边已经吸取教训重归简化了，那边无代码又开始搞复杂化。个人目前不看好低代码。

[coderluan]

我希望迅速普及，培训班大量推广，想入行赚快钱的人大概率会去选择做这个，然后让他们往死里去卷，然后真正喜欢写代码的人的环境反而会好转。

[murmur]

无代码本身就是面向中小企业开发的，场景非常明确，需求也很切合

[whywaoxaks]

即使日后 codeless 真到了“能用”的级别，那么能把 codeless 玩儿出花的人，也必然是本站诸位啊。
就好比传武大师说，如果允许插眼、踢裆的话我就可以和泰森打了。但是泰森掏裆的威力不是更大么。

[clf]

无代码工具其实本质上就是把代码语言变成了图形语言，相对的业务层面的工作不会减少。反倒是由于需求的深入，需要额外的对开发平台进行升级，你需要先让平台支持某种特性后，再用平台去实现业务功能。

[chendy]

对于甲方，引入低代码工具开发简单需求，降低成本
对于乙方，减少简单需求对大块需求开发的影响，提高效率
受伤的是只能做简单需求的供应商，或者被迫加入低代码开发的代理商

[charlie21]

在人力成本极低的地方，所有能变成劳动密集型的都会变成劳动密集型的安排，非劳动密集型安排是永远不可能成功的，永远。

[cpstar]

事物有因果，因果倒置，所以就不能被理解了。
@Macstu 11# 说的对，低代码 /无代码要弄清楚给谁用。它不是因，而是果，不是给 coder 的果，是给业务实践者的果。那么因从何来，代码框架、代码复用的事情暂且不说，放在更宏观的维度上，因来自快速变化的业务——业务变化导致开发人员跟随业务变化，一旦用术业解耦来解决这种变化，那势必带来信息传递的衰减、业务效率的下降：我这都有新需求了怎么你们程序员还没把老的弄完。

What if ，如果，如果业务人员掌握技能，直接搞“开发”，实现自己的业务，那简单维度上是不是提升了效率，同时复杂维度上业务人员还能够良好（被逼地）设计自己的业务呢？

换句话讲，码农也别骂产品经理了，NB 的话你写一套东西，让产品经理自己搞。因果自清。

[timethinker]

越灵活的系统就越复杂，到一定程度实际上也是在进行编程的工作，只是过去是写代码，现在是另外一种形式，至于效率高低就仁者见仁了。

抽象程度越具体化，则它的应用范围则越窄，而高度抽象的系统本身也不容易使用，需要有一定的专业知识和使用经验。作为应用层来讲，当然可以使用已经定义好的简单抽象 /组件，而这些简单抽象来自于更高层面的抽象，所以为了解决复杂性，仍然存在层次，层次越高（封装得越多），则要求更低，使用门槛自然越低。