低代码甚至是零代码工具一直被人非常看好和追捧，尤其是在云技术各种催生的背景之下，人们总是期望有一种工具或平台能够快速实现应用开发和部署，不写代码或者写少量代码就能够实现客户的需求，对软件厂商或云厂商来说都是省心省力的事情。
而最近特斯拉ERP开发用了低代码工具（平台）的消息在坊间一直流传，导致人们对低代码工具又掀起了一股狂潮，甚至欢呼低代码工具的春天来临了。
冷静下来想一想，低代码工具无非就是通过工具/系统自带的组件组合拖放快速生成我们所需要的应用，在特定的环节里还能够允许写入少量的脚本代码来扩充一定的功能，这类工具目前存在不少。典型的就是OA厂家开发的系统定制部署工具，只需要在后台做做页面UI设计，套一下固定模板，设置一下目录，很快一套OA审核流程的页面就出来了，功能强大到足以应对大部分的审核需求。就连跟SAP系统做RFC接口的对接，都只需要做一下简单的配置就能够成功调用并拉取到数据。
想想都觉得很靠谱且特别简易，感觉程序员都要没饭吃了对不对。
但，这真的靠谱吗？
1、不要迷信这些工具。
低代码的前提是厂商做了非常大量的代码封装和功能模块，这些都是超大量的代码堆出来的，而且是需要经年累月的累积才有的成果，这个非常考验软件厂商的技术能力。很可惜，目前国内的厂家技术都达不到让人放心可用的“低代码”阶段，在稳定性这方面就很难让人攻克。
2、看似功能多样，但灵活性不高。
虽然它们在一定程度上可以减轻代码量，快速部署应用，但这些应用几乎千篇一律，就连上传个Excel数据文档，它上传的步骤都一模一样。
很荣幸我就被这样的工具坑过，前东家买了一套类似“低代码”的OA开发工具，一个简单的上传Excel的功能要点七八个鼠标，跟开发人员反馈进行用户体验上的优化，被告知行不通：因为软件厂商根本没有做这个上传Excel窗口的定制后台，加上没有源码，所以实现不了。
于是乎用这个低代码工具做的Web应用系统，操作、UI、权限设置、框架、模板几乎雷同，让人审美疲劳和无感，架构技术缺陷，用户抱怨连天，但如果厂商无动于衷，便无可奈何。
3、局限性。
面对国内复杂多变的企业业务环境，仅依靠拖拉几个控件和模块，用有限的代码量来支撑是绝对不可能的。做过外包和企业技术人员的都很清楚，很多时候一套系统最根本的命脉就是那套“源码”，只有它才能尽最大可能实现企业想要实现的功能，而不是那些什么封装好的接口和模块，毕竟那些都比较粗犷和有限。
所以你看SAP为何能够得到广泛认可？
1、因为其本身足够强大。
后台功能的配置以及原生支持的业务模式多到让人怀疑人生，配置灵活性极强。
2、它提供了自由的系统开发能力。
SAP有自己独特的开发语言，几乎所有画面都能查看到源码，也能做一定程度的修改，可以做到不停机部署（热部署）；部署SAP的企业可以根据自己的业务需要进行二次开发而不通过SAP原厂的介入，就好比如你买了一套Visual Studio开发工具。
你知道自由的系统二次开发能力对于制造业/供应链管理的企业有多么重要么？你知道这些企业业务的最大特点么？——多变！
好，就以上2点，其他ERP有谁能做得到的？SAP这套系统才是所有企业应用厂商应该仰望的目标，这才是当下“低代码工具“的标杆。
这也就像为什么专业的视频工作者剪辑视频的时候都喜欢用专业的Adobe Premiere Pro和Final Cut Pro，而不会用爱剪辑、剪影等小软件。因为平台是极其重要的，很多时候我们需要的不是简单的封装工具。
但不可否认的是，不同的企业有其不同的需求，并不是所有企业都有使用SAP软件及其功能模块的需求，低代码/零代码开发平台切中了我国小微企业的需求，符合我国小微企业居多的国情，使更多的小微企业能以较低的成本体验到信息化给企业带来的提升，这点还是毋庸置疑的。
其实企业应用厂商现在做的所谓的低代码/零代码工具，抛开其外衣和新形态，其本质上和30年前的雅奇MIS、OA、BPM等区别不大。
注：本文章源于互联网整合，版权属于原作者，SAP斯凯普斯本着学习的态度进行传播转载，如有版权持有者提出异议，联系立即删除。
