所谓低代码开发平台，是指无需编码或者仅需少量编码即可快速生成应用程序的开发平台。这里的应用在目前的语境下一般是指企业应用，如OA、ERP、CRM、HRM、SCM等。此类平台的特点在于，允许终端用户使用易于理解的可视化工具建模即可开发自己的应用，而不是传统的编写代码的方式。对于企业而言，低代码平台作为一种新型的开发工具，不仅可以降低IT团队培训、技术部署的初始成本，还可以简化开发过程，缩短开发周期，提高开发效率，节省开发成本。而国内随着最近一系列的针对低代码平台的投资事件，此类平台也逐渐引起了更多的关注。
其实低代码平台并不是一项新的技术，相关的技术理念和产品实践的历史可以回溯到十几年前。但是从那时候就遗留了一个一直困扰低代码平台开发者的问题就是：低代码平台神奇的二次开发工具的用户到底是谁？
为什么这会成为一个问题呢？我们知道即便到现在，多数企业应用都免不了有一定的二次开发，以适应企业特有的管理模式和偏好。低代码平台出现初衷就在于，开发这些平台的程序员们期望这种单件定制的二次开发可以规避；如果不能完全避免，至少相关的工作量能减少，或者把这个工作从自己的身上拿开。于是乎，就设想了这么一个不需要编码或者仅需少数编码即可实现定制化的技术理念。但是任何理念都是要落地，如果假设这个二次开发者是用户企业的人，那是是业务主管还是信息部人员？前者显然对业务模型更加熟悉，也是多数需求变更的始作俑者，似乎是最好的选择。但是业务主管们一般缺乏编程的基本知识，所以程序员们一开始试图把二次开发工具以一种非程序员即可理解的方式来展现和交互。这个想法其实很早就碰壁了：主管们知道业务，不等于其具有业务的建模能力。主管们觉得自己是个业务经理不应该过多碰触一个工具系统的开发，哪怕只是一些配置。业务模型自身的复杂性和一些常人未必理解的软件建模习惯，导致配置界面其实无论如何也难以成为一种无需说明书的自解释的工具。所以，这个一开始的设想被实践证明是带有相当的一厢情愿的成分。
要回答好这个问题，还是要回到初心。我们期望二次开发难度降低、速度加快，这些其实并不意味着要甩给日常使用者。留给原本负责二次开发和部署的研发人员其实更合适。谁呢？这其中包含两类：一类是来自用户企业的信息化人员，一类是平台供应商的交付人员。这两类人的共性在于，具有对业务模型的基本理解和初步开发能力。有的低代码平台公司甚至为此类人员设立了一个专门的岗位：客户成功经理。而在用户企业中，这个除了信息部的人员，偶尔也会是业务部门的某个干预尝试的员工，而这个员工一般并不是业务主管本人。
所以说，低代码平台的二次开发工具的用户仍然是开发者，目的是提高交付速度和质量。只不过，此时的开发者主要是承担交付阶段工作的开发者。因为低代码平台的能力使得交付阶段开发者和河西阶段开发者之间可以进行分离而由不同的人来承担而已，即交付阶段开发者不在依赖于代码编写，从而有了“人人都可以是开发者”的说法，但是我们必须要明白“二次开发者仍然是开发者”这一点，否则在开发一个低代码平台的时候就会出现以这样的偏差：花费不必要的资源去把复杂的模型简化为非开发者能理解的操作，而这么做或者因为问题本身的复杂性而失败的概率非常大，或者即便做得不错也不会被用户采纳（因为普通用户就不认为自己该有这份工作：我花钱给你本来就是期望你给我一个开箱即用的系统，结果你开完箱还要我看说明书鼓捣那么多？），更或者，实际上即便做了出来且用户和喜欢使用，是不是也会因此丧失了从二次开发中获得更多商业利益的机会呢？只能说，慎之！在企业应用中，过度的产品化有时候并不见得是一件好事。
有一句话叫做：太阳底下没有新鲜事。其实类似的场景早就出现在其他领域，比如工业控制领域的组态软件。是的，没错，这其实完全可以看做是控制系统的低代码开发平台，而且已经有30多年的历史了！组态软件让一般的控制工程师，你可以理解为控制系统的交付工程师，不用一行代码就能实现一个复杂的生产线的管理和调度，但是，自控工程师没做一个画面的几件工资，我记得前几年是每个画面500到1000元。这些工程师在使用组态软件之前，也是需要应该的培训的。没错，是培训！能自学WinCC的已经被很多同行当做“技术大牛”了。当然如果不用组态软件而采用C 来编程实现，这个效率至少差2~3个数量级了。所以，您还认为低代码平台就应该是完全的非技术性人员使用么？
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。