慎重！小公司要不要搞低代码？
慎重！小公司到底要不要搞自己的低代码？
同学们好，我想结合自己的亲身经历，谈谈我对低代码开发的看法，讨论下人手和精力本就有限的小公司到底要不要搞低代码（中大厂无论资源还是KPI，并不在讨论范围）。
我对低代码最直白的理解
通过可视化拖拽来快速搭建某个场景的工具，以实现降本增效
市面低代码有哪些？
某个场景这个词很广泛，我们根据某个场景设计了各种低代码平台
单一场景
- 用来在线设计图片
- 用来搭建H5页
- 用来搭建商城
- 用来搭建问卷调查
- 用来搭建Form表单
- 审批流管理系统
全场景
除了上述单一场景低代码，还有一种并不是只想做工具。而是要做全场景、无限自由度的通用型低代码平台。
其中代表作，肯定大家都很熟悉，阿里的lowcode-engine。
什么是低代码毒瘤？
就是不少低代码平台用户（技术）的使用反馈
- 代码一句话的事，要搭建一整条逻辑链
- 再完美、再丰富的业务物料库，并不能覆盖所有业务，实际上每有新业务都是伴随大量的新业务物料开发
- 解决BUG时超难debug，你只能根据逻辑链去慢慢检查节点逻辑
- 很容易形成孤岛，你接手的别人屎山代码还能直接阅读代码理解，你接手的屎山低代码平台怎么捋？
- 我想干的是技术，入职干几年JSP我人都会废掉，更别说拖拽逻辑、拖拽组件开发页面，逼我辞职！（真实经历，导致从后端转前端，后文有详述）
我眼中的低代码
回到开头，我理解的低代码
它就应该像一把手术刀（工具），为消除某个病瘤（某个场景），精准、简单、快捷的解决问题（降本增效）。
而不是造一个可视化的编辑器，先用可视化编辑器先去构造场景，然后再在构造的场景上开发，这在我看来是本末倒置。
强如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、问卷、图文文章等多种应用，致力于提供一套简单、便捷、专业、可靠的多场景可视化搭建平台。
我愿景是让所有用户（无论会不会技术的普通人），使用云搭可以简单、便捷搭建各种应用。
平台功能
- 使用uni-app渲染器支持H5、小程序、APP的多端渲染
- 开发自定义表单系统，支持表单-列表-详情页的整链路设计方案
- 结合多端渲染与自定义表单系统，云搭设计了小程序、H5、问卷、图文文章多种使用场景
- 开发嵌套布局，提供卡片、tab等容器组件，让页面支持无限层级嵌套布局
- 内置图片实时编辑，给用户更多自由设计空间
- 开发数据分析模块，多维度统计分析问卷、表单数据
- 开发资源社区，共享用户创建的应用模板
- 内置图片库，提供1000+图片资源
通过一代代的产品，解读我眼中的低代码
我对低代码的理解是通过可视化拖拽来快速搭建某个场景的工具
那我设计云搭的理想就是，通过可视化拖拽来快速搭建多个场景的工具库
回到当初那句话，这几年一步步走来，我始终坚信实践是检验真理的唯一标准，我理想国也从未变过...
小公司到底要不要搞自己的低代码？
- 我们公司是做文旅的，活动、电商等天然就满足可视化搭建工具的增效。如果公司业务类似的部分简单场景，可以github找个相关项目或者自研个简单的工具来提效
- 如果用来搭建管理后台页面，我的意见直接是直接否掉。我的亲身例子就是，不要像我那样最后受不了煎熬，只能离职。包括我们公司只是在后台封装了通用业务组件和CURD Hooks来提效开发，新页面直接CV然后改需求，真的我感觉搞来搞去不如不如cursor一句话。
小公司不是那些中大厂，是不会成立项目组来做这些。在人力和精力有限的情况下，如果是固定场景的话，可以找市面上成熟的平台仿照开发，如果是想用lowcode-engine来打造公司通用型平台，直接拒掉...
真实案例
除了我司，我再举个真实例子（大道理谁都会说，我始终坚信实践是检验真理的唯一标准）
古茗的前端团队
古茗在面对门店几百张菜单，经常更新的业务现状
开发门店菜单智能化平台搭建电子菜单，切实的实现增效
还是我那句话，它就应该像一把手术刀（工具），为消除某个病瘤（某个场景），精准、简单、快捷的解决问题（降本增效）。
不为解决实际问题开发它干嘛？不如不做...
巅峰看到虚假的拥护，黄昏见证真正的忠诚
我从低代码还未大火时便开始研究，见证了它的崛起与沉寂。巅峰时，无数人追捧，仿佛它是解决一切问题的灵丹妙药；而如今，热潮退去，许多人选择离开，我还是孜孜不倦的探索我的眼中的低代码。
写这篇文章就是想对低代码祛魅，拨开层层糖衣看看它真实的模样。它没外界吹捧的那么无所不能，但也并未一无是处。
一去数年，我仍在低代码的道路上独自求索，构建自己的理想国。
诸君共勉 ~
来源：juejin.cn/post/7468621394736922662
