一图总是胜过千言？
Dean Wampler 在新文章《为什么我们要写代码而不只是画图就好》中主张，在软件行业里，前面那句话通常要反过来说才对。
图形表示法的拥护者们已经期盼了很久，希望能达到只需要画图不必写文本代码的境界。多年来，已经有一些图形编程环境来了，又走了。 要是一图真的胜过千言，那为什么它还没有实现呢？
曾被广泛应用的图形编程环境并不多见，但也有独树一帜的。 LabVIEW 可能是其中最著名的一个，不过它主要是被测试者所使用（以及拥有神奇的Lego 玩具的小孩）——而非一般的开发者。
为什么会这样？很可能是因为在软件开发中要照顾太多的细节。因此很难创造出一种图形语言能表达出这种复杂性，而又不致让阅读的人负担过重。如果用图形来表示编程结构，我们需要把图形映射到一种（常常是）抽象的概念方能理解其含义。难的是不要落入一个经典的陷阱。而因为我们需要与其他开发者交流，我们又的确需要能适用于种种情况的充分的词汇。
Dean 写道：
那我们不能用一种表述力充足的图形表示法吗？当然可以，只不过我们会遇到实用的问题——用文字来书写细节总比画出来要快。 几年前我为某著名公司开发面向 Java 开发者的以 UML 为基础的工具时，就遇到了这个现实问题。工具的 UI 可以做得更高效，但绝对没法超过打字的速度。
不过，这取决于你在代码中建立的抽象有多强。如果做得不好，你可能需要一千个词才能表示出一张图就能说明白的内容。而且你及你的同事每次阅读代码的时候都需要“解码”。
目前的领域特定语言运动就明确地专注在这一点：
有些语言相当繁冗也是事实。这是领域特定语言（DSL）将会扮演更重要角色的一个方面。一个设计良好的 DSL 能让你简洁地表述那些高抽象层次的概念。
Dean 所说的是文字的 DSL，但 Metacase 等公司正在设计图形建模语言，而Microsoft 也采取了类似的路径去开发创建图形DSL 的工具，来完成他们对软件工厂（Software Factory）的设计图景。
Arnon Rotem-Gal-Oz 如此描述图形 DSL 的局限：
跟以减少代码为出发点的 DSL 不同，以建模为出发点的软件工厂、MDA 等把目标定得太高，因而提供的价值太少，或者在代码生成的隔阂上受累太多（生成的代码太过一般化，距离方案的实际需要太远）。
Arnon 也明确地评价了一图是否真的胜过千言：
如果你把模型看作是纲领性的框架，那么你可以按自己的意愿提高抽象的层次，进而比较明晰地表达你的观点，那么这句话成立。然而，当你需要把模型建得非常具体，从而得以进行代码生成——在这种情况下，用代码来建模，再搭配自动生成或预先建立的 DSL 和框架，会更加合宜。
讽刺的是，运用图形是掌握一个复杂的代码基的一种好方式。InfoQ 最近发表了与 Erik Doernenburg 进行的一次关于软件视觉化的采访，在其中Erik 解释了从不同角度视觉化一个系统或者一个代码基的各种方式。运用视觉化方法，可以快速地聚焦到其他方法难以发现的反常之处。不过这与图形化地建造软件并不是一回事。
Dean 最后解释说他并不认为图形表示法没有存在的空间，但是：
就一般情况来说，用简洁的语言加上设计良好的 API 和 DSL 来编写的代码，对上图形驱动的方式仍然是必胜的。
可是另一方面， Intentional Software 会对你说，代码和图形都只不过是同一个模型的不同投射罢了。
活动推荐：
2023年9月3-5日，「QCon全球软件开发大会·北京站」 将在北京•富力万丽酒店举办。此次大会以「启航·AIGC软件工程变革」为主题，策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近30个精彩专题。咨询购票可联系票务经理 18514549229（微信同手机号）。
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论