低电平代码没有代码：如何骑此波浪

今天的帖子是Shawn Xu（无关系）的贡献。 Shawn是Ascend.io的早期工程师之一，在Carnegie Mellon的人类计算机互动中获得了他的大师，并在SaaS上写了一个被称为硅谷成长攻略的帆丝公共账户。

在这两部分的低代码中没有代码系列，我专注于整体低代码没有代码（LCNC）景观，主要产品类别，以及超过360家公司在生态系统中的景观图形。

在这部分II中，我将分享一些关于如何乘坐这个最新的LCNC波的思考，这是评估不同LCNC产品的标准，以及LCNC如何在中国发展。

低代码没有代码实际上是一个20岁的概念。有几个原因享受最近的繁荣：

对宣言性编程的迫切需要：命令编程是关于“命令”的，而声明性编程描述了“最终结果”。

一个很好的例子会告诉一些正在拜访你家的朋友。以必要的方式，你说：“在101号高速公路上，在公平的奥克斯大道出口，在邮局右转，然后在7-11之后左右左转。”这是一个命令列表，应该为您提供所需的结果，但实际上并没有描述结果。在声明方式中，您只需宣布您的家庭的地址并卸载导航即可说谷歌地图。

声明性编程具有其明显的优势，在那里工程师可以专注于最终结果应该是什么样的，而不是到达那里的杂乱中间命令。 SQL是体现了声明范例的一个很好的例子，因此它仍然是最广泛使用的查询语言之一，即使它在45多年前创建了。在技​​术堆栈的不同层，从前端框架（RESTJS，VUEJS）到基础设施管理和DEVOPS（Terraform），类似的趋势是出现的。

从宣言的必要性转变是另一个抽象的故事，这是LCNC运动的本质。回忆起，我是我们对LCNC的定义：

基本LCNC实质上，宣言编程的抽象进展，因此删除了“编程”本身的行为。

数字富有表现力：随着我们的生活变得数字化，需要表达自己的数字也会显着增加。从婚礼登记处到一家在线商店销售自制甜点，从定制的团队建设锻炼到移动游戏的帆布，任何人都可以成为“数字建设者”。您不需要计算机科学学位，只需需要正确的工具。

我们还尚未见证这种趋势的全力，因为许多工具仍然仍然在技术上挑战，需要一定数量的沉重举重。但是，我在第一部分中提到的一些公司，特别是那些在“迅速建设者”类别中，已经开始平滑粗糙的边缘来制作“每个人开发商”。

到云的旅程：非常像“西部的旅程”（一个古典的中国小说描绘了一个僧侣的史诗朝圣者和他的门徒获得印度的神圣兄弟课程），传统企业正在经历类似的艰辛，因为他们过渡到云层。

最大的挑战来自缺乏工程人才。旧的组织结构和文化使吸引顶级人才和与谷歌和Facebook这样的公司竞争困难。

LCNC成为帮助桥梁对这些传统企业缺口的关键界面。将数据从离线进行在线，推出新的基于云的体验，从各种系统拼接数据 - 最新的LCNC产品已经使所有这些工程重型工作量更容易，比以往任何时候都更容易和更顺畅。

有了这么多不同的产品，在堆栈中的不同抽象层中啃掉，您应该如何评估它们，作为投资者，公司主管或工程师？ 我想提出“5”的“规则”。 这是它适用于假设的产品x： x是否会削减计划启动至少5次的时间？ 一个人可以根据在5小时内的教程和文档基于X构建MVP（最小可行的产品）吗？ 一个新的员工可以在5天内使用x升高，以便在x效力吗？ 与在内部建立类似的解决方案相比，在近期使用x将总成本降低了50次？ 如果公司使用x 5倍，或者购买了5倍的座位，那么成本也将线性增加5倍？

如果x超出服务或破产，可以在X上建立的功能和业务逻辑通常在迁移到新的东西后通常运行？

使用X时，超过5％的问题遇到的其他客户不可能，因此必须聘请其支持团队？

从客户的角度来看，这份高度实用的需求列表是来自人群的真正有用的LCNC产品。当然，如第一部分所述，LCNC产品在抽象层面不同，因此数量“5”不应刚刚地使用。

与市场可能一样，我们尚未明确赢家或许多LCNC独角兽出现，与其他萨斯部门相比。以下是LCNC类别面临的一些独特挑战：

销售进入较大的企业：与其他SaaS产品一样，大多数LCNC产品出于充分理由的最佳销售策略，获取产品反馈，以更快的迭代并使用社区驱动的方法来传播意识。

这可以在开始时工作一段时间，但随着产品和公司的增长，它将不可避免地通过获得更大的购买订单来获取更大的客户。这种扩展到企业可以尤为努力，因为LCNC产品，因为这些较大的企业已经拥有了本土的机会，适用于许多商业用途的案例，这足够好。

销售进入这种环境只能意味着一件事：导航泥泞的内部政治池。这里的成功将需要大量的关系 - 建筑，一丝闪亮的功能，超过一盎司的运气。如果LCNC产品恰好取代执行行政所拥有的一个或多个关键业务流程，事情可能会更加困难，因为那个高管的职业可能在线。

购买VS构建和工作安全：没有人喜欢他或她的工作“抽象”或“自动化”。通过采用一些LCNC产品首先，少数人犹豫不决，为他们的公司保存自己的工作而言，为他们的公司拯救了一些钱！

有趣的是，更频繁的是，这些也是同一技术团队，使得购买或建立自己的全典解决方案之间的评估和决定。当公司高管不那么动手时，这尤其如此，将这些决定委派给适当的技术团队经理或领导。

如果LCNC产品对工程师团队的工作保障构成可靠的威胁，最终决定通常是一个“否”，其次是评论：“Meh，我们可以在一周内建造这些东西！”

购买VS构建和公司增长：对于客户公司，“购买”VS Build讨论不是一次性决定，而是一个正在进行的过程，以便在该公司增长时动态变化。

当客户公司年轻且缺乏工程资源时，“买”往往是正确的，如果不是唯一的选择。然而，正如本公司的增长，平衡慢慢倾斜，远离购买建设。作为一个更大的公司也意味着需要购买更多席位，产生更多使用，并签署更大的合同，分配一些工程师来构建本土解决方案可能会开始更好地利用资源。在这个时刻，LCNC产品必须努力打击（和可能的折扣），以努力打击其客户的建设冲动。

美国不是LCNC生态系统是红热的唯一地方;中国也有一个蓬勃发展的生态系统。

今年早些时候，阿里巴巴的企业产品DingTalk - 一个懈怠，Gmail和阿特拉斯人的混合动力车 - 宣布推出建立一个低码应用程序生态系统的新方向。本公告引发了中国企业产品社区的热情 - 有些人甚至叫2021“低代码年”。

据说，中国的LCNC景观仍明显小于美国。 2016年至2020年间，只有59次资助事件将少数在中国提供少数LCNC公司。这些公司中的大多数提供了合作工具或基于GUI的网站建设者。

归因于对中国不发达的B2B企业市场的差异有点天真，更简单，这实际上将上述LCNC数字超出了几个数量级。我认为游戏中还有另外两种细微差别因素：

垄断电子商务平台：推动美国LCNC景观的两个主要部门是电子商务网站建设者和聊天禁止（见I部分）。这些产品茁壮成长，因为有广泛的独立零售商，谁需要在线商店前面，具有定制品牌和客户服务功能。

在中国都不是必要的，因为它的电子商务行业由几个巨型平台主导 - 主要是淘宝，JD和Pinduoduo。所有这些垄断平台已经提供了一套完整的端到端零售解决方案，从付款到品牌到客户服务，以便在其平台上留下卖家。

Build比买便宜：这个原因可能更明显，但我们仍然应该把一些数字放在它周围。根据Jobui，一个类似于GlassDoor的流行就业数据网站，北京的平均开发商每年赢得164,000元（25,400美元）。食品送货员每年12000元人民币（18,600美元）。初级开发人员经常得到的支付低于平均值。

因此，充足和相对廉价的工程供应使得大多数用例的“建立”比“买入”更具吸引力。涉及开发人员的工具和自动化 - 美国 - 中国公司拥挤的LCNC域倾向于“抛弃机构”问题，以建立自己的解决方案，而不是考虑购买可能更好的架子的LCNC产品。这是比美国同行更容易的决定。

我希望这一两部分系列在低代码中的世界没有代码，没有代码可以让您掌握LCNC的主要用例，为什么这个空间最近在快速增长，如何评估产品，以及如何评估产品和比较镜头它分别在美国和中国发展。无论您是在任何类型的技术公司工作的投资者，创始人还是员工，都是一个值得关注的空间。 LCNC在将来发展如何会影响您的投资回报，您如何启动下一家公司，或者只是您的工作保障。就像技术中的任何东西一样，缺点和上行都是巨大的。

If you like what you've read, please SUBSCRIBE to the Interconnected email list. To read all previous posts, please check out the Archive section. New content will be delivered to your inbox (twice per week). Follow and interact with me on: Twitter, LinkedIn, Clubhouse (@kevinsxu).

今天的文章是徐晟洋（和我没有亲戚关系，纯属凑巧哈）写的《互联》的“嘉宾专栏”。他是创业公司Ascend.io的早期工程师之一，在卡内基梅隆大学获得了人机交互的硕士学位，并写一个与SaaS行业有关的干货很足的微信公众号《硅谷成长攻略》。

