根据相关研究报告显示,许多企业中,开发人员经常花费至少30%的时间来构建内部系统。随着公司规模增大,这个问题变得更加严重。想象一下,假设一家拥有5000多名员工的公司,开发人员将近45%的时间用于内部系统开发,是不是有些浪费了开发人员的生产力呢?
如果我们认为开发内部系统是为了提高生产力,那么浪费大量开发人员的时间和精力来构建这些系统是否有些得不偿失呢?
目前,大多数开发者仍然选择从头开始开发定制应用程序(从头构建)。他们主要选择的编程语言是JavaScript、HTML/CSS、SQL、TypeScript和Python,而常用的框架有React、Express、jQuery、Angular和VUE.js(尽管在互联网快速发展的时代,jQuery仍然很受欢迎,可能是因为许多老公司仍在开发和维护旧系统)。
目前,只有少数人采用低代码开发方式,对于这些用户来说,这是一个正确的选择,并且他们愿意继续使用低代码。但对于大多数开发者来说,他们对尝试低代码持有犹豫的态度,他们更相信只有通过自己编写代码才能解决面临的业务问题。
低代码开发的本质在于更高的抽象层次上进行开发。回顾编程语言的发展,无论是从机器语言到汇编语言,还是从COBOL/FORTRAN/C到面向对象的高级语言,都是朝着更高的抽象层次发展的。
更高的抽象化意味着开发者更容易理解和阅读代码,并且更符合人类的思维习惯。同时,使用这门语言进行开发能够更有效地实现功能,达到业务目标。
举个例子,当你使用React开发一个Web应用程序时,相较于纯JavaScript编码,你已经站在了"巨人的肩膀"上——使用传统的JavaScript实现相同的结果需要更多更繁琐的代码。想象一下,是选择一遍又一遍地复制粘贴相同的HTML代码,还是稍作修改就能实现相同结果的迭代数组呢?作为开发者,你会如何选择呢?
再来想象一个场景:如果你的团队需要为公司的网站开发一个新的支付系统,这个系统是否能够提供像支付宝和微信支付一样强大的功能呢?而且开发和迭代这样复杂而庞大的程序需要大量的时间、金钱和人力资源投入。在这种情况下,为什么不将这项工作委托给支付宝或微信等第三方支付平台呢?让它们来完成这个任务呢?毕竟,"天下武功,唯快不破",让开发人员专注于业务逻辑,将繁琐且耗时的工作交给框架或平台来解决,这样岂不快乐而又高效?
显然,我们都致力于减少编写代码的量,提高开发效率,并将注意力更专注于业务逻辑,而不是与底层技术细节纠缠。低代码开发就是当下时代变化的产物。
"内部系统"的主要目的是用于企业内部信息管理,包括BI数据看板、管理后台、数据录入系统、客服系统等等。这些系统往往涉及复杂的业务逻辑,开发人员需要考虑数据库的CRUD操作、构建用户界面、处理交互等等。在目前大多数开发人员选择"从头开始开发"的情况下,他们花费大量时间和精力的工作可能并不是真正解决业务问题,而是在重复造轮子、编写大量粘合代码和模板代码。
与枯燥重复的工作相比,大多数人更希望解决有趣的事情,例如建模和解决实际业务问题。重复性的CRUD操作已经走到了尽头,低代码应用开发的时代已经来临。
最后,作为开发人员,许多人希望拥有对我们开发和维护的东西的所有权。当他们被指派完成一个任务,只需使用低代码平台的拖放功能加上少量代码即可完成时,他们可能会感到自己不再是一个"真正的"程序员。类似的问题也常常出现在使用可视化编辑器WordPress的人是否算作"真正的"程序员,使用Shopify快速搭建电商网站的人是否算作"真正的"程序员等等。然而,我们对这类问题的答案很简单:是的。
我选择低代码开发,同时坚信自己是一名"真正的"开发者。就像前面提到的,如果没有站在"巨人的肩膀"上,我很难独立从头开始编写代码。举个例子,NASA的软件开发先驱(玛格丽特·汉密尔顿),她所编写的代码量足够堆成一人高。然而,现在有多少人能够做到这一点呢?难道这意味着我们不再是"真正的"开发者吗?我不这样认为。
此外,还存在一种现象被称为"宜家效应",指的是消费者对自己投入劳动和情感创造的物品高估其价值的倾向。这解释了为什么许多开发者仍然选择从他们自己编写的代码中获取成就感,即使有更好、更简单的替代方案存在。因此,越来越多的低代码平台,如织信Informat、Appsmith、Retool、Budibase等,也开始重视平台的可编程性、可扩展性和灵活性,并不断探索最佳实践,为开发者提供更多发挥空间,让他们享受"宜家效应"带来的乐趣。
以织信低代码为例,该平台在保留低代码高度抽象化特性的同时,提倡"到处可写JavaScript"的理念:在双大括号{{ }}中的语句都会被执行为JavaScript代码,并在沙箱环境中运行;此外,平台还支持图形化编程,可以快速将你编写的代码块供团队其他成员复用等等。
阅读到这里,如果还有人问我如何看待低代码开发,我可能会反问他们:如果你有5名开发人员,你是愿意让他们全职从头开始开发和迭代一个内部系统,还是选择一个低代码工具,让其中一名开发人员去完成这项任务,而其他四名开发人员则可以专注于开发公司的实际产品呢?
低代码开发为我们提供了更高的抽象层次,使开发过程更高效、更快乐。让我们拥抱这个时代的变化,发挥我们的创造力和解决问题的能力,而不被困在重复和繁琐的工作中。