大家好，我是Kason。您是否注意到，每隔几年，低代码的概念就会被炒作并大肆宣传。难怪软件行业最大的成本是人工成本（程序员的工资）。Low-code号称能够：一个外包替代几个程序员，产品、设计、财务人员替代程序员，xxxx替代程序员。一个唯一的程序，资本怎能不爱一个即使员工受伤也能降本增效的世界。这个概念被翻来覆去炒了这么多年，为什么市面上一直没有出现颠覆程序员工作方式的低代码平台呢？今天，我们就来聊聊这个话题。欢迎加入人类优质前端框架群，飞翔的低代码，我们说的是同一个东西吗？程序员眼中的低代码和资本眼中的低代码是一回事吗？对于程序员来说，低代码的概念更接近DSL。例如，JSX是对DOM的抽象。如果说直接编写和操作DOM的方法是代码，那么使用JSXDSL编写的React代码就是低代码。因为前者是开发者针对宿主环境（浏览器）直接命令式编写代码。后者是供开发人员以声明方式操作状态，而React这种低代码平台将状态变化转换为操作DOM的方法。对于资本来说，低代码的概念更接近于Jenny纺纱机，有了他，纺纱师（程序员）的人生就可以改变。为什么前者的开发模式能够在行业内大规模推广，而后者却不能？这就是关于它们之间的本质区别——是工具还是平台？工具与平台工具和平台的目的是降低成本和提高效率。它们之间有什么区别？应用程序从开发到发布的平稳运行涉及许多不同类型的工作。工具降本增效的方式就是帮助从事这些工作的工种降本增效，例如：前后端框架提高业务开发效率Git用于代码管理多时人们协作GithubAction是用来改进CI和CD流程和平台降低成本和提高效率的方法，就是将工作流程和工作内容抽象成模块，这样即使是外行也可以拼凑出一个应用程序，只要他们会组装不同的模块。也就是说，前者通过提高专业人员的效率来降本增效，而后者则以直观的方式降低工作门槛，让非专业人员代替专业人员。但是这里有个问题——虽然平台屏蔽了软件开发的复杂性，但是他无法避免软件开发会遇到的问题。例如：如何处理定制化需求？低代码平台遇到模块组装无法满足的定制化需求怎么办？业界常见的解决方案是为低代码平台保留编写代码的能力。毕竟，低代码平台的产品也是代码。只要产品代码结构清晰，程序员仍然可以在此基础上开发定制需求。但问题在于，随着程序员的介入，低代码平台所提倡的以下映射条件：从非专业人员组装的模块到应用变成：从非专业人员组装的模块到程序员的补丁码到应用的后续这种应用的迭代还需要程序员介入吗？这成本不回来了吗？如何协作开发现在我们假设有一个巨大的低代码平台，非常好用，大大提高了开发效率。老板看到员工闲着，不比股市下跌难受。于是，马上拍拍脑袋安排新的需求开发。开发人员不够，怎么办？招聘。这些人如何在低代码平台上协作？是否可以在平台中再次引入Git的概念？如何测试是一个应用程序会不会有bug。低代码平台再完善，也能解决模块本身的单体测试，但E2E测试谁来做？金融？思路就是打开上面提到的各种问题，随着项目的复杂度增加，维护时间变长，就会出现。那么如何解决呢？在这里告诉我答案，如果有人知道答案，请告诉我。如果解决不了，那我们换个思路，怎样才能不让项目的复杂度增加呢？不要让项目维护时间变长？然后限定低代码平台的应用场景，比如：开发一个营销活动页面的低代码平台，开发一个公司官网的低代码平台。之前收钱不就好了吗？不容易被互联网忽悠，所以我们可以帮助传统企业进行数字化转型。20分钟即可为您搭建好官网。这样的转变速度，未来可期。请转账付款。理想的低代码平台平台型低代码难以打通，工具型低代码前景广阔。以React为例。在使用React之前，前端开发人员直接操作DOM。使用React，将业务的前端逻辑封装到称为组件的模块中。接下来，React提出了ServerComponents，它可以运行在服务器端。这一步也将业务的服务端逻辑封装到了组件中。同时，Hooks可以链接到前端的视图状态和后端的微服务。你喜欢这个基于组件和Hooks的低代码工具吗？
