解读极限编程的十二大原则——隐喻

 

隐喻：普通语言和术语的集合，用来预见项目中的功能。

《敏捷软件开发：原则、模式与实践》一书中对隐喻的解读如下：

隐喻（metaphore）是所有XP实践中最难理解的一个。极限编程者在本质上都是务实主义者，隐喻这个缺乏具体定义的概念使我们觉得很不舒服。的确，一些XP的支持者经常讨论把隐喻从XP的实践中去除。然而，在某种意义上，隐喻却是XP所有实践中最重要的实践之一。

想像一下智力拼图玩具。你怎样知道如何把各个小块拼在一起？显然，每一块都与其他块相邻，并且它的形状必须与相邻的块完美地吻合。如果你无法看到但是具有很好的触觉，那么通过锲而不舍地筛选每个小块，不断地尝试它们的位置，也能够拼出整个图形。

但是，相对于各个小块的形状而言，还有一种更为强大的力量把这些复杂的小块拼装在一起。这就是整张拼图的图案。图案是真正的向导。它的力量是如此之大，以致于如果图案中相邻的两块不具有互相吻合的形状，你就能断定拼图玩具的制作者把玩具做错了。

    这就是隐喻，它是将整个系统联系在一起的全局视图；它是系统的未来景像，是它使得所有单独模块的位置和外观（shape）变得明显直观。如果模块的外观与整个系统的隐喻不符，那么你就知道该模块是错误的。

隐喻通常可以归结为一个名字系统。这些名字提供了一个系统组成元素的词汇表，并且有助于定义它们之间关系。

例如，我曾经开发过一个以每秒60个字符的速度将文本输出到屏幕的系统。以这样的速度，字符充满整个屏幕需要一段时间。所以我们让产生文本的程序把产生的文本放到一个缓冲区中。当缓冲区满了的时候，我们把该程序交换到磁盘上。当缓冲区快要变空时，我们把该程序交换回来并让它继续运行。

    我们用装卸卡车拖运垃圾来比喻整个系统。缓冲区是小卡车，屏幕是垃圾场，程序是垃圾制造者。所有的名字相互吻合，这有助于我们从整体上去考虑系统。

    另举一例，我曾经开发过一个分析网络流量的系统。每30分钟，系统会轮询许多的网络适配器，并从中获取监控数据。每个网络适配器为我们提供一小块由几个单独变量组成的数据，我们称这些数据块为“面包切片”。这些面包切片是待分析的原始数据。分析程序“烤制”这些切片，因而被称为“烤面包机”。我们把数据块中的单个变量称为“面包屑”。总之，它是一个有用并且有趣的隐喻。

       理解隐喻的确是个困难的事情，主要是这个说法太文了，其实我们在平时的开发中是一定会有做到的，只是我们没有将其重视起来。比如，在做一个Java项目时，我们可以在研发规范中要求对于每个对象要有一个属性类，对于这个对象的业务有一个业务类，对于这个对象的处理接口会有一个接口类，加入这个对象的数据库表名为TEST的话，那么它的属性类就是test，业务类是test_business，接口类就是test_instance。于是整个系统有多少数据表，基本上就会有多少套类，从目录结构上很容易看出来实现的进度和类之间的关系。这样的规范在大家接受之后，所有人都会按照这样的思路去做，假如在对代码进行重构的时候发现需要重新生成一个接口类，那么也会按照类似test_instance_xxxx这样的方式给类起名，这样别人看到这个类的时候就不会糊涂了。当然，我们这么做的时候仅仅考虑的是为了方便，从来没有想到这叫什么隐喻。大师之所以称之为大师，就在于他们能够将实践变成理论体系。