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