低代码不是行业毒瘤，你才是（低代码 行业毒瘤）

文/明道云创始人任向晖

著名的IT咨询公司ThoughtWorks在中国有一名徐姓CTO。他曾经在自己的视频号上公开攻击低代码市场，列出的理由却十分可笑。我看了全文后，相信这位CTO根本没有动手实践过，至少没有全面研究过，完全在望文生义，自我想象。

本来我也懒得回应这种低劣的行业评论，可是世道险恶，我心中的IT媒体圣地InfoQ居然在节前发表头条文章《为什么我说低代码是“行业毒瘤”？》。

在科技行业，各种技术热点层出不穷，褒贬争议也永远在起伏抑扬。可是，我从业二十多年，还没看到过一个科技媒体用“毒瘤”这种词汇来指责一个技术门类。我真不知道这位CTO从哪里来的愤慨？InfoQ出于什么动机要将这种文章作为头条发表？

情绪先放一下。我们先讲道理。

低代码预设的人群是初级和入门的人？

徐CTO认为LCAP产品是为入门程序员准备的，程序员成长了，就用不上了。甚至拿低代码平台和Scratch儿童编程来类比。这是对低代码产品目标的根本性误解。

这一代的LCAP毅然决然地要面向程序员以外的人，尤其是有一定IT素养的业务人员。他们在企业组织中往往是业务流程设计和管理的骨干人员，但是为了实现数字化工具，他们不得不费老大劲和开发人员沟通需求。业务的Know- How并不能直接表达为软件需求，所以为了沟通清楚一个IT系统的需求和标准，不得不嘴上说着，手上画着，业务人员恨不得和开发人员灵魂合体。

这个过程就是这么难。IT行业的人对行业需求一知半解，不知轻重。行业专家对软件实现机制也是门外汉。能够让行业经验和软件技术成功融合的产品和项目实属罕见。

尽管这么难，我依然看到很多传统行业的人不知畏惧地投入，做出一个又一个专业度有限的软件系统。这样的系统往往缺陷率高，抽象水平低，扩展性差。即便这样，能够做出一个可用的系统已经属于幸运者。大部分定制开发的系统都存在严重的可用性问题，最终被束之高阁。我听到过很多次这样的表述："我们几年前花XX万做了一个系统，后来也用不下去…."。这种资源浪费徐CTO想必是没有感同身受的。

站在服务者的角度，有多少软件开发公司的工程师们被派去遥远的城市，在城乡结合部从事外包驻场开发。这些软件工程师拿的薪水今天和农民工几乎一样，是真正意义上的码农。他们在客户的场地，可不能像徐CTO那样挥斥方遒，相反，他们要么在无尽地等待客户领导的需求，要么就是顶着进度的压力挑灯夜战。

你说这样的工作方式和产业现状值得维护？你说程序员在这样的环境中能够成长？

我们不可能等待程序员成长，就算成长，数量也远远不够。产业数字化唯一的解决方案就是让信息系统的建设离开对程序员的依赖，离开对专业DevOps过程的依赖，让更多的角色可以有效地参与进来。这些角色包括行业内的业务专家，运营和管理专家，软件行业内的产品经理，项目经理和实施专家。有了这些扩充的参与者，企业数字化建设就会大幅加速。甚至，连质量都远远高于传统开发模式。

第二，徐CTO认为低代码平台暗含巨大的变革成本。他说的对，不过他说的变革成本和我们面临的不是一件事。他说低代码平台改变了原有开发过程中的工作方式，不仅没有提高效率，反而增加了很多试错成本。而我认为，真正的软件开发团队的工作方式不需要任何的变化。你们应该继续使用日新月异的技术栈从事原生软件开发。真正的LCAP不是为了去取代高级语言的。

企业应用领域的LCAP到底取代的是什么呢？一句话 —— 那些模式高度一致的企业中后台应用。形象一点说，就是长这个样子的应用：

是不是很眼熟？无论CRM，ERP，还是ERP，MES，这些软件门类都是属于企业中后台应用，它们都是围绕关系数据库而建立数据管理和工作流程。实际上，企业应用中90%以上的应用都是这个模型，业内称为CRUD（数据增删查改）应用。正是因为模式上的一致性，让我们得以有机会抽象出这类应用构建所需要的基本要素，并且将这些要素的颗粒度充分提高，灵活组合，得以满足千变万化的具体场景。在我们的明道云中，这些基本要素包括工作表、视图、统计、用户权限、工作流和页面。每一个要素都通过可视化应用配置的方式来面向非程序员，只有在个别的环节允许程序员写一些代码来进一步提高灵活性。

我调研过，在定制开发的企业应用中，目前有九成以上都使用了Ants前端框架，这是阿里巴巴提供的一个开源前端组件。这个组件所提供的所有范式基本上就围绕CRUD场景而展开的。所以，即使使用Java、C#或者PHP等高级语言开发的原生应用，也遵照的是同一个范式。既然模型如此稳定，为什么每个应用都要从第一行代码开始写起呢？这就是LCAP产品为之努力的方向，在这个特定的应用类型下，用积木搭建的方式来取代DevOps过程，因为后者就是离不开程序员。

有人又质疑，企业应用没有增删查改那么简单。高级的ERP怎么怎么样复杂，算法如何如何先进，低代码都搞不定，像你们明道云标榜的零代码肯定没戏。有这个疑问的人，我建议你先动手实践。再不济，看看案例和视频也可以。你要相信，一代一代产品的努力，我们总是无限接近最佳的结果。企业应用中的复杂问题并不是只有代码开发一种方案，LCAP或者称为APaaS的这一代产品不可能停留在20年前，我们只是用了不同的解决方案。航天发动机够复杂吧？人家是怎么解决的？是将巨大的复杂问题拆解成若干个子系统，每个子系统再拆分为子子系统，最终落实一个个的简单问题。APaaS也不例外。有兴趣的，可以扩展阅读《APaaS搞不定复杂应用，是这样吗？》

怀疑是没有用的，动手干才是真谛。

所以，我所看到的变革成本，正是徐CTO你这种人的存在。倚仗着专业出身，大厂履历，干着指点江山的便宜活。IT评论家可以存在，但ThoughtWorks这样的组织，应该站在产业的最前沿，给大伙的创新带个头，而不是老气横秋地指摘创新行动。创新的言论可能天真，守旧的语气实在令人厌恶。他还在一个小视频里质问低代码产品是否"图灵完备"？掉书袋掉到裤裆里了。

低代码不会是永远的风口，那又怎么样？

徐CTO认为今天低代码的热度是不会持续的，风口总归会过去。但这等于是废话。没有不会过去的风口。你知道1970年企业IT界最大的风口是什么吗？关系数据库！今天你听到有人说关系数据库是风口吗？当然不会，但是你看看关系数据库今天的普及程度和使用率？

连我自己都希望这个风口快点过去。天天被行业谈论，难免遇到你这种幺蛾子。只有风口过去，APaaS才能真正主流化，传统用户开始采纳，产品变得更加成熟，纷争变得没有意义。这是IT行业几十年来不变的节奏。如果你真的理解IT行业的真谛，就不会说出"低代码是行业毒瘤"这种话来。至于InfoQ的编辑，也请你们回归到技术媒体的本分，多提供知识和方法论，少一些妄断。如果你把徐CTO的观点选编为头条，那么也请置顶我的这篇。

祝读者劳动节快乐！