剖析短迭代
敏捷教练Dave Nicolette提出：我们应该如何设定迭代长度？是要根据发布周期的时间么？使用短迭代又有哪些好处？
新闻
一图胜千言?
作者 Niclas Nilsson译者 郭晓刚 发布于 2007年11月10日 下午3时51分
一图总是胜过千言？
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会对你说，代码和图形都只不过是同一个模型的不同投射罢了。
查看英文原文：Is a picture always worth a thousand words?相关厂商内容
工具的UI可以做得更高效，但绝对没法超过打字的速度。
发表人
Junyin Wu
发表于
2007年11月11日 上午1时49分
虽然一图胜千言，但是引入高的细节沟通成本。
发表人
gem fox
发表于
2007年11月12日 下午11时21分
.gif)
2 条回复
回复