低代码，要怎么低？和低代码有关的十大问题或许是因为Mendix和Outsystems的收

或许是因为 Mendix 和 Outsystems 的收购及融资，还有 Gartner/Forrester 的鼓吹（Gartner 甚至预测 4 年后低代码开发会占应用开发的 65% 以上，你敢信？），这两年低代码忽然开始受到关注，不少公司在开发这方面的产品， jabdp平台就是这样的一种低代码开发平台。本文将谈谈我对低代码的理解，尝试回答这个 10 问题：

低代码是什么？
之前是否有低代码平台？它们是怎么做的？
低代码究竟能解决什么问题？
低代码平台适合用在什么地方？
低代码平台会带来什么新问题？
低代码平台的难点在哪？
前端如何低代码？
后端如何低代码？
低代码平台是否会大量取代研发？
未来会怎样？

低代码是什么？按维基百科的说法，低代码这个称呼是 Forrester 在 2014 年提出的，指那些用可视化方式创建应用的平台，特点是代码量比传统开发少得多，甚至无代码，所以能显著提升开发效率。
这个定义比较模糊，使得低代码平台有各种各样的形式，我见到的就有以下几种：

在线 IDE 和编辑器，界面方面虽然有可视化设计，但需要二次开发才能用。
提供一站式开发平台，提供了持续集成、部署和运维等功能，包含开发全流程。
简化前端开发，界面方面可以做到不用写 JavaScript 。
简化后端开发，可以在线设计数据结构，并实现增删改查功能。
彻底简化前后端开发，甚至变成无代码平台，什么都可视化编辑，易用性好，但牺牲了灵活性，这里面有很多子分类，比如 BPM、OA 系统、APP 开发等。
围绕某个成熟产品扩展功能，比如 CRM、ERP 之类的产品，为了满足定制需求，提供定制开发功能。

为什么会有那么多种形式？在我看来主要和团队定位有关，有个「康威定律」是这么说的：
"设计系统的架构受制于产生这些设计的组织的沟通结构。 " ——M. Conway
比如公司内有两个独立的小组，那整个系统设计肯定会划分出两个独立的模块，相互之间有明确的界限，这也影响了对于低代码平台实现方式的选择。
如果是前端团队，一般会选第 1 种形式，很少考虑第 3 种，因为团队成员都会 JavaScript ，没必要弄个不用写 JavaScript 的产品，更不会考虑第 4 种，因为不负责后端开发。
如果后端的团队，就会选择第 4 种，因为只负责后端开发。
如果是大公司内的工程团队，因为职责是负责开发环境，所以会选择第 2 种形式，但这种形式一般有很多定制功能，并且依赖公司内部基础设施，导致只能在内部使用。
如果是创业公司，往往会选择第 5 种形式，面向外部当然是前后端都封装起来更简单，但可能过于追求「无代码」，导致虽然用起来简单，却失去了灵活性，只适合简单应用。
如果公司本身有成熟产品了，自然是选择第 6 种方式，围绕这个产品来扩展更有优势。
因此下次在了解一款低代码产品前，先了解它背后是什么团队，擅长做什么，团队背景将在很大程度上决定这款产品的侧重点。
之前是否有低代码平台？它们是怎么做的？在低代码这个名词出现前早就有各种提升开发应用效率的产品了，比如我知道最早的是 FileMaker ，它在 1985 年就出现了，发展历史几乎和这几十年的计算机技术同步，最早是 DOS 下的程序，苹果推出 GUI 操作系统 Macintosh 之后改成了 GUI 程序，在 2010 年移动时代推出了手机版的 FileMaker Go ，然后在 2016 年推出了云上版本 FileMaker Cloud ，最新版本又加入了人工智能。
FileMaker 最初定位是个数据库，但它在数据库的基础上扩展了应用开发功能，使得可以基于它开发应用，比如下图是用它编辑应用界面的例子：

文章插图
FileMaker
类似的还有 Microsoft Access ，也是非常古老的软件， 1992 年就发布了：

文章插图
Access
Oracle 在 2004 年也搞过一个叫 APEX 的东西，基于向导的方式生成几种固定模板页面，虽然灵活性差但用起来简单，最近也改叫低代码了。

文章插图
Oracle APEX
另外就是Visual Basic 6.0 ， 1998 年发布的，功能比现在的许多低代码平台都强。