摘要：本文由葡萄城技术团队于思否原创并首发。转载请注明出处：葡萄城官网，葡萄城为开发者提供业余的开发工具、解决方案和服务，赋能开发者。
首次接触低代码的程序员大多会纠结一个问题，为什么性能越弱小的低代码开发平台越不会提供导出源代码的性能？
要想答复这个问题，咱们得回顾一下低代码开发的发展史。事实上，反对导出源代码的低代码工具，是上一个时代的产品了。当初，大多数还有研发能力而且违心推动产品化的低代码厂商都曾经实现了或者正在进行向元数据驱动的转型。
站在 2023 年，国内低代码行业的厂商多样性太强，泥沙俱下。为了说清代码生成器和元数据驱动的差别和优缺点，咱们能够用 Windows 桌面程序的可视化开发作为类比，毕竟 Visual Studio 能够算是低代码的鼻祖之一了。
最后 Visual Studio 和更晚期的 Visual Basic 在设计界面时采纳了代码生成器的技术计划，IDE 将用户拖拽控件、设置属性的动作间接翻译成操作这些控件的代码。用户能够间接获取到这些代码，如果有须要则能够通过批改这些代码来实现对 VS 可视化开发能力的扩大。
（Visual Studio 生成的 WinForm 代码）
这种做法历史悠久，能够上溯到 90 年代。有点很显著，这种做法对 IDE 来说，实现起来最简略，用户入手批改起来也是比拟不便的。然而，如果用户真的应用这种做法开发一个大型的我的项目并长期保护，就会发现放任开发人员对 designer generated code 局部进行批改，先不提如何读懂设计器生成的没有正文的代码，很容易导致后续的可视化操作冲掉一部分手工批改的代码，甚至连可视化设计页面都无奈关上。可视化开发成了“一锤子买卖”，长期来看，可视化开发带来的开发效率和可维护性劣势都十分无限。毕竟，软件不是欲速不达的，而是须要长期的保护和迭代，能力充分发挥出价值。
为了解决这个问题，让可视化开发能够长期施展效用，微软在做新一代桌面利用开发方式时参考了 Web 中应用的 HTML 技术，2008 年推出了 WPF 技术。应用 Visual Studio 开发 WPF 利用的界面时，IDE 将用户拖拽控件、设置属性的后果保留为 XAML 格局（一种 XML）的元数据。因为 XAML 自身就是可视化设计的后果，能够和可视化设计器一一对应，用户对 XAML 的批改能够实时反馈到可视化设计页面，这就是 Visual Studio 默认的 Split 视图。用户能够随时在可视化开发和编码扩大之间切换，适配开发阶段和维护阶段。
（Visual Studio 生成的 WPF 元数据）
将面向过程的代码切换为面向后果的元数据，可视化开发从“一锤子买卖”到继续笼罩，可视化开发终于施展出了应有的价值。上面是两种技术路线的个性比照：
| 评估规范 | 生成源代码 | 生成元数据 |
|---|---|---|
| 产品化水平 | 低（需通过混同来爱护版权） | 高 |
| 扩大开发的举荐形式 | 批改生成的源代码 | 开发插件（元数据标签） |
| 可视化开发覆盖度 | 创立时 | 全生命周期 |
| 总体的可维护性 | 差 | 好 |
| 总体的开发效率 | 低（与编码开发靠近） | 高 |
回到文章结尾的问题。作为一名程序员，如果你心愿应用低代码开发工具构建并长期保护一个软件我的项目，请趁早摈弃“导出源代码”的想法，因为低代码最大的价值并不是像可配置的代码模板一样，首次创立一个页面或业务逻辑，而是升高长期的开发和保护老本。抉择一个产品化水平高（重点关注页面和逻辑设计的灵便度、文档、教程和开发者社区），采纳元数据驱动技术路线的低代码开发平台吧，比方葡萄城的活字格低代码开发平台，如果有必要依照厂商提供的相似于“插件”或“子系统集成”的形式进行扩大开发。
如果你做的是“一锤子买卖”的我的项目，后续将保护工作齐全移交给甲方，那就别用低代码。读他人写的代码很苦楚，读机器生成的没有正文的代码几乎是噩梦。大家都是程序员，同行何苦尴尬同行？