慎重！小公司到底要不要搞自己的低代码？
当前位置：点晴教程→知识管理交流
→『 技术文档交流 』
同学们好，我想结合自己的亲身经历，谈谈我对低代码开发的看法，讨论下人手和精力本就有限的小公司到底要不要搞低代码（中大厂无论资源还是KPI，并不在讨论范围）。 我对低代码最直白的理解通过可视化拖拽来快速搭建某个场景的工具，以实现降本增效 市面低代码有哪些？某个场景这个词很广泛，我们根据某个场景设计了各种低代码平台 单一场景
全场景除了上述单一场景低代码，还有一种并不是只想做工具。而是要做全场景、无限自由度的通用型低代码平台。 其中代表作，肯定大家都很熟悉，阿里的lowcode-engine。
什么是低代码毒瘤？就是不少低代码平台用户（技术）的使用反馈
我眼中的低代码回到开头，我理解的低代码
它就应该像一把手术刀（工具），为消除某个病瘤（某个场景），精准、简单、快捷的解决问题（降本增效）。 而不是造一个可视化的编辑器，先用可视化编辑器先去构造场景，然后再在构造的场景上开发，这在我看来是本末倒置。 强如lowcode-engine，阿里一个团队****开发了几年，都定义了schema协议标准，大家使用都是吐嘈声一片。可见这不是技术原因，而是设计原因。从为业务提效的工具改为了提效程序员的编辑器。 切忌！不要为了一口醋，包一顿饺子。 我认为低代码以程序员为用户去设计低代码产品注定会失败，这几年低代码毒瘤的评价就是一场大型的社会实验，这就是用户（程序员）最真实的反馈。 我理想中的的低代码：
我的结论是，如果那么复杂的场景，物料拖来拖去，逻辑链上百个节点，不如cursor一句话... 这是我的黑历史，也是我的来时路转行前端：低代码熟练工最早受害者我2017年大学毕业，原本学的是Java，在南京面试并入职了一家公司做后端开发。 当时公司招聘了大量应届毕业生，我本以为是因为业务发展迅速，需要大量研发人员。然而入职后才发现，公司后端开发并不使用代码开发，而是通过公司自研的一个逻辑编辑器进行开发。这个编辑器采用拖拽节点、搭建逻辑链的方式来实现后端业务。我们平时写的一句代码，实际上就是一条逻辑链，独立的方法构成一个独立的父节点，节点之间再相互串联。之所以招聘这么多人，是因为公司离职率极高，每年大约只有20%的人能留下来。公司通过这种方式，逐年筛选出逻辑编辑器的熟练工。 我干了两个月后，实在无法适应，准备离职。但当时招聘季已经结束，只能暂时忍耐。转机出现在公司的低代码平台——它只支持后端开发，前端仍然需要编写代码。前端组也在招人，于是我谎称自己会前端，成功转到了前端组。但实际上，我当时只会一点Vue基础，完全不懂前端开发，只能从头学起。最终，我从后端彻底转成了前端开发。 在大半年后，我跳槽去了另一家公司。就在我准备离职时，公司其他部门的前端组也开发出了类似的低代码平台。我试用过，虽然非常难用，很多操作反人类，但公司也打算仿照后端的模式，每年招聘前端应届生，逐年筛选出熟练工。 可以说，我们这波人是国内最早被低代码迫害的那批开发者。因为我亲身经历过，所以我很明确地告诉大家：有些公司开发和推广低代码平台的目的，并不是为了提升业务效率，而是为了替换掉研发人员，转而使用一些廉价的低代码平台的熟练工！ 这简直从根源上实现了节流，对他们来说也是增效。 开源之旅：构建我理解的低代码平台了解我的同学可能知道，我是低代码开源项目Mall-Cook和云搭的作者，既然我已受过低代码的迫害，那为什么还要开发低代码？ 因为我想还原可视化拖拽搭建降本增效原本的魅力。 我的的研究很明确，就是开发普通人（产品、运营、不管会不会技术的普通人）在某些场景（H5、问卷、图片、商城等）能简单、快速搭建的工具（有用的才算工具，如果只是KPI产品，合格的软件我认为都不算） 五年磨一剑，三代铸巅峰我公司是一家做文旅的小公司，而公司的业务恰好是我低代码项目落地的最佳场景。 在过去的五年，我独立开发了三代低代码项目，在项目我都会开发完成后。都自荐接入公司的实际项目中，通过用户实际使用的反馈，不断的优化和扩展。 H5-Generate我自研第一代低代码平台，当时仿照鲁班花了3个月自己搞了一个H5生成器，用来搭建生成活动页H5。 最初的试水之作，现在看来很简陋、使用体验也一般，也没信心开源出来献丑。不过我接入公司文旅小程序，支持了我们当时拳头产品数百个活动页的搭建。
Mall-Cook自研第二代低代码平台，突破只能搭建H5的桎梏，支持搭建H5、小程序、APP任意端页面搭建。 开源地址： 链接
Mall-Cook旨在开发一个供运营、产品快速搭建商城的可视化平台。其实现了可视化页面搭建、组件流水线式标准接入、搭建页面多端生成（H5、小程序、APP）、运营/产品低学习成本维护等特点。
Mall-Cook是我承上启下的开发项目，在项目开发完成后，在当时我还是比较满意的。 所以把项目进行了开源，并向公司自荐由Mall-Cook替换掉H5-Generate，支持公司后续项目的可视化搭建需求 Mall-Cook在开源和公司都取得了很不错的成绩，真正让普通人去做了部分研发需求做的工作，真做到了我所希望的降本提效。
云搭自研第三代低代码平台,大成之作，云搭万物，触手可及！ 云搭平台： 链接 开源地址： 链接 介绍文章： 链接
云搭是一款功能强大的可视化搭建解决方案，它支持零代码搭建小程序、H5、问卷、图文文章等多种应用，致力于提供一套简单、便捷、专业、可靠的多场景可视化搭建平台。 我愿景是让所有用户（无论会不会技术的普通人），使用云搭可以简单、便捷搭建各种应用。
平台功能
通过一代代的产品，解读我眼中的低代码我对低代码的理解是通过可视化拖拽来快速搭建某个场景的工具 那我设计云搭的理想就是，通过可视化拖拽来快速搭建多个场景的工具库 回到当初那句话，这几年一步步走来，我始终坚信实践是检验真理的唯一标准，我理想国也从未变过...
小公司到底要不要搞自己的低代码？
小公司不是那些中大厂，是不会成立项目组来做这些。在人力和精力有限的情况下，如果是固定场景的话，可以找市面上成熟的平台仿照开发，如果是想用lowcode-engine来打造公司通用型平台，直接拒掉... 真实案例除了我司，我再举个真实例子（大道理谁都会说，我始终坚信实践是检验真理的唯一标准） 古茗的前端团队 古茗在面对门店几百张菜单，经常更新的业务现状
开发门店菜单智能化平台搭建电子菜单，切实的实现增效
还是我那句话，它就应该像一把手术刀（工具），为消除某个病瘤（某个场景），精准、简单、快捷的解决问题（降本增效）。 不为解决实际问题开发它干嘛？不如不做... 巅峰看到虚假的拥护，黄昏见证真正的忠诚我从低代码还未大火时便开始研究，见证了它的崛起与沉寂。巅峰时，无数人追捧，仿佛它是解决一切问题的灵丹妙药；而如今，热潮退去，许多人选择离开，我还是孜孜不倦的探索我的眼中的低代码。 写这篇文章就是想对低代码祛魅，拨开层层糖衣看看它真实的模样。它没外界吹捧的那么无所不能，但也并未一无是处。 一去数年，我仍在低代码的道路上独自求索，构建自己的理想国。 诸君共勉 ~ 转自https://juejin.cn/post/7468621394736922662 该文章在 2025/9/10 11:51:40 编辑过 |
关键字查询
相关文章
正在查询... 
|
400 186 1886
