iVX虽然是图形化编程，但“我们不一样”

最新推荐文章于 2024-07-01 18:36:20 发布

是小喵咪呀

最新推荐文章于 2024-07-01 18:36:20 发布

阅读量896

点赞数 10

文章标签：低代码程序员创富团队开发个人开发

本文链接：https://blog.csdn.net/hicode001/article/details/136342641

版权

文章讨论了iVX作为一种成熟的图形化编程语言，如何通过去除画图环节、采用面向组件编程和高度抽象的逻辑块，显著提高编程效率。尽管早期图形化编程常被质疑效率低，iVX通过一站式开发流程和先进技术，证明其在复杂应用开发中的潜力。

摘要由CSDN通过智能技术生成

首先简单介绍一下iVX。iVX基本上算一个比较成熟的“全栈图形化编程语言”，自带IDE，自动对接云资源的产品。这种编程语言内化到了图形化界面和操作中，通过“生成器（Generator）”的方法再生成多种前端、后台和数据库语言。无论功能、性能、扩展性、兼容性应该都是这个领域内杰出的代表。

大家可能也清楚，无论编程语言还是IDE，要想做好都是一个非常费时费力的过程，基本上都是10年起的事儿，据我所知iVX做到现在这个程度，差不多花了17年的时间！

我和一些朋友说起图形化编程（或图形化编程语言），很多人就是“一脸鄙夷”的样子😅，有几种最常见的想法，在这里我来给大家仔细分析和回应一下：

图形化编程效率低？

常见的几种观点：

“不就是程序流程图吗？我高中就用过，那个实在是太慢了...不可能用来做应用开发...”

“我敲键盘/写代码的速度很快，我就不信图形化操作比我键盘还快?...”

“图形化编程就是画图... 我不会画，画起来也慢...”

也大家分享一下，常见的几种图形化编程软件和工作方式：

（1）最早期的“程序逻辑线框图”，拖拽画图，效率也是最低的，无封装

（2）近代的，还在使用的“用于数据流编程的Labview/NodeRed”，拖拽画图，强大直观，效率有所提升（在数据处理和测试等领域的编程）

（3）特殊“儿童/青少年编程”的“scratch/blockly”，拼接画图，把语法拆成逻辑块，效率低，但比较有趣，适合小朋友

（4）低代码领域Mendix/Outsystems等，拖拽画图，效率有所提升，操作繁琐，整体空间信息密度还是相对较低（大量留白，连线太多就会乱）

其实也不能怪大家，传统的“图形化”编程方式，确实存在很多问题，其中最核心的就是“效率低”，导致这种方式无法实现“真正生产力”上对研发效率的提升。

大家再看一下iVX的解决方案：

（1）iVX前端逻辑的开发

（2）iVX后台逻辑的开发（包含数据库代码生成）

（3）开发完后一站式预览、调试、导出代码（可选）、上线运维

通过这种直观的方式为了给大家说明几个问题：

虽然也是图形化的编程方式，但是iVX不画图！这个很重要，因为画图本身就效率很低，有时候甚至需要排版和设计，而且多数情况下画图的空间信息利用率并不高，也就是说“信息密度”通常都很小。（也不知道是谁一开始就是把“图形化”编程往画图这个坑里带，一代一代的图形化编程都是走这条老路，因此一直发展不起来。）

iVX主要操作就是点击鼠标，直接操作各种封装好的组件进行逻辑的拼接，如果要定义一种编程范式，我觉得可以叫“面向组件编程”。（这个有点像DOS到Windows的感觉，Windows把操作都封装在可点击的对象里面，无论学习和操作都带来很大效率上的提升，除了一些坚守“键盘操作”的极客以外，多数用户都投向了图形化操作系统的怀抱。对于iVX不同层次的可高度抽象的丰富组件和内部方法，其编程效率也会显著提升）

iVX“去掉程序语法，只保留程序逻辑”，把以前编程语言的“控制结构if while for swich 等”只保留最基本的结构，并抽象成逻辑块，把“控制结构”和“结构内部的逻辑表达”区分开来（听起来可能比较抽象），进一步提升逻辑表达效率。（Scratch虽然也是块，但是几乎是复用所有语法控制结构，导致结构还是比较复杂，效率较低。）

iVX追求最少的窗口和最少的点击次数，探索编程可能的最短路径；追求“逻辑简单 > 操作简单”，走了一条完全不同于以前图形化编程的技术路线。

因此同样是图形化编程，通过“图形化”方式表达程序逻辑，但是iVX效率上会有非常大的提升！现阶段iVX一次有效操作，平均生成300行以上代码。

图形化编程架构差，技术落后？

几种常见观点：

“VB我就用过啦，后来不用了...被鄙视了...”

“Dreamweaver用过，后来也被鄙视，不用了...”

造成技术落后的几个原因：

（1）图形化编程，本身技术复杂，而且IDE是一个非常“重”的东西！

图形化编程涉及到方方面面，编译器/解释器、代码生成、组件设计、中间语言设计和生成、多人开发、版本管理、debug/测试、运维... 再加上IDE开发，使得整个项目非常复杂，而且“牵一发动全身”维护和升级成本都很高。如果技术选型中出现什么问题，那基本上就是灾难性的...相比“文本编程（现在的高级语言）”图形化要更新迭代要艰难很多。

（2）技术进步速度太快

图形化产品如果开放性不够，例如自定义组件不成熟，或无法接入云计算，就会导致技术升级能力比技术进步要滞后很多的现象。如果采用架构再比较落后，基本上后面就很难有大的改进了。因此，本身图形化编程就是难度很大，赌性十足的项目方向。

iVX的做法：

（1）尽量保持架构的灵活，引入最新的软件概念和能力。例如前后台分离、微服务、数据驱动、Serverless（函数计算）、技术/数据中台等。

（2）对代码的高度友好，iVX与代码实现“充分非必要”的关系。这里面包含分层的自定义组件、小模块、模型的设计，以及云计算产品/数据库产品组件化接入的设计。同时允许方便引入各种前端库和npm包，后台引入各种语言的SDK等。

（3）生成公认标准的框架代码，例如前端生成vue/react可用代码等。

总之在技术上，保持生成的代码运行效率较高，并尽可能保证技术中立和减少第三方依赖。

图形化编程还需要学代码？

几种常见的观点：

“现在低代码平台那些，还不是要学代码？学完代码再学低代码，成本太高了...”

“而且还不是简单学学那种，因为图形化里面需要代码的地方往往都是图形表达不了的，都比较复杂的...这个要怎么搞？”

“先学代码，在学图形化编程...就没有那么有意义了”