当初接触低代码开发的程序员们常常会纠结一个问题：为什么那些功能越强大的低代码开发平台越不给我们导出源代码的机会呢？
要回答这个问题，我们得回顾一下低代码开发的发展历程。事实上，支持导出源代码的低代码工具已经是上一代的产品了。现如今，那些具备研发能力并致力于推进产品化的低代码供应商，大多已经完成或正在进行元数据驱动的转型。
站在2023年，国内的低代码行业涌现出众多供应商，形形色色，五花八门。为了更好地解释代码生成器与元数据驱动之间的区别、优劣势，我们可以借用Windows桌面应用程序的可视化开发作为类比，毕竟Visual Studio可以被视为低代码的先驱之一。
早期的Visual Studio和Visual Basic等工具在设计界面时采用了代码生成器的技术方案。这些集成开发环境（IDE）会将用户拖拽控件、设置属性等操作直接转换为相应控件的代码。用户可以直接获得这些代码，如果需要的话，还可以通过修改这些代码来扩展Visual Studio的可视化开发能力。
（Visual Studio 生成的WinForm代码）
这种做法历史悠久，可以追溯到90年代。显而易见的是，这种做法对IDE来说实现起来最简单，而且用户也相对容易进行手动修改。然而，如果用户真的使用这种方法开发一个大型项目并长期维护，就会发现允许开发人员修改“由设计器生成的代码”部分的问题。暂且不提如何阅读没有注释的由设计器生成的代码，稍有不慎就可能导致可视化操作覆盖了手动修改的代码，甚至可能无法打开可视化设计页面。可视化开发变得像是“一锤子买卖”，从长远来看，可视化开发带来的效率和可维护性优势非常有限。毕竟，软件的开发并非一蹴而就，而是需要长期的维护和迭代才能充分发挥其价值。
为了解决这个问题，使可视化开发能够持续发挥作用，微软参考了Web开发中使用的HTML技术，在2008年推出了WPF技术。使用Visual Studio开发WPF应用时，IDE将用户拖拽控件、设置属性的结果保存为XAML格式（一种XML）的元数据。因为XAML本身就是可视化设计的结果，可以与可视化设计器一一对应，用户对XAML的修改可以实时反映到可视化设计页面，这就是Visual Studio中默认的“Split视图”。用户可以随时在可视化开发和编码扩展之间切换，适应开发和维护阶段。
（Visual Studio生成的WPF元数据）
将面向过程的代码切换为面向结果的元数据，使得可视化开发不再是“一锤子买卖”，而是持续覆盖。可视化开发终于发挥出了应有的价值。以下是两种技术路线的特性对比：
评价标准 | 生成源代码 | 生成元数据 |
产品化程度 | 低（需通过混淆来保护版权） | 高 |
扩展开发的推荐方式 | 修改生成的源代码 | 开发插件（元数据标签） |
可视化开发覆盖度 | 创建时 | 全生命周期 |
总体的可维护性 | 差 | 好 |
总体的开发效率 | 低（与编码开发接近） | 高 |
回到文章开头的问题。作为一名程序员，如果你希望使用低代码开发工具构建并长期维护一个软件项目，请及早抛弃“导出源代码”的想法。因为低代码的最大价值不在于像可配置的代码模板一样，初次创建一个页面或业务逻辑，而是降低长期开发和维护的成本。选择一个产品化程度高（特别关注页面和逻辑设计的灵活性）、提供文档、教程和开发者社区支持的元数据驱动低代码开发平台，比如葡萄城的活字格低代码开发平台。如果有必要，可以按照厂商提供的类似于“插件”或“子系统集成”的方式进行扩展开发。
如果你的项目只是“一锤子买卖”，后续维护工作完全交给甲方，那就不要选择低代码开发。读别人编写的代码已经够让人头疼了，阅读由机器生成的没有注释的代码简直是一场噩梦。我们都是程序员，何必为难同行呢？
葡萄城热门产品
