低代码指南100问：13为什么「我不」需要低代码？

为什么「我不」需要低代码？

即使所有人都认同上述“为什么要用低代码”的理由，但仍不时会有试水者跳出来，给大家细数“为什么我不需要低代码”。实践出真知没错，而且大部分质疑背后也都有一定道理；但在我看来，更多的可能是主观或无意识的偏见。这里我列了一些对低代码的常见质疑和我个人的看法，期望能帮助大家看到一个更全面和客观的低代码。

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

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

作为调研过国内外多款低代码产品的深度体验用户，我的观点是：不能以偏概全。低代码市场在国内正处于爆发初期，所以许多与低代码只沾一点边的产品也都在蹭热点；但它们并不能代表低代码目前的业界水平和发展方向。市面上真正成熟的企业级低代码开发平台，完全有能力以高效的开发方式满足大部分复杂场景的功能需求，以及企业级应用所需要的安全、性能、可伸缩等非功能需求，这一点在国外市场已得到充分验证（不然也不会这么被寄予厚望）。

当然，国内市场尚处于鱼龙混杂的混战阶段，遇到真龙的概率很低，但碰上金鱼鲤鱼甚至木头假鱼都在所难免。相信随着时间推移，真正有实力和口碑的产品都能脱颖而出，为大家展现低代码该有的样子。

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

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

作为同样不搞清楚底层原理不舒服斯基的程序员，我更愿意相信：问题只是暂时的。虽然这确实是目前使用低代码平台时绕不开的一个痛点，但并不属于低代码技术本身的固有缺陷。计算机领域有一句至理名言：任何问题都可以通过增加一个间接的中间层来解决。低代码的思路亦是如此：与当年的操作系统和现在的云平台一样，都是想通过建立一个黑盒化的中间层抽象来降低开发者的工作量与心智负担。

当然，所有额外增加的中间层都不是完全免费的，低代码也不例外。作为一个尚未成熟稳定的新的中间层，低代码必然会出现各种让使用者束手无措的问题，就跟当年的操作系统内核bug、如今的云主机I/O hang一样。但历史规律也告诉我们，所有伟大的技术最终都会走向成熟；只要低代码领域一直健康发展，问题总会越来越少，最终降到一个绝大部分人感知不到的范围内。过去萦绕在Windows用户心中挥之不去的“蓝屏”问题，对如今的新用户来说早已不知为何物；今天低代码开发者所遇到的种种“蓝瘦”问题，未来也终将成为被遗忘的历史（谁还没段黑历史呢）。

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

“应用一旦复杂起来，各种复杂逻辑流穿插着自定义代码，看不懂也改不动，还不如全用代码呢。”

作为对软件可维护性深有感触的无脑级布道者（见《救火必备！问题排查与系统优化手册》），我不得不说：用低代码开发，也要讲基本法。一般来说，无论是使用低代码开发还是纯代码开发，造成应用可维护性低的根本原因往往不在于开发工具，而是开发者自身没有去遵循一些软件开发的普适原则，比如工程规范性、命名可读性、DRY/KISS/SOLID原则等。

好的低代码平台绝不会阻碍开发者去改善应用的可维护性；恰恰相反，还会尽可能提供引导和帮助。以Mendix为例，除了支持基本的模型分析与重构（e.g. 无用模型、对象重命名、子逻辑流提取）以外，甚至还提供了基于ISO/IEC 25010标准的应用质量监控（AQM）能力。另一方面，让应用变得难以维护的一个客观原因也是应用本身过于复杂，而低代码作为高度抽象和自动化的开发模式，在降低应用复杂度方面是专业的。

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