软件技术可视化编程不是捷径,效率也不高

米花 发表 于:8年前 浏览量:156

Frederick Brooks在《人月神话》中有这样一段描述:“在软件工程博士论文中,一个很受欢迎的主题是图形化和可视化编程,计算机图形在软件设计上的应用。这种方 法的推测部分来自VLSI芯片设计的类比,计算机图形化在设计中扮演了高生产力的角色。部分源于——人们将流程图作为一种理想的设计介质,并为绘制它们提 供了很多功能强大的实用程序——这证实了图形化的可行性。不过,上述方法中至今还没有出现任何令人信服和激动的进步。我确信将来也不会出现。”

不久前,我和一个久未见面的朋友共进午餐。他最近参加了游戏行业的一个会议,在会议上他看到了一个用于统一引擎的可视化编程工具。(我不能100%确定,但是我猜测它可能是PlayMarker)

同样的效果,使用可视化编程工具操作,你只需在工作区里面简单地拖动几个控件,并且在它们之间 做一些选项和绘画箭头即可。而在非可视化编程工具里,你得思考如何输入各种命令,与可视化编程工具比起来,真是让人煞费苦心。我朋友看到的那个工具使用起 来非常像用于编程的图解工具:FPGAs。

表面上,这种编程方式非常了不起并且演示起来会让人印象深刻。你无需记住语法和方法名称,你只需简单地浏览一个列表,从中找到你想要的即可。但是,我对这样的东西并不信任。

正如Frederick Brooks在其书中提到的,流程图是一个非常抽象的软件结构表达方法,它们可以很好地处理那些简单的、琐碎的程序,比如像我朋友看到的那个演示。换句话说就好比像电子表格那样的工具操作起来确实很简单。

可视化编程让我想到这次设计和构建的4-bit电脑,我们在开始前绘画了原理图,看起来条理非常清晰,在执行过程中,伴随着数字功能盒与彼此间关联 连接数量的增加,整个结点数量竟达到了非常恐怖的地步。当初一个简单的原理图,执行起来竟会发展到如此地步。即使它的创造者可以理解,但任由它发展下去, 结果也是无法想象甚至是让人憎恶的。开发人员是否会有这样的感觉,代码在被搁置一段时间后,你很难能继续回到代码中去。就如上面提到的,仅是一张简单原理 图而已!

事实上,以长远目光来看,相比人们在其他领域的发现,文本工作效果会更好。这就是为什么VHDL Verilog会比我之前提到的基于路径流程图会更受欢迎的原因。图形化的东西往往都比较抽象,在软件处理上,往往会因处理过快而导致一片混乱。模块化操作可以解决一些问题,但执行时很难做正确并且在做错后会很难清理。

但是,可视化编程真的就一无是处吗?话说任何东西都有两面性,可视化编程确实也存在好的一面。

可视化编程是让程序设计人员利用软件本身所提供的各种控件,像搭积木式地构造应用程序的各种界面。正如我前面提到的,无需编写太多的代码甚至不需要 懂太多的语法知识和API就可以实现一些功能,尤其是针对那些不会编程或者对编程感兴趣的人,这是非常棒的操作体验!它也可以有很好的模块,并且工作的很 好!PlayMaker用户创建的游戏/应用程序工作起来会很棒,据我了解,PlayMaker还支持混合模式,可以一边编写代码一边显示可视化界面。或 许这是代码/可视化领域里最两全其美的工具!

下面分享原文的一些精彩评论:

在20世纪70年代,有句老话:“可视化编程就像是爬树登陆月球一样,初期取得了非常大的进步,但不久后,你不得不重新回去寻找更大的树。”意思大概就是想说,可视化编程永远不会取得太大或者让人信服的进步吧!

图形化编程在某些领域也有大展身手的地方:

  • 虚拟仪器(即LabVIEW)
  • 流程自动化(即自动化工具)
  • 快速原型和实物模型

然而,这些只是做些文本方面的工作,它早已从开发中抽离出来!

我之前还未想到UML,但既然提到,我不得不表达一下我的观点。在开头也同样引用Brooks的话:“如今的流程图已经变得复杂,一张图有若干页, 有很多链接结点。这种表现形式令人同情。流程图已经成为完全不必要的设计工具——程序员应该在开发之后绘制,而不是之前绘制描述程序流程图”。要知道,这 句话是写在1975年,在UML概念之前。Brooks在写书的时候可能还未想到过UML(目前许多公司在采用)。

用于可视化编程的语言有很多,比如C#,大家常用的可视化编程工具莫过于微软的Visual Basic、Visual C++、VS等。各位开发人员,您对可视化编程是持什么样的观点呢?不妨分享一下吧!

本文由 米花发表。转载请注明出处:https://www.mihua.net/list/0/3192.html

发表评论

您的昵称:

猜你喜欢

最近更新