Google Search

自訂搜尋

2009年1月24日 星期六

[IT Architecture] Starbucks 買咖啡 VS Design Pattern

昉間有不少文章和書針對在StarBucks買咖啡的過程比較起軟體開發的Design Pattern. Design Pattern對從事MIS的人員有點像烏托邦, 因為MIS的工作, 以老闆對時程的要求大概不會允許你從Design Pattern開始一步一步設計系統, 但是IT人員總有個夢希望在程式變成如蜘蛛網般難讀之前還是可以有一個機制去將需求概念化並用圖示的方式去呈現. 對Design Pattern在下懂得不多不過還是從幾篇文章針對這個主題整理出一些心得,希望對日後的系統分析有一些幫助, 下次去StarBucks喝咖啡除了聊天看小姐還多一些正經事可以做!

事情就從踏入Starbucks店門開始吧, 當你點完你的咖啡後, 拿到發票, 此時服務生會拿起咖啡杯並在上面做標示. 之後就將此咖啡杯放入等待序(Queue)中. 這個設計就是系統分析時所謂的分離(Decouple), 就是將處裡訂單的服務生和煮咖啡的服務生工作分開, 如此一來, 在客人變多時, 處裡訂單的服務生還是可以專心處裡訂單. 另外, 如果等待序(Queue)的單子太多, 也可以透過增加煮咖啡的服務生來加快處理速度. 這也是常見的非同步處理(asynchronous processing).

但非同步處理並不是沒有缺點, 最明顯的就是咖啡完成的順序未必和訂單順序相同. 例如當煮咖啡的服務生為加快速度可能將不同訂單中同樣的咖啡一起處理或者有些煮咖啡機器煮的時間較長, 服務生要特別考慮. 但問題是同一張訂單的咖啡還是要一起給人客啊, 這時Starbucks用的方式是用人客的姓來區隔. "來賓王先生你的咖啡好了", 這時, 王先生的訂單不管幾杯都會一起交給王先生.

問題又來了, 客人臨時換單或機器出問題, Starbucks如何處理呢? 一個最簡單的方式就是認賠殺出, 人客說她點的是熱的但做出來的是冷的, 很多時候服務生會再做一杯熱的給客人, 做錯的就倒掉. 還有一個方式就是重試, 客人說糖不夠就再加一點, 當然前提是這是一個可以重複的動作. 最後一個就是全部回到原點,一個情形就是訂單在還沒煮以前就取消, 這時當然就是退錢給客戶將交易退回(Rollback).

如果Starbucks是用傳統的方式, 點一杯做一杯付一杯的錢, 我們應該會看到Starbucks櫃檯前永遠大排長龍, 因為一段時間內可以服務的客戶數目會降低. 當然傳統的方式, 訂單出錯的方式降低很多, 客戶臨時換單或機器出狀況都比較容易處理.

生活中其實充滿一些同步也有一堆非同步的動作, 有時停下腳步好好觀察一下也許會有一些不同的收穫喔!

參考文件:

http://eaipatterns.com/docs/IEEE_Software_Design_2PC.pdf

http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html

http://www.springerlink.com/content/r72253p030411878/


沒有留言: