程序员为什么害怕低代码？ZT

转自：https://www.jianshu.com/p/cd89fe94cd30

低代码 是一种近些年兴起的企业软件快速开发技术和工具。借助低代码使用者无需编码即可完成企业应用的常用功能，少量编码扩展出更多功能。低代码凭借低门槛、高效率和易集成等特性，被越来越多的软件开发团队青睐。Gartner预测，到2024年四分之三的大企业将会使用至少4种低代码开发平台，用于信息化应用开发。届时，65% 的应用开发将通过低代码完成。

看上去，低代码是一种颠覆性的技术。那么，低代码会不会取代专业开发者？如果你是一名企业软件领域的程序员，这篇文章也许可以减轻你的恐惧。

恐惧来自哪里？

我是一名年近40岁的程序员，在这家公司里先后从事过WinForm、Web和移动APP的开发。不能否认，面对低代码技术时，我是有些恐惧的：没有受过专业训练的平民开发者可以先学习SQL（甚至可以跳过这一步），然后学习一种低代码工具并投入开发过程中，我的工作可能也就终结了。

（传统的软件开发方式，图片来自网络）

这个想法曾经变成短暂而真实的恐慌。在与活字格低代码开发平台的核心员工进行过几次讨论之后，我意识到了自己逻辑上的错误，而这个错误恰好就是低代码永远不会取代我，也根本不打算取代我的原因。我想，充分了解这些论点，可以缓解你和你的团队对低代码的恐惧感，并防止他们陷入对低代码的恐惧中。

低代码平台只是一款工具

在科幻电影中，我们看到过不止一次的“人工智能大灾难”，软件最终会完成自我开发并最终征服人类。低代码是否也会像电影中那样，自己完成软件开发？答案当然是否定的，低代码平台仅仅是一种工具而已。和其他所有的工具一样，其价值源自于它的使用者。设想一下，大多数软件都可以基于低代码平台进行开发，这意味着老板们随便雇用张三、李四，而不是专业的程序员就可以进行在低代码开发平台上拖拉拽出一个报销系统、填报表单。但是，如果没有必要的软件基础知识，他们的能力也就到此为止了。

与标榜为无代码的“开发工具”不同，低代码开发平台具备更强的扩展性，比如活字格就提供了自定义JavaScript/CSS，高级SQL查询和C＃接口。这使得经验丰富的专业开发者——比如我——可以在低代码平台上完成那些可视化开发不能满足的需求，最终交付更复杂的系统。

（使用低代码构建的ERP系统页面，图片来自活字格官网）

更重要的是，开发者更了解软件、计算机架构、数据库、Web端等的基本原理。这种知识储备使他们能够提高工作效率，进行平台优化，少走弯路。这远远超过了张三、李四等平民开发者能做的。所以，没有受过专业编程训练的平民开发者能够使用低代码开发平台构建出面对特定场景的简单应用，但是，对于ERP、MES等为核心应用场景而生的更高价值的大型系统，依然是专业开发者的主舞台。低代码只是专业开发者手边更趁手、更高效的工具罢了。

低代码是一个值得信赖的“黑盒子”

低代码平台不会取代专业开发者，相比于平民开发者，专业开发者依然有着很强的优势。但这一发现并不能真正将开发者变成低代码的支持者，尤其是当他们第一次开始尝试去了解低代码的时候。

（典型低代码开发平台的设计器界面）

开发者对这些低代码平台所见即所得设计器有两种反应。

A： “我的天啊，看看我能以多快的速度开发出XXX！”，这是一个了解时间价值并欣赏抽象之美的人。另一种更为突出的反应是B：“我不相信有人能用这个搞出YYY！”。

与对失业的恐惧不同，这种担忧是有价值的。就我个人而言，我属于A组——就是我刚才很友善地称赞过的那个组——因为我不仅是一个值得信赖的程序员，而且喜欢自夸。

但是，当我与专业开发者讨论低代码时，他们向我保证，这些低代码开发平台是个危险的黑盒子，他们担不起在无法控制的“黑盒”上开发关键任务带来的风险，比如平台不稳定怎么办、开发进度过半发现有问题无法解决怎么办等等。首先，这种逻辑看起来没毛病，所以，我将花更大的篇幅来解释为什么这种恐惧是不合理的。

低代码的技术栈并不特殊

首先，低代码的黑盒子是在开发者熟悉的技术栈上运行，而这些技术栈本身和低代码类似，也经历了被逐步认识、喜爱、鄙视并再次喜爱上的过程。比如活字格低代码开发平台就是的服务端是采用.net开发的（毕竟葡萄城在1980年代加入了Microsoft Early Adopter Partnership），前台则完全使用JavaScript，数据库方面兼容SQLite、SQL Server、MySQL等主流数据库。

这些技术栈保障了低代码开发平台自身的稳定性和可靠性，更重要的是，平台的编程接口也基于这些技术，所以，开发者可以将现有的服务器代码、SQL视图及存储过程、样式表等添加到使用低代码开发的项目中。这么看来，你对低代码的稳定性、扩展性等担心，是不是有些多余了呢？

