上周日和橱柜公司商量好,下午三点到我的房子量尺,橱柜设计师按时到达,拿着一卷尺开始了测量工作。有过装修经历的人都知道:在装修公司进场之前需要橱柜设计师出一份水电改造图,便于装修公司人员确定水电改造的具体方法。装修公司的施工人员与橱柜设计师之间仅需要一份设计图纸就可以完成水电路改造的沟通,这不由得让我想起这样一个问题:"软件开发领域的"图纸"在哪里呢"?

"图纸"是建筑行业的标准的共同语言,它能让设计师与施工者无缝沟通,同时由于建筑图纸的形象性,普通人看了基本也能了解一二,这样普通用户和设计师沟通起来也是很容易的,即使是一个外国设计师设计的图纸,只要使用了标准的图纸符号,中国的施工者也可以完美的将之实现出来,反之中国设计师的作品,外国施工人员也亦然可以实现之。软件行业的人总喜欢拿软件开发与建筑行业做比较,设计模式就是其中最典型的例子。不过这么多年来,软件开发过程仍然无法达到建筑业的那么"精确",这里的精确不是指过程和进度的精确,而是沟通的"精确"。

软件开发领域的"报怨声"已经持续了几十年了,需求分析人员无法获取用户的准确需求、系统设计人员无法将自己的全部设计思想很好的传达给编程实现人员,人们都在抱怨:缺少一种"共同语言",能让他们之间"无缝的沟通"。软件业的大师们绞尽脑汁、费尽心思、提出了多种沟通语言,以试图解决这个问题。这里面最著名的莫过于由OMG组织于20世纪末推出的"统一建模语言(UML)"了,顾名思义,UML试图统一软件开发领域所有过程阶段的"沟通标准",需求阶段有Use Case图;设计阶段有组件图、类图;部署阶段有部署图,另外还有序列图、状态图、活动图作为辅助。UML到目前为止也从1.0发展到了2.0版本,但其实际应用情况如何呢?乐观点说是:没有"图纸"在建筑领域应用的那么广;如果从我了解的和接触的实际情况来看,UML已经过了其高峰期,开始变得"不瘟不火"。

程序员多数喜欢简单化、个性化和形象化的表达思想,一块白板,无拘无束。虽然UML在形象化上做的还不错,但是却始终无法打动程序员的心扉。从另一个事实来讲,图纸是建筑行业的门槛或者说是基础,而与之对应,代码才是软件行业的门槛。这样一来似乎代码才应该是一种共同的语言,在"敏捷软件开发"的附录中就有这样一篇文章:"源代码即设计"。那是否说:"代码"就是"软件业的图纸"呢?"代码"在设计开发人员之间可以说是基本无缝的,但是对于普通客户而言,代码似乎太专业了。其实在建筑行业"图纸"也多在设计师和设计师、设计师与施工人员之间做沟通之用,大项目中少有客户与设计师沟通时使用"图纸",多数会用外观效果图。这样一来似乎软件开发领域的"代码"与建筑业"图纸"的概念达到了一定的一致性。"代码"作为沟通媒介的前提是:代码和设计的统一。为了达到这一目的,需要代码结构清晰,可读性,可沟通性要好,这也势必需要实现人员提高编码技艺。都说编程是一门艺术,从这里来看,名符其实。如果承认"代码"这一地位,那么实际上是确定了一个方向,以后向这个方向努力就是了,众所周知的"敏捷"在这个方向上做出了努力。

上面也已经说过,"代码"过于专业,并不能作为"统一沟通媒介"来统一整个软件开发过程,看来我们只能继续期待头脑中理想的"图纸"的出现了,也许它会诞生于将来的一个突破性的"发明"或"发现“;也可能它将是一个永远的"梦"。

© 2008, bigwhite. 版权所有.

Related posts:

  1. tony说设计-实践后的体会
  2. 软件抽象
  3. '此起彼伏'的复杂性
  4. 三角形输出问题考量
  5. 查表法求解'自然数对'问题