也谈西直门桥的设计

下面就是著名的西直门桥的右转指示图：

 

这个桥在从两个方向上过来的右转都必须经过三圈或者五圈。任何新司机都惧怕这里，任何老司机都激动这里。

就因为此，还有人编写了一段笑话：

 

中国联通壮告西直门立交桥设计者

一日,中国联通董事长王建宙坐在车后座上无线上网,车在北京的街头和汽车洪流中走
走停停.王总突然感觉累了,于是合上电脑,放眼望向窗外.

“这是什么桥，这么大？”王总突然问。
“是西直门立交桥，王总”司机回答到。司机知道，王总平时太忙，在车上都在办
公，其实经常路过这桥，但是王总一直没有注意到。
“哦。”王总叹到。他想，现在中国的通信和交通发展真快啊，有这么宏伟的桥。
王总打开电脑，继续办公。

良久，王总再次望向窗外，“这座桥和刚才那座很像嘛！”王总感叹道。
“这就是西直门大桥，王总”司机说。
“我怎么觉得刚才开了很久，绕了很多弯路，还是西直门大桥？”王总疑惑不解。
“是的，王总，这桥就是这样，我们刚才只绕了一个半圈，一共要绕三圈，还有...”
“这简直是胡扯！有这样设计桥的吗？”王总不满地说。他看着这一个又一个的圈，猛
地想起了什么，于是打开电脑，在网上搜索到了西直门大桥的俯视图。
“这不就是中国联通的标志么？！”王总愤怒了,拨通了律师的电话:“把设计者找出
来，我要起诉他！”...

第二天，王总接到一个电话：
“王总您好，我是西直门大桥的设计者聂大华，我是来给您道歉的，我在设计桥的时候
是参考了中国联通的标志，是侵权了，而且开车过桥的时候转的圈也多了点儿...”原
来是他的电话。
“不过王总您千万不要生气，我已经和有关部门联系好了，决定过段时间就把桥炸
了，重新造，这回，我们将采用中国移动的标志！！...”

当然了，这些只是笑谈。不过也证明了这个桥的知名度。不过，我今天只是想聊聊它的设计！

下面是网上关于原设计者的一段描述：“记者通过查找资料得知西直门立交桥的设计者叫聂大华。她当时设计此桥的主要依据是通过定向匝道解决主车道车流问题。根据模型测试分析车流的主流向、主流量。据说当时这种方式被认为是最科学的一种立交的方式，避免了以往老桥各方向车流交叉的矛盾，使得西二环的通行能力从原来的每小时通行９０００辆增加到了１２０００辆。“由于建桥受到土地面积的限制，其他被认为是次要的方向就必须盘桥。”可事实却是：主车流车速没快起来，而次要车流则更堵了。”

我相信，在我们开始否认这个设计之前，必须清楚地了解到设计者的思路。不了解而开骂，那是为了泄气。就算骂也要骂在点上才行。而且，我写这些，只是从设计角度看看这座桥。

一、             目的良好。增加二环的通行量，这个就是在现在交通拥挤的北京，也是非常正确的。舍弃一些“可以舍弃”的道路，保证主要路段的运行效率。从本质上没有问题。

二、             建模设计。使用模型来进行测试，保证达到预期效果。建模这种手段在我们做软件设计的方法中也非常重要。比如说系统的效率问题，必须先建模进行测试，看看是否可以承受最大压力。

这些都没问题，那么，问题出在哪里了呢？

一、             忽视用户使用习惯。右转弯的惯例显然没有遵守。就这一点上，是最致命的设计失误。事实上，其他方面都是可以被用户原谅的。一个架构师必须充分考虑用户的使用习惯，才有可能赢得用户的满意。就算通行效率没有提高太多，用户也不至于到骂人的程度。

二、             架构师的基本功不扎实。很多人喜欢谈原则，但是到具体执行设计的时候，基本功往往决定了细节，而细节决定成败。

三、             没有多个方案比较。很多问题的产生，都是因为只有一种方案的。试问，次要路线的盘桥方式只有一种嘛？

四、             桥的设计不必软件的设计。后期变更的机会不大。因此对效率的预测，必须做到足够充分，显然这位架构师的模型还是有问题，应该进行多方面校验。

五、             业务专家不够。架构师自己应该充分体验一下设计。将自己想象成用户去进行体验设计，能发现很多问题。显然这位架构师不像是个司机。唉，那就应该找一个道路专家，或者汽车专家进行辅助设计。

话说回来了，这些都是事后诸葛亮。真正设计的时候，很难顾及到所有。越是重要的设计，就越应该多方面验证。我相信，会避免很多问题。