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等。各位开发人员，您对可视化编程是持什么样的观点呢？
温馨提示：内容为网友见解，仅供参考
无其他回答
相似回答