在低代码、无代码（LCNC） 系列的上篇中，我们聚焦在这个赛道的整体版图、具体的分类，以及一张包含360家LCNC的版图。下篇中，我们将讨论这个浪潮的背后推动因素、分析一款LCNC的框架，以及LCNC在中国的发展。

尽管不是新概念，这两年LCNC关键词出现频率越来越高，颇有”出科技圈”的架势。究其原因，主要有几点：

编程思维变化: 一个横跨各个技术栈的趋势，是从“命令式”(Imperative)向“声明式”(Declarative)的转变。两者有何区别？命令式的核心在于“下指令”，声明式的关键在于“最终结果”。

一个简单的例子是，假如我想告诉朋友怎样来我家，使用命令式，我会说”先上101高速，从71号口下来，路过邮局向右拐，开过711以后的第二个路口左转就是“。这是一系列能够完成任务的 “指令”，却并不直接表达想要的结果；用声明式，只需要发给朋友一个地址，把导航的任务交给Google Maps就行了。 声明式的好处显而易见，工程师不用管理繁杂的中间过程，而是专注于”这段代码应该实现这个功能“。SQL是“声明式”编程类型最广为人知的例子之一，尽管已有45年历史，直至今天依然被广泛应用、拓展。著名的前端框架，比如ReactJS、VueJS，凭借着简洁易用的声明式API，快速取代了命令式的jQuery。同样的故事也发生在运维领域（Terraform）。

从命令式到声明式的转变，正是“抽象化”的一个绝佳体现，也是LCNC运动的精髓。如果你还记得上篇中我们对LCNC的定义：

“LCNC将产品开发流程中一个或多个步骤封装起来，可以更简单抽象地完成” 对“全代码开发”抽象化的尽头，便是LCNC —— NC最甚，把写代码本身给抽象没了。

数字表达欲: 自从我们的生活逐渐转移线上，大众对打造个性化的数字体验需求日益增加。从一个婚礼网站，到一个卖手工艺品的网上店铺，乃至一个公司内部团建小游戏，只要使用合适的无代码工具，都可以很快实现、上线。

当然，“我也可以搭XXX”的理念还未深入人心，现在依旧是对科技敏感的一批人“先富起来”。同时，许多LCNC工具还没能做到足够易用。但像上篇中，“快速建站”类产品的出现，上手难度的逐渐降低，“人人都是程序员”的一天终将到来。

坎坷的“云游记”：许多传统企业的“上云”之旅，几乎和唐僧西游一样艰辛。最大的困难莫过于技术人才的缺失。在科技行业的头部效应（薪资、光环、平台）愈加明显的今天，传统企业陈旧的组织框架很难笼络各地的技术精英。

LCNC无疑是这些企业最佳的“上云桥梁”。无论是数据云端化，还是打造个性化数字体验，是连通线上线下系统，还是流程自动化，这些公司无需雇佣昂贵的工程团队，反而可以依赖熟悉业务的已有团队，搭建合适的方案。

衡量一个LCNC产品，无论你是投资人，公司高管，还是技术负责人，都有一些共同的问题值得考虑。以下是我用来评价一款LCNC产品（下用X代替）的思路。

与原有的流程比，使用X，新功能的开发时间是否缩短了 五倍以上？

五小时之内，能否仅靠X的新手导引和开发文档，搭建一个简单的MVP？

新员工入职，能否在 五天内成为X的行家？

公司内已经建好的系统，能否在 五个月内完全迁移到新平台？

为接入X产品而需要做的定制接口、逻辑，X公司能否在 五周内交付？

与聘请一个工程师团队相比，使用X的短期总成本（TCO）是否在 五十分之一以内？

如果使用X的人数 增加五倍，或是使用量增加五倍，收到的账单会 增加五倍吗？

如果提供X产品的公司突然倒闭或下线，经过 五天的抢救和迁移，我们基于X的业务还能正常运转吗？

X产品的在线社区（论坛、Slack）里，提问是否在 五小时内能得到解答？

使用X产品时，是否有超过 5%的异常是我们自己解决不了，需要找客服的？

从使用者的角度来说，这个框架可以作为参考，区分出更为优质的LCNC产品。当然，正如上篇提到的，不同的服务对于工程流程的抽象程度不一样，套用“Rule of 5“的时候不应太死板。

尽管LCNC热火朝天，真正”跑出来“、成为独角兽的产品却并不多。大部分LCNC产品主要走to B路线，不免会遇到中小to B公司的难关，除此之外，还有一些这个领域独特的挑战。

