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

• 1. 什么是无代码或低代码工具
• 2. 无代码和低代码会抢走程序员饭碗吗
• 3. 总结

低代码和无代码平台

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

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

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

[](https://kalasearch.cn/blog/no... 什么是无代码或低代码工具

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

无代码：英文为 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

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

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

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

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

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

[](https://kalasearch.cn/blog/no... 无代码和低代码会抢走程序员饭碗吗

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

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

[](https://kalasearch.cn/blog/no... 软件的饼越来越大

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

公有云软件渗透率

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

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

[](https://kalasearch.cn/blog/no... 低复杂度的重复软件开发会被替代

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

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

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

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

[](https://kalasearch.cn/blog/no... 与商业逻辑紧密相关的软件开发不会被替代

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

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

主要原因有几个

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

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

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

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

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

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

[](https://kalasearch.cn/blog/no... 总结

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

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

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

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

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

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

参考：《2020最新Java基础精讲视频教程和学习路线！》
链接：https://kalasearch.cn/blog/no...