怎么看待争议 低代码？（怎么看待争议 低代码的问题）

怎么看待争议 低代码？（怎么看待争议 低代码的问题）

作为一个有过相关开发经验的码农，过来简单谈几句自己的想法：

首先，低代码平台并不能单纯说是好是坏，这样评价太片面了，它能流行起来，肯定有它的可取之处，但是现在争议之所以这么大，跟很多因素相关，先说好的吧。

它的优势在于能够极大地提高开发速度和降低技术门槛。对于一些标准化的业务流程，使用低代码平台可以相当快地搭建出一个稳定的原型或甚至是生产级应用，这个快是什么概念呢，大概是之前开发速度的 3-5 倍，就这么朴实无华，一点没夸张。

这种快速迭代和验证市场相当有利。就像是在搭积木，你不需要知道每一个积木是怎么制造出来的，只需要知道它们如何组合在一起。对于非技术背景的人来说，也有一个很大的好处，可以直接参与到应用的构建中，不需要深入了解编程语言和开发细节。

传统软件开发步骤最大痛点是什么？不是代码、不是bug、也不是什么业务逻辑，是沟通！

大部分的问题都是老板或者产品经理不知道自己想要啥，做成什么样，对软件需求不明，你在一开始没有一个完善的解决方案，导致我们就要边做边改，有可能产品今天冒出个什么想法，改！明天又冒出个什么想法，改！市场遭遇冷淡？改！于是，无数夹杂着唾骂、琐碎、怨恨和无力的情绪在琐碎的修改和推翻重来的时间里默默自己消化。

现在就跟以前不一样，在低代码平台上快速搭建起基本模型， 再根据实际应用的使用体验反馈完善方案，这种速度不晓得快过以前多少，起码推翻重来的是很少数了。

不过，实际应用中，低代码平台也不是万能的，往往适用于中小型项目，或者是企业内部的一些工作流程自动化。这些场景下，低代码平台可以大大减少开发工作量，提高工作效率。

但是，一旦涉及到更复杂的系统，特别是需要高度定制化的场景时，低代码平台的局限性就显现出来了——无法提供足够的灵活性来满足特定的业务需求，或者在性能优化方面不如手工编码那样精细，就像是当你需要一个定制化的解决方案时，预制的积木可能就不够用了，你得自己做这块积木出来。还有一种情况是，很多低代码平台本身就是个黑盒，一旦内部出现bug或崩溃，我们就只能干瞪眼，完全没有办法，只能等官方的维护修理。

上面的缺点都还能忍受，但低代码最大的问题，在于它可能会导致技术债务。

在低代码平台上快速搭建的应用，可能在未来难以维护和扩展，一旦业务需求超出了平台的能力范围，就可能需要进行大规模的重构，甚至是重新编码。

另外，过分依赖低代码平台也可能导致程序员群体的技术能力退化，因为不再需要深入底层技术，这就像是一直使用计算器做数学题，久而久之可能就会忘记如何手动计算了。

我觉得能解决上述问题的唯一方法就是导出源码，所以后面我们自己的团队也换用 iVX 了，独立导出源码，独立部署，生成代码的质量还高，也不会说丧失我们自己的专业能力，把代码导出到其他平台，照样能用，也没有重构编码的担忧了，目前算是一个还不错的平衡。