©2020-2024 ioDraw All rights reserved,
Privacy Policy
对于低代码早有耳闻，一直没更进一步花时间了解，借着这次探讨学习的机会，翻了些资料再试用了几个平台，浅显谈谈对低代码的理解，熟悉这块的朋友，可以一起讨论。
[ From unsplash ]
太阳低下没有新鲜事，低代码或者零代码也不是新事务，只不过用一种新概念来包装加工一些旧的工具或系统，比如Dreamweaver、在线建站系统等，透过拖拽就可以完成一些网站页面的开发，比如一些PASS平台，通过成熟的中间件或组件，快速搭建一个分布式系统等等。至于低代码、零代码或无代码的差别，从名称上大概也可以猜出一二来。
听惯了PaaS、IaaS、SaaS、BaaS，这里再提及一个：aPaaS，是PaaS的一个分支，全称为应用程序平台即服务。在国外也都有比较成功的案例，国内也有一些厂商在从事这块业务，目的就是让非技术人员也可以参与进来，进行业务系统的研发。这也是当下云计算、信息化、数字化必然涉及到的一块业务，总存在一些企业信息化能力很弱，没有专职的研发团队来进行软件开发，交由专业的厂商来做似乎是一个明智的选择。
近两年也出现一批业务流程管理类的低代码平台，相比aPaaS而言，上手入门门槛更低，短时间就可以搭建一套适用于企业业务管理系统，相比传统的研发模式，不仅省时间成本，研发团队岗位、硬件投入成本也大量减少，对中小企业而言，何乐而不为。
低代码再好也不是银弹，无法解决所有问题，在试用了国内BPM类型几个低代码平台后，简单梳理了下优缺利弊。
利
*
无须依赖开发人员，懂一定的基础即可上手开发业务系统
*
功能覆盖数据收集、报表、流程审核等常见的功能，提供通用应用模板
*
无须弄懂应用的运转逻辑、服务器运维等，全由平台负责
*
与支持的第三方应用授权绑定实现数据同步，如钉钉、teambition等
*
提供接入工具插件，提升用户体验，比如OCR工具等
*
降低研发团队人员开支，降低研发时间成本
*
在同一套低代码平台内部，各个子系统间的数据互通，降低了数据孤岛的可能性
弊
*
需要一定的逻辑抽象能力，并非面向所有人员都可以轻松上手使用
*
系统运行限定在低代码平台的云服务上，主要面向企业内部的管理系统为主，虽然少部分可以私有化部署
*
无法完美与自研系统融合，对外提供API有限，不能直接读取底层数据库
*
复杂的场景无法支持，一旦使用后出现无法满足需求的情况，只能舍弃需求
*
面向C端用户的功能应用适用性不高，与当下的小程序业态融合不够友好
一些研发过程中常见的管理系统脚手架，也被包装成低代码/无代码平台，进行对外销售。这也说明概念不断推陈出新，蹭个热度更有助于打开销售局面，提高市场占有率。
在有一定研发能力，业务场景并非简单的增删查改的情况下，通过编码的方式会更好。时下形态下的低代码已经可以帮不少中小微企业解决实际的问题，特别是传统企业的数字化转型，是一个值得尝试的方向。