向上销售的瓶颈：一款企业级LCNC产品，在竞争激烈的今天，很有可能选择“自下而上”的销售策略：定位小团队中的个人和一线工程师，快速获得产品反馈，通过廉价的口碑传播，达到一定规模后再雇佣昂贵的销售团队，争取大公司的大额订单。 向上销售是必要的，但对LCNC产品来说，这显得额外困难。大公司由于资源充足，很可能已经有工程团队搭建了”还凑合“的全代码方案。即使新产品的体验、效率更佳，在试图取代原有方案的销售过程中，很容易陷入内部政治斗争的泥沼。

这意味着大量的精力需要用于建立个人关系、允诺并实现各种定制，还得祈祷好运。另外，一旦涉及公司的核心业务或敏感数据，手握裁量权的管理者会格外慎重地评估，因为其绩效甚至前途都可能与之挂钩。

“买or造”与饭碗危机：没有人喜欢自己的工作被“抽象”或者“优化”掉——在公司成本和自己的饭碗之间，不会有人犹豫，这为LCNC产品（尤其是LC）带来巨大的进入阻力。 很多时候，由于管理层通常不自己写代码，评估一款LCNC产品的职责被交到tech lead手中。如果这款LCNC产品带来强烈的竞争和危机感，很有可能过不了这个”鬼门关“。最终，这样的评估会以工程师们 “ 这个没啥了不起的，我能在一周内搭出来” 的结论结束。 这样的LCNC产品，在营销和定位时，如同走钢丝：一方面，过于雄心勃勃的愿景容易引发工程团队的警惕；另一方面，过于低调谦和的姿态难以说服管理者其价值。

“ 买or造”与客户公司成长：在衡量是否继续订阅某个LCNC服务时，客户需要比较“买”和“造”的成本和利弊，这是一个长期、动态的博弈。 在客户公司规模尚小，工程力量不足的时候，“购买”是很划算、甚至是唯一的选择。 然而随着公司成长到一定规模，买和造之间的博弈逐渐变得模糊。如果继续”购买“，越大的公司意味着越多的用量、用户席位，以及越高的订单价格。另一方面，分出几个工程师来完成一个小项目，不再显得那么奢侈。如上图所示，当到达某个临界点，购买总成本大于自建成本，这个LCNC产品的订单就变得岌岌可危。

从全球范围来看，LCNC的迅速发展并不局限在美国，中国也有正在崛起的LCNC生态。

今年年初，钉钉宣布了打造低代码生态圈的新方向，让LCNC这一话题在企业服务圈子里火了一把，以至于有人 将2021年称为“低代码年”。

然而，当我们继续深挖，并且参考实际数据，会发现中国的LCNC版图比美国来的小得多：

从2016年到2020年，只有59起LCNC公司融资事件。

这其中的大部分公司，提供的都是在线协作或建站工具。

当然，我们不能简单地将其归因为中国尚未成熟的B2B市场环境——毕竟，企业服务大赛道的发展速率是LCNC的好多倍。我认为，最重要的两个原因是：

垄断性的大型电商平台：如果回去参考美国的LCNC版图，会发现电商建站工具以及聊天机器人，占有很大比重。这些LCNC工具的发展，得益于美国大量的独立商家。这些商家有着从建站，到营销，到客户服务的多样需求。

而在中国，这样的需求并不常见——众所周知，几大电商平台占据了绝大部分线上购物的空间。而这些平台所提供的服务极其完整，已经涵盖商家销售过程中的方方面面，从上线店铺到营销，从支付到客户服务。

“买”比“造”便宜：根据职友集统计，北京程序员平均年工资为16.4万人民币，而外卖骑手的平均年工资则为12万人民币。更别提，许多应届程序员的年工资还不到10万元。

如此充足、相较美国廉价多的技术资源供应，使得前文所描述的买、造天平，在中国大幅偏向“造”。同样，在美国相当火热的程序员工具、自动化工具领域，难以在中国吃得开——有工程问题？多安排几个程序员就行。

希望这个上下篇系列的LCNC介绍，能加深你对这个领域的了解，并且解答诸如“有哪些主要应用”、“为什么发展如此迅速”、“如何评价一款LCNC产品”的问题。无论你是投资人、创业者，还是在科技公司工作的工程师，LCNC都是不可忽视的新风口，可能会影响投资回报、创业和招聘的重心，或是饭碗的稳固。如同科技圈发生的任何事，机遇与挑战共存，积极应对永远优于苟安一角。

如果您喜欢所读的内容，请用email 订阅加入“互联” 。要想读以前的文章，请查阅 《互联档案》 。每周两次，新的文章将会直接送达您的邮箱。请在 Twitter 、 LinkedIn 、Clubhouse（@kevinsxu）上给个follow，和我交流互动！