编者按：以营销为例，如今在数字化的世界里，项目管理、会员系统、拼团裂变等活动界面……哪个不需要依赖程序员的支持呢？没有技术，寸步难行。而随着「低代码」一朝风起，号称让“普通人也能开发自己的程序”，这对广大的营销人乃至各部门管理者，都有着无与伦比的吸引力。
但绝大多数企业，包括大多数低代码平台开发企业，都没有明白他们到底在做一样什么工具，给谁用、用多久、怎么用。本文是由一位亲历者撰写，通过他的视角，或许就能明白「低代码」是什么，以及它给商业世界带来了哪些机遇与展望。
作者背景：Delphi，现任某知名大型企业数字化SVP。1996年开始从事软件开发，2004年开始设计低代码平台，于2006～07年正式商用，直至今日还有不少零售企业正在继续使用。下为正文。
自从阿里“宜搭”出世，掀起了新的一轮低代码热潮，大量投资公司涌入这个赛道，据不完全统计，得到投资的低代码平台就有45家以上。作为一个资深的程序员，架构师，刚好于18年前设计过类低代码的系统，同时，目前正在为公司选型一套低代码平台作为基础开发工具，有幸又与十余家新老牌的低代码企业交流沟通，颇有心得，在此一一记录，希望能够对行业的发展有所助力。
2004年，正值笔者为某大型零售企业开发ERP系统，一次偶然的代码Bug，让我重新审视自己当时近6年的开发成果：订货模块的子版本号是163。也就是说，这个模块从最原始的版本，已经有了163次迭代，不禁拍案而起：
这个世界，要么是客户错了，要么就是我错了！
为什么要改这么多次？主要是因为这个客户在大半年内换了6个VP，每个新人都有自己的一套方法论和习惯，因此订货单的审核功能从 1、2、3、4、5（管理审核逻辑），换成了 1、2、3、6、7，又换成2、3、4、6、8，接着换回了2、3、4、5、6。如果软件的功能一直被封装在代码里面，那么，这种迭代似乎永无止境。
这时我自然萌生了一个念头，是不是可以把软件的界面和功能分开，把最常见的各层级「1、2、3、4、5、6、7、8……」做成一个一个的插件，根据客户的要求，打勾即可，如果我能够穷尽所有的可能，大概也就是20来个吧，以后是否能够满足绝大多数客户的需求？
因此在2004年开始了第一个版本的开发，那时候我开的车是广本飞度，英文名FIT，因此我也给这个平台起了个简单的名字Fast Integration Tools，简称也是 FIT。大概三个主力程序员，半年的时间，完成了第一版的迭代，我记得第一个白鼠客户是广州的某知名直销平台，第二个则是那个频繁换将的零售商。如果现在百度关键词“Fast Integration Tools FIT”第二条就是当时我在联商网打的广告。
当时的设计是为了给乙方打造一个开发平台，可以面对客户频繁变动的需求，做一些有沉淀有积累的开发，主要用户是乙方具有业务能力的开发人员，未来还能给甲方自己的技术人员使用。
设计之初就提了几个要点：
一、 为了性能考虑，尽可能只使用SQL（编者注：简而言之，SQL是一种比较容易的、学会就能操作数据库的语言，而下方提到的Java和.NET则是编程语言。），毕竟当时零售商能招募到的技术人员也就是懂SQL的，你要是会Java、.NET，早就被互联网公司挖走了。
同时，SQL保证了程序执行的效率和性能是最高的，毕竟当时的主流CPU还是奔腾4，性能实在有限。后来这也成了这个平台最大的瓶颈，当然没想到现在又在TiDB和PolarDB（阿里云主导研发的关系型云原生数据库，在云上不必考虑硬件性能问题）上焕发了第二春。
二、 平台设计的核心在于：尽量通过配置而不要重新编译代码！这样最大限度地保障了灵活性，降低了发布的成本。
三、 平台必须自带文档管理。因为一旦文档与代码分开，那就是再也没有相见的时候，谁拿到了代码，都不可能搞清楚为什么有这么一个奇怪的功能，是谁提出来的，在什么时候才会被用到，所以，必须有一个随代码一起密不可分的文档体系。
四、多语言。这是我的个人恶趣味，因为之前有人承诺我中国的零售软件一定可以走出国门，另外至少看上去很酷（后来该零售商真的找了一个老外做VP，他看到软件可以瞬间转换为英文版很是高兴，立刻问我能不能搞法文的……）。
五、性能可以被监控。因为零售商有限的硬件预算和海量的数据，软件最容易被诟病的就是性能，而且一个错误的SQL往往带来的就是性能的灾难，因此，需要可以快速定位性能问题至具体的细节点。
六、其他的一些显示标签必须一致、编辑条件必须可控等等，凡是涉及到程序员经验带来的Bug，都尽量能够统一管理，防止经验性错误，当时是拿着测试部门的Bug清单分类来一一要求做到平台里去的。
七、以上都是工具类的要求，核心对业务的要求就是抽象，把业务抽象为三大类，业务对象，业务逻辑，查询表单。通过对这三大类的抽象，基本覆盖了95%的零售业务需求，也就是说，在这95%之内，无需编译，只需要在工具中配置即可。
在系统上线过程中，又陆续添加了一些小的功能，例如
1. 一键生成HTML的文档导出，可以满足ISO9000审核的要求；
2. 版本管理，一键导出测试单元，满足开发环境——测试环境——正式环境部署的要求；
3. 自动测试脚本，多数据库支持；
4. 在还没有云计算的当年，都是客户机服务器环境的C/S架构，因此，还增加断电保存功能，你在本地录入的几十几百条记录，断电后还能够恢复；
5. 快速录入，专门针对那些盲打录入数据的专业人员，也支持从Excel直接粘贴大量数据录入表单。
后来随着系统的升级，增加了.NET的版本和Java的版本，可能因为那时候IDC投资比较火吧，哈哈，软件也改名为IDC（Intelligent Deployment Center）。这时候大概是2008～2009年，与此同时还有一些个人开发的基于Sybase Power Builder一类的开发平台，也都有了低代码平台的雏形。
说了这么多，我们再来看一下国内外低代码平台的发展：
大概在我设计FIT的同一年，远在美国的Oracle也开始了他的工具APEX的开发，异曲同工，都是基于数据库，抽象了业务、集成了工具，到目前为止已经有7～8次大的迭代，有几十万人的社区在这个平台上进行开发。
国内的软件公司如用友、金蝶，也一直有自己的开发平台，但是一直是内部使用，配置要求对数据库结构非常熟悉，也不是真正意义上的低代码平台。
随后，云平台浩浩荡荡，势不可挡地来了。
云平台最大的特点是什么？其实是算力的低成本化，在云上，算力越来越不值钱，因此原来你挖空心思去做的性能优化，突然就不再有太大意义，这时候，随着容器化、微服务的兴起，摆脱了性能的桎梏，低代码又变成了炙手可热的好概念。
本次选型，深入了解了十几家低代码平台，以下做个总结：
一
低代码平台大致分为两类，一类是以UI入手，从操作层面开发，偏向简单易用，立等可取，快速做一个表单以及录入界面，灵活无比，通过与企业IM工具的集成，可以非常高效的建立起一些用完即弃的功能，比如所有低代码厂商都特别喜欢拿来展示的防疫信息录入…….第二类则往往是传统ERP或者行业软件开发商设计的，从标准的建模、拖拉拽画界面，到完成一个模块的开发，往往有灵活的权限控制和复杂的逻辑可以进行配置，一般是面对企业内开发人员。
二
谁来用？大部分低代码平台并没有想好到底是谁在用，开发出来的系统又是谁在用，怎么用。包括阿里腾讯在内，只是基于有限的思维设计了一个“瑞士军刀”，你说他不行吧，他貌似啥都行，你说他行吧，深入一些就会出问题。
举个例子，低代码平台常喜欢说的，我们可以让业务人员自己开发软件。其实，做软件时间稍长我们就知道，业务人员有Excel，缺点是不在线，无法多人共享，其他灵活度方面比啥都强。同时切记，业务人员即使是在用一个标准ERP软件，我们面临的最大问题绝对不是开发问题，而是维护问题。
但凡做过软件运维的人都会碰到一个令人痛苦的场景：业务小姑娘愁眉苦脸地告诉你，她录错了单据，而且，这是在一周以后才发现了，需要你帮她把数据修正过来，她甚至可以请你吃饭。
source：pexels
是的，这才是低代码平台最痛苦的问题，软件不是做完了拿来秀的，过了测试与交付就和你没有关系了，后面需要有人让它健康的活下去，而这正是几个没有经过任何专业开发训练的业务小朋友就想搭建一个软件的最大问题。
三
那么软件需要什么？是的，标准的CI/CD，标准的Devops。目前看到的低代码平台里，很多还不具备基本的开发——测试——灰度——部署，他们强调的就是我能直接快速修改。试想，一个已经有5000条各种数据的小软件，你今天要升级软件功能，难道是简单的在界面上修改一下就可以的么？数据的一致性怎么保障？新增加的逻辑，可能和之前的数据逻辑有冲突怎么办？如果置之不理，那么，之前的5000条数据，混杂了后来增加的3000条数据，谁还敢用？
不管你是不是低代码，不管用户用不用，你至少需要一个开发环境、测试环境、正式环境的部署体系。专业的程序员尚且会出错，你让业余的业务人员去写一个稍微复杂的逻辑，不加测试就部署上线，后面只会带来无尽的烦恼。
有部分低代码平台提供了Devops平台和开发测试上线环境，但是能提供自动化脚本进行测试的还很少，可能大家认为这个还不那么重要吧。
四
云计算，就真的不需要考虑性能了么？目前除了少数的几家有着深厚的传统ERP沉淀的企业，大部分人真没有把性能当成一回事。当我问到能否在发现性能瓶颈后立刻定位到具体的逻辑或者流程环节，大部分企业是无法做到的。
不过想想也是，业务人员写的逻辑，能复杂到哪里去。更何况，80%的场景，数据量不会超过10万条，剩下的20%场景，可能加个服务器就好了，按双十一的打折价格来说，一个程序员一个月的工资，可以部署十台！两年！
不过，服务器要用电，会消耗碳排量，我们还是应该稍微环保一点吧？
说句实话，几乎目前所有低代码平台都用上微服务、Docker了，但是怎么用呢？其实就是核心引擎是一个微服务而已，完全没有从业务逻辑、流程这个粒度进行拆分并为之分配docker，这个问题不致命，只能说是一个遗憾：这样相当于放弃了一个巨大的机会，一个用低代码平台重构大型复杂系统的机会。
五
随行文档，这个问题真的没有人考虑过，一家都没有。反正低代码好开发，人走了？重写一遍吧，谁去管老代码怎么继承怎么重用。作为一个正统程序员，这个问题刚好是我最关心的，试想，一个公司，你接手了一堆系统，一看，低代码写的，挺好，但是，但是为什么这里有一个奇怪的流程与逻辑？问了所有人，没人知道为啥，当你顺手删掉以后，结局就是下周财务跳到你面前，大声质问你为什么突然税务数据全部乱了。呵呵，当时那个逻辑加的那个标识位，就是为了在特殊情况下处理这个不起眼的税务要求啊。你估计会立刻和我深有同感：“文档一定要跟着代码走！即使是低代码！“
随行文档，意味着在设计低代码平台时，就考虑到了业务部门为此提出的各类需求同时会被记录下来，谁、什么时候、提出了什么样的需求，又是谁审核过了？同时，开发又提供了一个什么样的新的状态位来记录这个状态，从而为后面不知道躲在哪里的一张报表提供了依据。
千万别说有一个word文件或者某个网站文档管理工具已经记录了，我们都知道，那个是胡扯，他们的关系和渣男的感情一样，半年内一定会随风而逝。
六
多语言，很多低代码平台没有考虑这个问题，情有可原，国内市场还没做完呢，但是请不要用“你可以给这个字段标签用中文+英文方式设计呀“这样来敷衍，你试着找一台英文电脑，你就会发现英文前面你加上的中文只会显示为乱码，不知道有多么影响心情。
有部分平台提供了多语言的一个配置环境，但是一看就是没有做过项目，好，我这里再说一遍，一个正规的多语言系统，必须具备可以将所有标签及提示信息导出的功能，导出的目的是生成一个Excel，然后交由专业的翻译公司进行翻译、校对，至少不会出现干货=F**k Goods一类的低级错误，然后，再导入系统，生成第二语言，同样，第三第四语言也是同样操作。
七
移动端，这部分大多数的低代码平台都做得不错，支持例如扫码控件一类的方式，但是大部分都还是H5的版本，反正也能用，我就不过多挑剔了。值得注意的是，大量的传统ERP软件，往往只有PC端，已经严重不适合现在的操作要求，更多的系统都需要移动端，我认为这可能会是低代码平台的一个主攻方向，用低代码平台重写某些老旧的ERP，把他们迅速转移到移动端，这是一门需求极其旺盛的生意，也是CIO、CTO们愿意去为你申请预算的一个良好突破口。
八
社区，说到低代码，不得不说一下这个隐隐的痛。所有的工具，其实都必须有一个社区，这时候，他才是一个强壮的，有生命力的工具，目前做的最好的自然是Oracle，国内有社区概念的很少，能把社区玩好的也很少，这也是国产软件历来的问题，其实技术都可以追赶，软件都可以开发，功能都可以重构；唯有社区，这是一场看不见的战争，却最终能够决定胜利的走向，在这里投入多少钱都是应该的！毫不夸张的说，低代码的所有技术差距不会超过1年，而谁拥有了技术社区，谁才会是最终的胜利者。
九
价格，有完全免费的，但是你需要买他的数据库，也有开价过百万的大型平台，更多的是SaaS方式合作，不一而足，丰俭由人，但是选了低代码平台，往往就会被绑在这个战车上，使用小公司产品风险很高，除非你是一个更小的公司。这个领域的马太效应一样强大。
十
最后，说几个有趣的事情
1. 关于甘特图（Gantt chart，一种协调团队项目进度的图表）。由于希望用低代码平台做一个项目管理工具，对所有低代码公司都提了这个甘特图展示的需求，几乎所有现在没有甘特图功能的企业都告诉我，已经在7月份的迭代里加入了这个需求，这是他们商量好的呢，还是商量好的呢，还是销售的标准套路呢，我陷入了深深的思考。
2. 有一家公司另辟蹊径，索性把Excel在线化作为重点，不和其他低代码公司在同一赛道竞争，听起来挺美好，看起来也不错，但是我不知道这家公司这么照抄Excel，未来是不是会面临很多官司呢？老年人应该都还记得当年的Louts123和Excel之争吧？要是那个年代过于久远，请看看三星和苹果在手机UI上的那些官司。另外，他们认为“在本质上，所谓的数字化转型，在执行上就是把所有的电子表格转换成一个个基于网页的系统，让所有的员工、不同的部门可以在上面一起协同工作。”我理解你们看重Excel，但是这个实在不敢苟同，要是这样，这个所谓数字化转型也太容易了吧……
3. 好几个低代码公司的投资方都差不多，看起来，资本就是任性，反正我有钱，都投了，总有一个跑出来的吧？哈哈。
上一篇
