无代码和低代码是什么?会抢走程序员的工作吗?

卡拉先生
发布于 2020年07月21日 | 上次编辑:2020年07月21日

低代码和无代码平台
低代码和无代码平台

最近在知乎上看到一个非常有意思的问题:无代码时代来了,程序员会失业吗?

之所以这个问题很有意思,是因为问题本身已经走在了时代的前沿。在很多人没有听过无代码、低代码是什么的时候已经有人在思考它的影响了,让我感慨现在信息流动速度之快。

那么要讨论这个问题,首先我们得知道,什么是无代码、低代码?

1. 什么是无代码或低代码工具

无代码和低代码工具是一股正在发生在硅谷的风潮,但它其实并不新鲜,正所谓“老瓶装新酒”。

无代码:英文为 No Code,也就是无需代码即可使用

低代码:英文为 Low Code,也就是需要少量代码即可使用

那么你要问了,这什么鬼?难道不是几乎面向终端用户(to C)的工具都是无代码吗?难道用户还要去写一段代码才能用一个 APP?

这其实是个好问题,但需要注意的是,几乎所有的无代码、低代码工具本身,都是为了开发其它工具而使用的。以及,几乎所有的无代码、低代码场景,都是 to B 场景,简单说也就是给自己公司、其它公司创作工具。

听着很绕,但我们用一个例子来说明。

之前我在朋友的一家跨境电商公司帮忙,我们把这家公司叫 A 公司好了。A公司的主要业务在 Shopify 上(不重要,想象成淘宝即可)。但不幸的是,Shopify 并不允许他们的供应商直接把商品的信息传到后台,因此这时候问题来了,A 公司如何才能方便地让它的供应商把货传到后台呢?

同时,传的商品不能一传就上架,要是供应商传了不符合规定的商品,不能直接展示给消费者。所以还需要一个工具,让 A公司的人工可以对商品进行审核

那么有两个我们试过的方案:

  1. A 公司让供应商把 Excel 传过来,让一个客服小妹手工输入,顺便审核
  2. A 公司建一个 React 网站,在网站内调用 Shopify 的 API,让供应商可以通过网站把商品信息传过来。在这个网站上,再提供一套审核工具

方案 1 当然可行,但是问题非常明显。A 公司尝试招过几个客服小妹后,发现无法规模化,于是转向方案 2. 方案 2 比起 1 来,显然更优,这让 A 公司不必增加人工成本,只要 React 网站上和对应的后台的审核功能做好,那么规模化很容易。

但是问题来了,要做方案 2,至少短期内,需要更大的开销:至少需要一个后端工程师和一个前端工程师,或者一个全栈。

而有一些硅谷的创业公司发现了这个问题:很多时候我们在内部开发的工具,其实抽象一下就是在数据库基础上的增删改查,以及套一个 UI。所以,为什么我们不能做一个工具,这个工具的作用就是用来方便地构建其它工具呢?

上面提到的这个工具就叫作 Retool,它是很多家做类似无代码、低代码工具中的一家。它的卖点就是,帮你节省开发资源,可以非常快地开发出内部工具。

Retool
Retool

对于上面说的方案 2 来说,我用 Retool 试了一下,大概花了20分钟就搭建好了一个基本的工具,可以允许供应商上传 csv,自动把 csv 解析好,添加到审核列表。客服只需要点鼠标(也是 Retool 做的)就可以审核商品是否合规。

为什么这么快?我在 Retool 里做了啥分别花了多少时间?

我可以在这简单总结一下:

  1. 有非常方便的接口连接数据库,大概 5 分钟我就连上了 Postgres
  2. 所有的 UI 库都可以以拖拽的形式直接操作,大概 5 分钟调好了界面
  3. UI 与数据库的逻辑操作稍复杂,这里需要写一些特定的 SQL 和调整触发器,大致花了 10分钟左右

成品就是上面描述的小工具网站,客服可以登录审核,供应商可以登录上传商品等等。从成本上看,如果当时我们用了这个工具,那么可以至少省掉一个月工程师时间。

2. 无代码和低代码会抢走程序员饭碗吗

那么问题来了,无代码和低代码会抢走程序员饭碗吗?

先说我的结论:对绝大多数程序员来说不会,但长期来看,对一些程序员来说有可能。以下是我的分析

2.1. 软件的饼越来越大

首先需要明确的一点是,虽然现在看似我们身边每个人都在用着 APP,用美团点着外卖,用猫眼看着电影,但是整体国内,甚至软件渗透最高的美国,很多行业的软件渗透率其实也并没有那么的高。比如说,即使到了现在 2020 年,整体的软件渗透率也就 36% 左右。不少行业,比如建筑工程、制造业更是低得可怜,分别只有百分之十左右。

公有云软件渗透率
公有云软件渗透率

