为什么很多程序员讨厌低代码？

“为什么很多程序员讨厌低代码？”。古有云“实践出真知”，大多数人在质疑和讨厌背后都有一些原因。但在我看来，更有可能是主观或无意识的偏见。在这里，我列出了一些关于低代码的常见问题和我个人的看法，希望能帮助你看到一个更全面和客观的低代码。

质疑1：低代码平台不好用

部分人尝试过一些所谓的低代码开发平台，要么能力很弱，要么体验太差，只能开发一些玩具应用。

作为一个深入体验国内外许多低代码产品的用户，我的观点是：不能以偏概全。低代码市场正处于国内爆发的早期阶段，所以许多软件开发平台也在蹭低代码的热点；但它们并不代表低代码当前的行业水平和发展方向。市场上真正成熟的 企业级低代码开发平台 完全有能力以高效的开发方式满足大多数复杂场景的功能需求，以及企业级应用程序所需的安全、性能、可伸缩性等非功能需求，在国外市场得到充分验证（不然也不会这么被寄予厚望）。

当然，国内市场仍处于混战阶段，遇到真正的龙的概率很低，但遇到金鱼鲤鱼甚至假木鱼是不可避免的。我相信，随着时间的推移，真正强大且声誉好的低代码产品是可以脱颖而出的，并为大家展示低代码产品真正的该有的样子。

质疑2：低代码开发不可控

低代码平台上的各种可视化组件、逻辑动作和部署环境都是黑盒，如何内部出问题无法排查和解决。

作为一个不知道底层原理的程序员，我更愿意相信问题只是暂时的。虽然这确实是目前使用低代码平台时不可避免的痛点，但并不是低代码技术本身的固有缺陷。

计算机领域有一句名言：任何问题都可以通过增加一个间接的中间层来解决。

低代码的想法也是如此：像当年的操作系统和当前的云平台一样，他们都希望通过建立一个黑盒子中间层抽象来减少开发者的工作量和精神负担。

当然，所有额外的中间层都不是完全免费的，低代码也不例外。作为一个不成熟和稳定的新中间层，低代码必然会出现各种让用户束手无措的问题，就跟当年的操作系统内核bug、如今的云主机I/O hang一样。

但历史规律也告诉我们，所有伟大的技术最终都会成熟；只要低代码领域健康发展，问题就会越来越少，最终会降到大多数人无法察觉的范围内。

过去萦绕在Windows用户心中挥之不去“蓝屏”问题，对于今天的新用户来说早已不知是何物；低代码开发者今天遇到的各种问题“蓝瘦”问题，未来也终将会成为被遗忘的历史(谁还没段黑历史呢)。

质疑3：低代码应用难维护

一旦应用程序变得复杂，各种复杂的逻辑流穿插自定义代码，看不懂也改不动，还不如全用代码呢。

用低代码开发，也要讲究基本法。一般来说，无论是低代码开发还是纯代码开发，应用可维护性低的根本原因往往不是开发工具，而是开发者本身没有遵循工程规范化、命名可读性等软件开发的一些普适原则。或者是DRY/KISS/SOLID原则等。

一个好的低代码平台永远不会阻碍开发者提高应用程序的可维护性；相反，它会尽可能地提供指导和帮助。例如Mendix，除了支持基本的模型分析和重构外，（e.g. 无用模型、对象重命名、子逻辑流提取)，它甚至提供了基于它的ISO/IEC25010标准应用质量监测（AQM）能力。

另一方面，难以维护应用的客观原因之一是应用本身过于复杂，而低代码作为一种高度抽象和自动化的开发模式，在降低应用复杂性方面是专业的。

总的来说，虽然低代码不是解决所有问题的“银弹”，但也不是带来更多问题的炸弹：在提高应用可维护性方面的上限，一定比传统开发模式更高；但决定应用可维护性下限的，依然还是开发者自己。