或许是因为Mendix和Outsystems的收购和融资，以及Gartner/Forrester的提倡（Gartner甚至预测低代码开发占比将超过4年65%的应用开发，你信吗？），低代码这两年突然受到关注，很多公司都在开发这方面的产品。本文将谈谈我对低代码的理解，并尝试回答这10个问题：什么是低代码？以前有过低代码平台吗？它们是如何制成的？低代码能解决什么问题？低代码平台适合用在哪些地方？低代码平台会带来哪些新问题？低代码平台的难点是什么？如何对前端进行低代码化？如何对后端进行低代码化？低代码平台会在很大程度上取代研发吗？未来会怎样？什么是低代码？根据维基百科，低代码一词是由Forrester于2014年提出的。它指的是以可视化方式创建应用程序的平台。它的特点是代码比传统开发少很多，甚至不用代码，因此可以显着提高开发效率。这个定义比较模糊，这使得低代码平台以各种形式出现。我见过的有以下几种：OnlineIDEsandeditors。界面虽然有可视化设计，但需要二次开发才能使用。提供一站式开发平台，提供持续集成、部署、运维等功能，包括开发的全过程。简化前端开发，无需编写JavaScript即可完成界面。简化后端开发，在线设计数据结构，实现增删改查功能。彻底简化前后端开发，甚至成为无代码平台。一切都可以可视化编辑，易用性好，但牺牲了灵活性。有很多子类，如BPM、OA系统、APP开发等。围绕一个成熟产品扩展功能，如CRM、ERP等产品，为满足定制化需求，提供定制开发功能。为什么有这么多形式？在我看来，主要是跟球队的定位有关。有一条“康威定律”是这样说的：“设计系统的架构受制于产生这些设计的组织的沟通结构”。——M。Conway举例来说，有两个独立的团队，整个系统设计肯定会分成两个独立的模块，彼此之间有明确的界限，这也影响了低代码平台实现的选择。如果你是前端团队，一般会选择第一种形式，很少会考虑第三种形式，因为团队成员都懂JavaScript，没必要创建一个不需要写JavaScript的产品，更不用说考虑第四种形式，因为他们不负责后端开发。如果你是后端团队，你会选择第四个选项，因为你只负责后端开发。如果是大公司的工程团队，因为职责是负责开发环境，所以会选择第二种形式，但是这种形式一般有很多定制功能，依赖于公司内部的基础设施，所以只能在内部使用。如果是创业公司，往往会选择第五形态。当然，对外封装前后端更容易，但可能过于追求“无代码”，导致使用简单却失去了灵活性，只适合简单的应用..如果企业本身有成熟的产品，自然会选择第六种方式，围绕这个产品进行扩张更有优势。所以下次在学习低代码产品之前，先了解它背后的团队，它擅长什么。团队背景将在很大程度上决定这款产品的侧重点。以前有过低代码平台吗？它们是如何制成的？在低代码这个词出现之前，已经出现了各种提高开发应用效率的产品。比如我知道最早的是1985年出现的FileMaker，它的发展历史几乎和这几十年的计算机技术同步。它是DOS下的程序。Apple推出了GUI操作系统Macintosh，然后将其改为GUI程序。2010年移动时代推出FileMakerGo移动版，2016年又推出云版FileMakerCloud，最新版加入了人工智能。聪明的。FileMaker最初的定位是数据库，但是在数据库的基础上扩展了应用程序开发功能，可以基于它开发应用程序。比如下图就是用它来编辑应用程序界面的例子：FileMaker类似于MicrosoftAccess，也是很古老的。软件，1992年发布：AccessOracle也在2004年开发了一个叫APEX的东西，它基于一个向导生成几个固定的模板页面。虽然灵活性差，但是使用方便，最近更名为low-code。OracleAPEX也是VisualBasic6.0，于1998年发布，比当今许多低代码平台更强大。还有十多年前大名鼎鼎的SaaS软件Salesforce，可以扩展领域扩展功能。可以看到界面还是web1.0时代的风格：Salesforce也有很多商业产品，几乎都有十几年的历史。它被称为低代码平台。低代码能解决什么问题？对于这个问题，有两个极端。专业的开发者会认为低代码平台是玩具，没用，而小白则认为有了这个，不知道怎么写代码就可以开发应用，但这两种想法都是不正确的。.要回答这个问题，首先根据《人月神话》中的陈述对软件开发进行分类：所有的软件活动包括：基本任务——创建构成抽象软件实体的复杂概念结构。次要任务——用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。这个分类第一次出现在作者的论文中是在1986年，可能很久没有多少人看过了。我在这里多说几句。“根本任务”指的是什么？比如你要实现一个发工资的软件，其中涉及到如何计算所得税，就必须实现个人所得税的计算方法。用什么语言来实现这个算法是“次要任务”，算法本身也是“次要任务”。Fundamentaltask”，无论用什么方法来实现，都不可能降低这个算法的复杂度。比如个人所得税有7级，那么某处一定有7个if语句。“根本任务”解决不了，因为它本身就是需求，唯一的解决办法就是砍需求。低代码平台主要解决“次要任务”，用更简化的方式实现同??样的功能。比如前面的问题，低代码平台有几种常用的方法：提供一个简化的DSL，类似于Excel中的公式。提供一个图形化的代码编辑器，类似于UnrealEngine中的“蓝图”，或者像Blockly/Scratch这样的拼图。支持写代码或外部api扩展。平台内置的实现，比如上面提到的个人所得税，平台可以有一个内置的函数来计算这个。其中，DSL方式只适用于简单的场景，因为DSL一般不具备复杂的逻辑控制和定义函数等功能。不如直接用JavaScript/Lua等成熟的语言将这些功能添加到DSL中。许多低代码平台使用第二种方法。这种方式看起来最符合低代码平台的定义，看起来也是最高的。以UE4中的蓝图为例。这是我见过最复杂的可视化代码Editor，你可以用它来写着色器和控制游戏流程：据Epic国内社区负责人介绍，蓝图在实际开发中用的比较多。我个人的经验是，这个编辑器有以下优点：方便的预览，尤其是在写shader的时候，可以立刻看到每个节点的输出，相对于代码有明显的优势。编程环境问题解决了，不用再花时间配置环境了。节点会列出参数和属性，这样你就不需要像写代码一样去查手册，直接点击修改即可。调试可以实时生效，比如拖动某个值可以马上看到效果。不容易出错，比如需要符合类型才能连接，因为整个环境是可控的，在很多细节上可以比代码报错更友好。底线：Blueprint比C++简单得多，不需要像C++那样的多年经验，因此要求不高且更容易雇用。图形化编程在3D设计领域立下了汗马功劳，如Blender、Grasshopper、Houdini、NUKE、SubstanceDesigner等，通过节点编程极大地提高了灵活性，但这些都是针对特定领域进行优化的，并不是通用的编程方式.通用编程世界使用节点编辑器是否可行？《人月神话》中也提到了图形化编程，原文说：Flowchart是一种非常糟糕的软件结构表达方式。事实上，最好将其视为Burks、vonNeumann和Goldstine试图给计算机，他们说他们设计了一种当时急需的高级控制语言。今天的流程图变得复杂了。一个图表有几个页面和许多连接点。这种表达方式真是令人同情。流程图已被证明是完全不必要的设计工具——程序员在开发之后而不是之前绘制描述程序的流程图。更根本的是，正如我们上面所讨论的，软件很难可视化。即使将流程图、变量范围嵌套、变量交叉引用、数据量和分层数据结构等图形化地表达出来，也只是表达了某一方面，就像瞎子摸象一样。本书预测10年内不会有突破性进展，但34年过去了，也没有看到重大进展。1985年，Raeder在他的文章中告诉我们，流程图最早是用于汇编语言的，因为汇编代码充满了跳跃和跳转，看的时候很容易头晕。这样的图可以让它看起来更清晰：但是在高级语言中不需要这个，因为高级语言中的代码可读性和这张图是一样的，但是用图形来表示会很乱在复杂的业务逻辑下连接。对于熟悉代码的开发人员来说，效率会有所降低。后来在《人月神话》20周年纪念版里加了这句话：流程图是程序文档中最被夸大的一种形式。详细的、循序渐进的流程图令人讨厌，高级语言的出现使它们显得过时了。所以，在这些方法中，我最倾向于第三种，就是直接通过代码来扩展功能。目前顶级的低代码平台都支持代码扩展，比如Salesforce、ServiceNow，尤其是ServiceNow在前后端都使用了JavaScript。使用犀牛引擎。如果需求很普通，可以选择第四种方式。一些低代码平台针对某个垂直领域进行了优化，集成了这个行业的很多常用功能。在同行业中，一家公司需要解决的“根本任务”，在另一家公司遇到的概率很大，所以使用这种低代码平台可以显着降低成本。比如淘宝，可以算是电商行业的“低代码”平台。它集成了各种电子商务相关功能，还提供店面装修功能，实现个性化设计。低代码平台适合用在哪些地方？什么样的应用适合使用低代码平台？目前看来最适合的场景是面向内部员工（B2E）的应用，即企业内部的各种系统和平台。虽然也有面向外部应用的低代码平台，比如创建手机APP，但只有小公司才会用，因为外部应用一般是公司的主营业务，需要高度的自主可控性，定制化需求也很多。显示要求也很高，低代码平台中的组件无法复用，只能通过自定义代码进行扩展，但如果大量使用代码扩展，还是自己开发比较好。以jabdp为例，表单列表的增删改查等常用功能，通过简单的自定义配置即可自动生成。复杂的业务功能只需要知道基本的sql语句和javascript语法就可以进行快速开发，满足他们个性化的业务需求，设计各种复杂的企业web应用。不仅可以快速提升开发效率，帮助企业节省人力成本，还可以在不失灵活性的情况下，有效解决企业级项目中经常遇到的需求变更问题。jabdp开发平台适用于大多数企业级web应用的开发，尤其适用于企业信息管理系统（MIS）、企业资源规划系统（ERP）、客户关系管理系统（CRM）、业务支持系统（BSS）、等，并根据一些经典的项目案例，提取整合各类项目模板，分享给开发者参考。开发者可以对原有项目进行修改和定制，打造属于自己的个性化企业信息化平台。低代码平台会带来哪些新问题？低代码平台虽然可以显着提升效率，但也会带来新的问题，比如可扩展性、难以支持复杂场景、性能等等，但在我看来最大的问题是平台锁定，很多问题都是这样的Bringing：平台使用自己内部独立的框架，需要额外的学习成本。该平台是一个黑盒子，不清楚内部如何实现。如果遇到BUG、性能等问题，只能向官方求助了。如果无法满足某些需求，您需要等待平台的预定升级。信息分布在各处，不如本地代码方便全局搜索。对于不熟悉的新手来说，往往要在各种界面中搜索半天，而且越强大的平台越难找到。多人协作不方便，部分平台只提供少量环境，难以做复杂的分支管理。平台后续发展未知，哪天倒闭了怎么办？谷歌4年前发布了一款低代码应用创建产品GoogleAppMaker，不仅可以可视化创建界面，还可以编写JavaScript扩展函数，但今年2月宣布关闭，无法导出。写一个，连谷歌的低代码平台都要关门了，更别说其他小公司了。为什么低代码平台不能开放？在我看来，主要有两个原因：技术上的矛盾。为了实现低代码，不得不隐藏很多不必要的细节，而这些细节有的依赖于平台的底层框架，有的依赖于平台编辑器。这些都是低代码平台的核心技术，不能开源。商业矛盾，如果可以很方便的导出，让用户可以二次修改，部署到任何地方，低代码平台就会成为离线开发工具。一个账号就可以开发出无数的应用，不利于商业化，所以甚至一些低代码平台只提供SaaS版本，只能在线使用。平台锁定问题在中国更为严重。有一种说法，古代中国属于大陆农耕文明。农业文明的特点是强调自给自足。我希望自己能自己掌握一切，不能相信别人。目前国内只有一个封闭的开发平台取得了巨大的成功。这个平台就是微信小程序。相对于原生APP的开发，微信小程序的开发成本更低，而且是跨平台的，所以其实也算是低代码。程序非常封闭，只能在微信上运行，必须使用专门的框架和工具，甚至注册账号、发布应用都要人工审核，但要靠微信的影响力和用户量微信，这些都不是主要问题。在这个问题上，jabdp低代码平台已经实现了完全开源，https://gitee.com/jabdp/jabdp。低代码平台的难点是什么？在我看来，低代码平台的难点在于如何同时满足易用性和灵活性，因为它们经常是冲突的。以低代码平台必备的可视化页面编辑器为例，如何实现页面布局？主要有3种方式：基于flexbox/float的布局，灵活但牺牲了易用性，要求用户至少懂一点CSS，否则看不懂。布局基于绝对定位。这种方法很容易使用。您可以随意拖动，但会失去灵活性。要支持多分辨率，就得在手机和PC上分别编辑，而且不容易根据内容自动展开。高的。提供水平/垂直的列容器，将它们组合起来实现各种布局。这种方法介于上述两种之间，灵活性和易用性都不算突出。它仅适用于移动或背景页面。除了布局，还有一个问题是是否支持自定义类？如果不支持，灵活性差。如果你换了一个字体，你必须在所有地方配置它，支持会导致可用性很差。不了解css的用户会发现改变一个地方会影响到其他地方。如果你想与众不同，你必须创建一个新类。,有理解成本。如此复杂灵活的可视化编辑器可能吃力不讨好，那么易用性呢？一些低代码平台追求“零代码”，让普通人也能使用，但这将面临另一个意想不到的强大竞争对手：“Excel”。对于普通人来说，Excel是一个很有用的数据库，可以添加数据、修改数据、搜索数据、排序筛选等，还可以制作图表，不用开发应用程序就可以管理数据。前段时间，在吴伯凡的课上听到一个故事。原文如下：雷军惊讶地发现，小米的整个管理体系，也就是采购部，也就是供应链部，拿着一台电脑，生产部拿着一台电脑，销售部手里拿着一台电脑，里面有Excel，三个部门打开电脑就可以核对数字。这就是小米的流程管理。同行们知道这些事情后都不相信，认为这是天下奇闻。对于一个年产几千万部手机的企业来说，管理流程就是这样，这个流程出现问题也是理所当然的。但从另一个角度来说，这个故事告诉我们，最初几年，小米仅靠Excel就能生产出数百万台手机，创造百亿营业额。因此，在很多情况下，Excel就足够了。在Excel平台上，也出现了Airtable等新的Excel类型，还有专门做漂亮表格的Typeform。甚至文档工具Notion也有一个内置的小型数据库。这类产品在易用性上远胜于各种零代码。平台。如何对前端进行低代码化？前端开发的主要工作是界面、交互和业务逻辑。FrontPage和Dreamweaver在20年前实现了可视化编辑页面，但它们生成的代码远不如手写。后来随着前端重构的流行，开发者又回到了通过写代码的方式来创建页面。现在可视化页面编辑器主要用于制作静态原型，或者官网和落地页，很少用在前后端交互比较多的页面，因为动态数据很难在可视化编辑器中展示，比如as显示yyy当ifxxx怎么显示呢？因此，界面开发效率的提升主要依赖于UI组件库。前端UI组件库早在十多年前就存在了。比如2006年发布了YUI，2007年发布了jQueryUI和ExtJS，但是这些组件库在产品线中用的并不多。想想百度搜索、贴吧、知乎、百科的各个页面，哪些东西是通用的？我能想到的只有轮播、弹出层和下拉菜单。这些在整体发展中所占的比例并不高。即使使用了，整体效率提升也不明显，所以前面说的低代码平台并不适合。用于面向用户的产品。但是在企业应用中情况就不同了。这些应用页面比较相似，大部分都是表单，更注重功能而不是个性化展示，所以更容易实现复用。在企业应用中，甚至可以简化成表格展示。第一列是时间，第二列是用户名，第三列是文本。虽然显示差异很大，但功能是一样的。如何对后端进行低代码化？在后端，低代码平台主要解决这几类问题：系统开发常见问题，如登录、账号/角色、权限管理页面路由、导航等外部系统对接，有的还提供通用协议对接各种各种数据源的数据管理，CRUD流程管理，开发运行环境最常用的就是CRUD，如何实现？目前有以下三种方式：基于表单，优点是简单易用，只需要设计表单即可使用，缺点是灵活性弱，难以支持复杂的关系.基于数据模型，首先需要定义数据模型。优点是灵活，但易用性差，非开发者使用会有成本。提供BaaS服务，例如开源的Parse，通过提供友好的API实现用户管理、数据访问等功能。这种方式需要编写后端代码，但灵活性高。低代码会在很大程度上取代研发吗？不，原因如下：如前所述，低代码不适合开发面向客户（toC）的应用程序。在很多公司中，这部分是最耗费人力的。对于企业内部的应用，低代码可以显着提升效率，但是效率的提升带来的不是人员的减少，而是需求的增加。众多中低档优质项目终于上榜。低代码平台无法解决“基础任务”。图形化编程只适用于特定场景。用它来控制流程还不如写代码，所以还是需要研发的。未来会怎样？我个人的判断是：图形化编程只能在特定领域取得成功。目前看来主要是音乐和图文相关的软件。普通用户免代码平台的开发会受到限制，很多时候还是用“Excel”比较好。对于成熟的垂直行业，购买软件是最便宜、最有效的选择。low-code在国内和国外会有明显的区别。中国更喜欢私有部署而不是SaaS版本，技术锁定将是国内推广的最大障碍。低代码平台不适合开发面向客户的应用程序，将来也不适合。【小编推荐】【开发记录】VPS从头搭建鸿蒙OS编译环境！【开发板试用报告】HiSparkWi-FiIoT智能家居套件开箱试用报告物联网安全基金会推出行业协同漏洞披露平台我该怎么办？