对于绝大多数还没上车的企业,这样的趋势还会持续很长一段时间。也就是说,即使什么都不改变,随着各个行业软件渗透率的提升,水涨船高需要的程序员也就更多。而这样的前提下,饼越来越大,因为饼大带来的工作机会也就更多。

这其实也可以解释为什么现在程序员的工资如此之高,特别在美国湾区,中国的北上广和印度孟买班加罗尔等城市——主要是需求太过于旺盛。各个地方的公司、用户都在越来越多地依赖软件给他们带来的便利,正如 A16Z 的创始人说的:软件正在吃掉这个世界

2.2. 低复杂度的重复软件开发会被替代

虽然随着软件渗透率的变高,越来越多的工作机会会向程序员敞开,但要注意的是,重复性的软件需求一定会被替代掉。

原因很简单,因为企业追求创造利润,而利润的一部分来自于降低成本。如果有工具把成本降低,但产出不变化的话,企业一定会趋于使用这样的工具。

举个例子,自从 Wordpress 出来之后,自架 PHP 来维护一个内容站的需求慢慢都转移到了 Wordpress 上。而类似 Stringly,Wix 这样的公司也不断地发布一键建站的工具,其实它们真的可以吃掉很多简单的应用场景。试问,如果你是昆明的一家鲜花厂,你的网站只是为了单纯展示产品和列出联系方式,你真的需要做一个全新的 React 站吗?也许一个 Wordpress 就可以非常好地满足需求。

上面我举的的例子也是一样,随着 Retool 这样的工具的增加,一些被重复开发的内部工具会慢慢被挪到这样的平台上。

2.3. 与商业逻辑紧密相关的软件开发不会被替代

如果你的公司做的是销售管理软件(CRM),那么有可能也用无代码、低代码平台来开发吗?

就我目前的观察看这还不太现实,甚至可以抽象一下,所有核心产品用无代码和低代码来开发都不太实现。

主要原因有几个

首先,至少到目前为止,市面上的无代码或低代码平台的定制程度都非常有限

而这也是所谓的 by design,也就是说它们本来就是被这么设计的。写过复杂软件的我们应该都知道,随着你写的功能和业务逻辑复杂度的上升,你的代码量也会迅速增加,且很多时候都不是线性的。

同理,如果任何公司需要做一个无代码、低代码的工具出来,且这个工具需要有非常好的可定制性,那么这个工具本身的复杂性就相当可观了。

第二,如果你可以用低代码平台实现你的产品,除非你的产品本身有其它的壁垒(比如网络效应、品牌效应等),本身产品的壁垒会非常低,不一定容易在竞争中胜出。

举个例子,卡拉搜索本身做的是站内搜索引擎,对比简单的数据库模糊搜索和 ElasticSearch 来说,卖点就是速度极快(我们的测试中是 ES 10 倍左右)以及免配置和维护。要写这个搜索引擎本身,需要对搜索技术有非常深的了解。如果说有人告诉我,市面上某个无代码甚至低代码工具可以写出这套引擎,我是会非常惊讶的。

第三,即使你的产品用了无代码甚至低代码的工具,你的软件的 scalibility 直接跟这个工具相关。因此按定义,很难想象一些量大的核心产品,比如抖音、快手之类的大厂会使用。而在这些大厂的很多很多程序员,操心的并不是具体的产品实现,而是存储、规模化、高可用高并发等等其它问题。

3. 总结

对于绝大多数程序员来说,并不用担心无代码或低代码工具的出现,会对作为程序员的你有太多冲击。毕竟水大鱼大,机会本身都在增加的话,不用太担心。

但是如果你的工作的确是在重复一些可替代的部件,比如小规模的内部工具等,那么应对的最好办法是提高竞争力,从一些无代码、低代码工具无法取代的角度来提升自己。比如说了解一门语言核心的用法、算法,了解如何应对规模化和高并发,如何实现复杂业务逻辑场景等等。

当然即使什么也不做,短期内我认为这股风潮也还非常早,但提前做好准备,总是更万无一失一些。

顺便说一下,如果你是程序员,且对创业感兴趣,我觉得做一些相对简单的无代码工具是非常好的项目。

首先这样的痛点你自己感受得到,其次复杂度不用非常高,一个人或者小团队能处理得过来。

最近看到一个好的例子是veed.io,这个工具非常简单,长话短说就是在线给视频加字幕的工具。但这个工具的应用场景却非常广泛,加字幕是视频里最主要的一个功能之一,而 iMovie 或 FinalCut 之类的工具不光贵,还难用。而这个小公具很好解决了这个痛点。这家公司几个人的小团队已经做到了年流水一千多万,对多数程序员和小创业团队来讲,这比做个社交网络成为下一个 Facebook 来得靠谱多了。

想要阅读更多技术文章和卡拉搜索的创业经历?
与 1893 位读者一起,订阅我们的邮件列表吧

相关文章

© 2020, 卡拉搜索, Built with ❤️ in San Francisco + Beijing

京ICP备15049164号-3