lowcode 是不是在断后人的路？

[vevlins]

看到一些 lowcode 平台其实并不好用，但毕竟摆在那里，从组件机制到部署一条线全干了，甚至禁止别的部署和接入方式。技术 leader 和产品都倾向于采用现成的方案。

其实实际开发还是写组件，没什么本质区别，另外还可能受限于封闭性做一堆有难度没价值的 hack 。工程化和性能优化两条路都堵死了。前人造轮子彻底封死后人造轮子的路(组件化、打包构建、CICD 直接与你无关)，工作没成就感。个人发展和职业晋升受限，有能力的人挣扎挣扎走了，剩下能力平庸的用一套固定的东西实现傻逼的需求。

有些做 lowcode 平台的人自己也知道，做一堆封闭、全但差的东西就是要堵死别人。

[scar263]

在较长的时间尺度下看，效率更高的技术方案总是会取代效率低的技术方案（这里的效率是多维度的）。当你发现违背这个规律的现象，就得认真考虑重新对于方案的效率进行评估了。

[Marszm]

如果能用你们公司所谓的 lowcode 解决问题，说明你们的业务，这样的东西已经能应付了。。如果不能应付强行用这玩意自动化生成，欠下的债，早晚有一天会爆发，你们领导知道，但是估计心里想的是到那天自己也赚够了，或者找好别的下家了。或者，这么恶心的东西估计离开自己都玩不转了。自己就是最牛逼的。

[vevlins]

@cmdOptionKana 你喜欢这样说就这样说，这不是我定义的 lowcode，是我在腾讯工作两年见到的四五个 lowcode 平台的总结。希望你以后不会遇到这种问题，没人强迫喂你吃屎也是一种快乐。

[vevlins]

我自认为不是一个对 lowcode 没概念的人，我跟微信团队的一些大牛也讨论过 lowcode 的看法。大可不必恶意揣测我对 lowcode 没见解，是外行发言。

[Marszm]

现在很多大厂特喜欢托拉拽，为啥，应为现在互联网大厂最大运营成本就是人力开发，多搞点这种东西，那就可以少招很多人，每少招一个人，一年省几十万。所以呢，中层想晋升看到了这点，强推这玩意，上级管理层一琢磨，很有道理，必须推广。甚至做完了还能拿出去卖。。。整个搞下来，除了一些低端码农，都开心。所以程序员这行从来都是赤裸裸的达尔文进化论，没有一点人文关怀，科技的理性加上资本的贪欲，最后大家卷起来，大家一起不好过，互相伤害。

[Cotory]

lowcode 确实在一定程度上可以方便业务人员自己手动搭积木，但具体的一些细节需要编码微调的地方反而觉得 lowcode 不太灵活，让业务人员快速实现原型说明他们到底需要什么也挺不错的，简单的需求搭搭要是能完成更好，断后路的话还是不至于（说不定能一定程度上缓解加班问题

[vevlins]

我负责任的说，我定义的恰恰是一般情况下的 lowcode 。

lowcode 在目前无非是基于组件机制的一种抽象层次，组件的建设还是业务部门自己做的。抽象越多描述灵活性越差，现在的大趋势就是 toc 的 h5 页面使用 lowcode 方案解决，因为描述能力变差和系统封闭性，导致很多工作价值不好体现、花时间在 hack 原来的黑盒上。

我们需要的不是真正的 lowcode，我们得到的也不是真正的 lowcode，得到的最高的价值不过是附加的 CI&CD 罢了。组件不需要自己开发了吗？产品需求和设计稿都没实现统一，lowcode 平台那几个有限的属性得到的表现力跟原本的 web 技术栈一样吗？功能做出来了，老板以为是 lowcode 平台的功劳，只有你自己知道被喂了一嘴屎。

[yhxx]

小程序不也是这种鬼东西

[x86]

lowcode 挺好的呀，一些非 IT 行业非常的喜欢

[x940727]

说白了就是害怕 lowcode 抢你工作岗位呗……没必要，你不写 CRUD 可以去写 lowcode 平台，或者去做更接近底层或更高层的工作，嵌入式你拖拉拽总不能行吧，架构设计你也不能拖拉拽吧。

[wupher]

我觉得正好相反。

[vevlins]

@x940727 你这话说的有领导感觉！做了同样的工作量在老板看来价值却不足原来一半。我不怕 lowcode 抢我的工作岗位，我对自己的技术水平很有自信，我的工作经验和 base 在同龄人水平都是 top 的，我在为所有业务开发担忧，当然也可以包含我自己。

[Dragonphy]

lowcode 本质上是给养不起程序员的公司用的

[taowen]

https://zhuanlan.zhihu.com/p/373001720 减少样板代码为啥不受欢迎

[murmur]

lowcode 其实定位就是中小型企业应用，场景明确，上限也明确
那种一天访问量不超过 100 的功能，有必要写代码完成么？？

[leelz]

遇到定制化就不 low- code 了

[nevin47]

LZ 的担忧其实过去在其他领域也有过

非常早期的嵌入式开发，要么基于寄存器和 datasheet 直接调寄存器（甚至还可以用 GPIO 撸电平高低），要么稍微好点的也需要用厂商的 SDK 去做二次开发，但是本质上这些工作没啥营养，和 CURD 没啥本质区别

后来随着 Linux 在嵌入式领域的发力，尤其是对几个核心总线的支持的加入，很多通用性的操作全被做了高层次封装，现在基于框架做开发去完事儿了，很少有人关心更底层的实现原理了（例如新 dev hotplug 之后触发了什么中断，中断到了芯片又会转到什么中断门）。但是底层工程师依旧很多，只是关心的点变了而已

所以 Lowcode 平台本质上也是一层业务封装，CURD 是没了，但是设计架构、软件的规划等等问题，都不是 lowcode 可以解决的。

[ianva]

自己实现过 DSL 的人应该都明白，当需求越来越复杂的时候 DSL 慢慢演变成脚本语言，再往后就演变成有工程化能力语言

[www5070504]

能被 low code 占领的东西 现在不也是各种框架搭一搭就完事了么

[vevlins]

@taowen 很好的资料。我也在思考一种 lowcode 方案，跟里面有个想法比较像。通过搭建组件库-基于组件库结构化描述需求和部分生成需求单 /原型图-代码预生成，结构化页面搭建需要前置的结构化需求。不过我是做 mis 系统。

我认为更少的代码是对的，目前的 lowcode 在某些具体的业务场景下也是有价值的。但最好不要在市场上限死，也不要在能力上限死。如果提供 toolkit 那我很喜欢，如果让我走到模板里面我很抗拒。