为什么低代码和专业代码走向融合才能破解低代码困境？

        近年来，低代码开发平台勃然兴起，成为业界的“当红炸子鸡”。但随着推广和投入应用，低代码平台却遭遇了强烈的质疑，尤其是开发人员和专业人士的反对，这方面的典型文章有许多，比如：

• 《“行业毒瘤”低代码》

• 《如何用低代码搞垮一个公司》

• 《低代码，不要以比“中台”还快的速度臭大街》

• 《帮手还是鸡肋？低代码的未来悬而未决》

• ......

        这些文章和观点的结论基本一致：低代码概念很好，但在实际应用中有重大缺陷。为此，我们请起步科技牛刀低代码平台架构组就此进行深度分析探讨，发表争鸣文章，也欢迎按文末所述方式加入微信群更详细讨论，以期共同探讨进步。

一、低代码开发平台为何遭遇强烈质疑？

        为什么低代码平台会遭遇业界的强烈质疑？归根到底，是因为这样一个具有普遍性的基本事实：低代码的确大幅提升了应用系统中“70%~80%部分”的开发效率（六到十几倍），但是，针对应用开发中20~30%的重要或关键需求，低代码开发无法满足，导致应用系统烂尾和无法交付！说白了就是很“鸡肋”。

        在复杂的企业业务应用开发中，低代码工具“七八成做起来很快捷，剩下的两三成做不了”而导致项目烂尾，是一个高发的现象，这不仅引发了企业应用开发者的强烈质疑，也使得低代码工具的推广遭遇了很大的阻力，因此，很有必要对这个问题进行深度探讨，找到问题的关键症结，并给出有效的解决方案。

二、低代码的产品定位有重大问题

        在我看来这个问题产生的根源就是低代码开发平台的产品定位有问题。

        无代码的产品定位是非常清晰的，就是那些没有专业技术的业务人员，让他们可以完全不懂编程也能做出软件来，哪怕能力是受限的也没有关系，简单好用，能解决日常信息化问题就可以。

        而低代码平台即希望能让业务人员使用，也希望能让开发人员可以接受，这种定位下所产生的产品明显是两不讨好的。

        低代码平台之所以区别于无代码平台的关键，是可以有更强的定制能力，既要像无代码一样可以简单拖拽出简单应用，也要能做复杂应用。这时候必然要采用一些模型设计、表达式、逻辑编排、脚本等工具和手段，但是这些明显是有技术门槛的，什么是数据库？什么是服务？什么是函数？出错了怎么分析日志？怎么调试？这些对于业务人员来说完全就像天书一样！

        21CTO在《低代码开发可不低，用户仍需要与IT技术部门联手》文中提到，经过统计只有6%的低代码开发是由业务人员完成的。也就是说，低代码平台真实的广大受众是开发人员，而不是业务人员。

<