人人都爱黑盒子

事实上，我们都爱“黑盒子”，尤其是可以帮我们大幅节省时间的黑盒子。Java及其姊妹语言Scala，Groovy，和其他语言一样依赖于开发者中最受欢迎的黑盒：JVM；而C#、VB.net依托在.net Framework上才能运行。那么，为什么我们会信任JVM、.net而不是低代码呢？因为时间可以为这些平台证明。

21世纪初，.net在诞生时也受到开发者社区的严格审查。但在看到它年复一年地顺利运行后，信任度增加了。开发者知道C#和.net仍然会存在很长一段时间，而微软将继续支持这两者。我不知道微软将会如何执行我的C#，但是我依然信任着它。就像我相信V8引擎执行我的JavaScript，JVM运行我的Java一样。当然，我也不能忘记曾经依赖的其他著名的黑盒：Spread、KendoUI、ActiveReport等前端控件。正是因为有了这些控件，我们开发应用的效率得到了数倍的提升。如果你从事过程序界面的开发，我相信你一定会和我有同感。

事实上，低代码并不是一个这两年横空出世的技术，只是近些年更受媒体关注而已。十几年来，已经有太多的案例能向你证明这个“黑盒子”的真实实力，应用场景从MES、ERP到SCM以及SCRM，终端平台也支持PC浏览器、APP、企业微信和钉钉。所以，也许是时候给低代码这个不算很新的黑盒子多点信心了。

（使用低代码构建的SCM系统门店销售终端页面，图片来自活字格官网）

对了，前面提到的那些控件的厂商也推出了低代码开发平台，如果你对低代码行业的初创企业实在没有信心，可以先从那些来自开发控件厂商的产品（如Kinvey、活字格等）开始。

低代码能够带来更大的成就感

到这里，我们已经粉碎了失业的威胁，粉碎了对黑盒子的恐惧。那还剩下什么？应该是对失去挑战及成就感的担忧，因为它比其他所有类型的恐惧更可怕。

每当深夜下班，程序员们结束工作离开办公室时，手中都掌握着自己所拥有的技能。有些人可能会会心满意足地休息，太阳再次升起之前都不会使用这些技能。但是其他的，譬如那些激情四射的黑客，他们会利用个人时间来摆弄一些业余项目。他们也许会修补开源代码，也许在学习新的框架，还有可能会回答StackOverflow、知乎或其他社区上的问题。

（不眠不休的腾讯办公楼，图片来自网络）

他们热爱编码，因为编码可以解决复杂的问题、凭空构造产品，作用相当于现代炼金术。他们的技能赋予自己力量和尊重。而低代码则有可能威胁到他们的地位。

毕竟，只需花费很少量时间来掌握软件工程知识，就能学会低代码开发。当低代码成为企业软件开发的首选工具后，专业开发者的威望很可能会随之降低。这些平台可以预先解决大多数复杂的问题，如负载平衡、资源分配、加密甚至界面交互等。这意味着使用低代码做开发的人在日常工作中几乎没有什么需要克服的障碍和挑战。程序员该如何获得成就感呢？事实上，低代码能够帮我们解决更大的问题，那就是如何更快速的完成软件交付，而这才是成功的关键。

企业想要快速发展

企业需要以一种能够匹配竞争对手、供应商和现代消费者稍纵即逝渴望的速度来进行变革。如果仍保持以蜗牛般速度升级的旧版软件，企业如何能够实现这样的速度？

然而，使用传统的开发方式编写软件是一项艰巨且缓慢的任务，容易出现人为错误。根据我的经验，程序员编写代码的速度和他们出错的数量之间存在指数关系，写的越快，Bug越多。因此，更快地编码其实并不是一个可行的选择。还有没有别的办法？

站在领导者的角度考虑这个问题

办法确实存在，但已经超出了编码本身。也许你正在企盼自己成为一个领导者，而不单是一个程序员，而要想成为领导者，就要超越自己的角色，看清大局。

这里的大局并不是 “解决复杂问题”或“重新考虑解决方案”，而是如何快速发布产品，快速发布用户满意的产品。如果你不得不缓慢、费力、容易出错的工作，而有一种技术能够以同样成本获得快速、精确、准确的结果，我想你的选择是显而易见的。

所以，对程序员这份工作来说，最大的成就感应该源于其通过自己开发的软件让更多人的生活更加美好，而不是加班工作本身。我宁愿拥有一个低代码库和无穷多的满意用户，也不愿抱着自己编写的专有源代码，以及一堆褒贬不一的评论。

开始行动吧

当然，专业开发者还可能出于一些本文没有提及的原因害怕低代码平台，因为人们可能对每种特定产品都存在更狭隘的怀疑。然而，对失业、黑盒、丧失成就感的恐惧是常见且真实的。如果你已经克服了这些非理性的恐惧，那就开始使用低代码工具，乘着软件开发技术的发展趋势，从更高效率的开发中获益吧。