Metaphor

Oct. 12 17:29~18:18

 

XP有一個實務作法（practice）叫做Metaphor（比喻、隱喻），原本是用來讓專案有關人員，包含開發者與利害關係人，可以透過比喻的方式，用一種大家都認可的方式來溝通正在開發的系統。例如，用「購物車」這個比喻，來代表線上購物系統。

Metaphor除了可以促進專業與非專業人員之間的溝通，還可以（部分）解決敏捷開發對於軟體架構設計的問題。如果有辦法幫系統找出一個好的比喻，開發人員可以很容易了解系統架構，以及系統內部重要概念、模組的意義，這對於開發與維護而言，都是很有力的溝通工具。

舉個例子，Teddy以前開發過一個伺服器管理系統，負責收集與監控很多台電腦的狀況，然後顯示給系統管理者觀看這些狀況。針對異常情況，主動發出警告訊息。在開發這個系統的初期，Teddy覺得這是一個由很多外掛（plug-ins）所組成的系統，因此套用了Plug-in這個架構模式（architecture pattern）。隨著系統逐步開發，過了好一陣子才慢慢發現，這樣一個系統本質上就和作業系統的排程器（scheduler）沒什麼分別，負責監控遠端電腦的軟體模組，就是scheduler，每一個監控的工作就是一個排程的job。

有了這個Metaphor之後，等於找到一個開發人員都可以理解的conceptual model（概念模型），後續的設計工作也變的簡單許多。例如，每一個排程的job都有check interval這個屬性，用來控制多久被scheduler檢查一次。用了Scheduler這個metaphor，解釋check interval就變得非常簡單與自然。

***

但是，要找到好的Metaphor不是很容易，如果使用不當，形成「不正當的類比」，不但無助於溝通，反而造成誤解。這可能也是Metaphor這個實務作法不像XP其它實務作法那麼被廣為使用的原因。

Metaphor就好像一座橋梁，讓身處A地的人，可以透過它到達原本一無所知的B地，建立起AB之間的關聯性。就算不用在軟體開發上，對於教學、解釋觀念，也是十分有效的方法。Teddy自己多次在教學中使用這個技巧，發現效果極佳。例如，用「跟團」與「自由行」來類比「predictive process control」與「empirical process control」，用看廣告或短片的方式來解釋某種專業概念，例如「價值驅動」或是「pattern的六大元素」，都驗證了它的藥效。

努力找到一個好比喻，你會發現聽完你的解釋之後，大家都變聰明了 XD。

***

友藏內心獨白：問題是要怎麼找啊。