低代码会取代软件工程师吗？低代码是如何实现降本增效的？图形化编程有未来吗？... 本文对这些具体的问题给出回答。
低代码会取代软件工程师吗？
答案是显然的，低代码会取代部分软件工程师。具体来讲，一部分从事业务开发的工程师会被逐渐取代，比如一部分做业务页面开发的前端工程师、移动端工程师、一部分专注业务逻辑开发的后端工程师、BI分析师，部分测试工程师、系统集成人员等。
前文中提到，低代码是新的数字化浪潮下新型生产力的一部分，在任何的科技进步过程中，工具一旦强大到某种程度、部分人工被取代是必然会发生的。
事实上，这个变化已经出现，例如，包括阿里巴巴、字节跳动等互联网公司，目前在中后台系统、营销活动等场景，尤其是页面部分，以往以P5、P6为开发主体的正式员工正逐渐被外包工程师所取代，这些来自外包公司的工程师通过使用低代码工具，快速实施业务。
那么这部分工程师怎么办呢？其实，**在一部分低技术含量的工作被工具取代的同时，也给了工程师们更多发挥自身创造力的机会，从而重塑工程师的价值。**目前来看，在低代码的生态结构中，之前的业务开发工程师可以转型参与建设各类平台、工具、服务，设计开发搭建过程中所需要的物料，或者借助此前的工作优势，成为既懂业务又精通实施工具的业务开发专家。
低代码降本增效的原理是什么？
长期实践发现，在应用软件建设过程中，生产效能与以下三个部分呈相关性：可复用比例、单位产能与协同方式。
可复用比例，指的是面对新的需求，可以直接复用的过往功能模块在新交付应用中的占比。
单位产能指的是个体的生产能力。协同方式体现了建设过程中各个参与角色的组织结构、生产排期流程，信息沟通传递等各个方面。
可复用比例与单位产能是生产力的范畴，协同方式是生产关系的范畴。
**生产效能与可复用比例、单位产能成正比，与协同方式的复杂度成反比。**低代码对于生产效能的提升，重点体现在提升可复用比例与优化协同成本等方面。
低代码之所以能够提升可复用比例，关键之处在于建立了一套“面向物料”的新型生产协作方式。物料是构成软件应用的“乐高积木”，低代码将软件应用的开发过程转化为拼装组合物料的过程，从需求分析、产品设计到研发实现，所有阶段以物料为核心关注要素，有一系列配套流程对各类指标进行规范与保障。关于这方面的更多论述，请参阅本系列中“低代码方法论”一章。
图形化编排能够代替编写代码吗？
图形化编排作为低代码尤其是无代码的重要能力之一，可以代替一部分文本编程，但并不是说完全不需要文本编程。即使是无代码，在实际使用中仍然需要一部分“文本编程”，这包括了编写一部分逻辑运算表达式或者简单的DSL、为元素做标识符命名等方面。
在图形化编排方面，低代码不是将原先的文本编程简单的转化为图形化编程。事实上，现今的一些图形化编程，例如Scratch，只是将原来的代码图形符号化，本质上依然是文本编程。图形化编排是低代码图形化的一种，低代码中的图形化更像是面向开发者的GUI（图形界面用户接口），关于这方面的详细论述，请参阅本系列中的“Mybricks生产力开发语言”一章。
Scratch图形化编程
无代码也有学习成本吗？
无代码也是有一定学习应用成本的，概括来讲，通用意义的无代码产品使用成本介于Axure、Figma等原型工具与需要使用复杂公式以及VBA语言的Excel之间。
我们曾经在《低代码的争议：行业毒瘤还是银弹良药》一文中提到通用无代码与PPT、原型工具、传统编程的学习成本对比：
概括来讲，面向业务人员的无代码产品需要用户需要具备以下能力：
-
熟悉了解某个领域的业务规则以及相关应用。用户需要对自己领域的业务知识有充分的了解，同时对于该领域常见的各类应用软件有充分的了解，例如业务场景、用例、交互方式等，并有一定的评判能力。
-
对低代码有必要的了解及基础知识准备。这包括低代码是什么，如何运用低代码工具解决自己的问题，哪些问题可以自己解决，哪些问题需要寻求专业技术人员的帮助等。
-
工程应用基础知识。对计算机的各类术语有一定的了解，对于应用程序的各个组成部分，例如界面、服务、连接器、数据库等概念有基本的认知，理解数据类型、表达式、逻辑判断等基本编程能力。
Mybricks通用低代码平台中的数据类型
更多的常见问题，我们将在本系列的其他章节中展开。
感谢阅读，下一篇文章，我们介绍一下低代码领域的有代表性产品。
欢迎访问免费、通用的无代码开发平台Mybricks ，体验图形化编程的乐趣
