共计 1220 个字符，预计需要花费 4 分钟才能阅读完成。
你是否听过低代码？你是否晓得最近几年低代码十分火，国内外产品十分多？你是否试用过一些低代码产品，冀望很高却悲观而止？我也一样！我试用过不下 10 种低代码产品，论断是：国内的低代码产品，以后只是玩具！
说他们是玩具，并不是说他们没有价值！玩具也有玩具的价值。他们的确能解决一些特定场景问题，比方，做一个产品问题收集表单、或者做一个办公用品申请流程等。
低代码——不应该只是玩具
低代码不应该只是在蛋糕上加颗樱桃，还须要提供生产蛋糕的能力。低代码须要解决企业的业务问题，提供生产加工的整套能力，能力真正为企业的数字化转型赋能，空有樱桃，而无蛋糕是会饿死的。
收集表单的场景太系统，并且从业务上讲，收集来的数据须要进一步解决，这时该怎么办？如果企业做了一堆收集表单类的所谓低代码利用，一个利用就是一个烟囱，这无疑会加剧企业应用烟囱的景象，与企业数字化转型南辕北辙。
办公流程类的场景，最合适的自定义形式，是在办公软件的平台下来做，而不是应用独自的低代码产品。
低代码产品呈现的真正价值是进步研发效率，升高研发的准入门槛，解决真正的业务问题。低代码火的一个要害市场驱动因素，是企业数字化转型须要大量优质开发人员，而市场的供给方无奈满足。那么，解决这个问题有 3 种思路：
- 进步研发人员的效率
- 升高研发人员的门槛
- 让业务人员本人开发
第 3 条思路就是当初的“表单 + 流程”类的低代码产品的思路，我认为第 3 条思路最不可取，业务人员能够做一些最简略的自定义，一旦须要进一步自定义，“表单 + 流程”类的低代码产品顾此失彼，业务人员也没有能力做进一步的自定义。
什么才是业务？
业务是：业务对象 + 业务操作（名词 + 动词），是主谓结构的短语，比方用户治理、订单治理、商品上架、商品购买等。从认知心理学上，人类天生就辨别名词和动词。所以，你会发现，所有的 IT 零碎全部都是业务对象 + 业务操作，这合乎人类写在 DNA 中的直觉。而表单 + 流程的低代码产品做不了这样的业务，下图比照一下。
真正能解决业务问题的低代码产品，应该具备如下特点：
- 可视化便捷操作（这是低代码的标配）
- 能反对业务对象 + 业务操作（这是能解决业务的标配）
- 面向开发人员，进步开发效率
- 必要时能与代码混用
下面曾经提到，低代码平台必须提供足够的灵活性，最高的灵活性是能不便地切换成代码。Salesforce 也提供了很高的灵活性，用户能够应用代码自定义，然而，用户须要学习 Salesfoce 借鉴的编程语言 Apex。最优的形式是，用户能够应用本人相熟的编程语言、编程框架进行自定义。
最近，发现了新产品 StarOS，它可能将低代码与代码混用，如下是一个电商利用，将它设计成一张能够间接部署成利用的架构图。该架构图中，front-end 是利落拽实现的前端，goods、user、order、pay 是应用代码实现的后端，它们提供 API。前端设计完页面，绑定后端提供的 API 即可。
丢个官网，有趣味可理解下：StarOS- 官网：http://staros.cloud/
