尋找第一個Pattern

May 07 14:11~15:07

很久以前有一次Teddy在某場合介紹Alexander的pattern languages，談到這個方法是一種「由上而下」的設計過程，透過一次套用一個pattern（one pattern at a time）的方式逐次展開，採用pattern為基礎的方式解決一個大問題。就好像人類使用「語言」解決問題一樣，Alexander把這種方法稱為pattern language。

聽完演講之後有一個聽眾問我：「要如何選擇最上層的第一個pattern？」當下Teddy心裡覺得:「啊不就是你書讀得少，pattern認識沒幾個，所以才不知道要如何選擇第一個pattern。」

事實上Teddy的想法並不完全正確，對方也許真的不熟pattern，但這個問題首要的重點不在於對方懂多少個pattern，而是「最上層的第一個pattern，就是你要解決的那個大問題，也就是你想要達到的目標 （goal）」。

***

設計模式的例子

 

▲Mediator範例

上周末在上【Design Patterns這樣學就會了：進階實作班】，討論到Mediator模式的時候有學員問…

學員：如果Mediator的coordinating logic太複雜，我是不是可以把 Mediator + Strategy或是Mediator + Command混和一起使用？

Teddy：你先不要把問題複雜化，想著把A模式加B模式結合起來的可能性。「理論上」很多模式可以被「一起使用」，但如果只從解決方案來看設計模式，你會有太多排列組合都可以達到「相同功能」。這樣子學習者會無所適從，不知道怎麼套用pattern解決設計問題才合適，很容易變成為了套pattern而套pattern，變成過度設計（over design）。

Teddy：你要先問自己「目前你首要想解決的設計問題是什麼？」以Mediator的例子來看，因為你想拿掉Colleague與Colleague之間多對多的相依性，所以找一個中間人來負責協調與溝通。此時此刻，根本還沒有「Mediator的coordinating logic太複雜」的問題，所以不需要討論Mediator + Strategy或是Mediator + Command的可能性。

Teddy：當你套了第一個Mediator pattern，過了一段時間後，你發現coordinating logic太複雜。這個複雜性已經強大到讓你修改coordinating logic變得很困難，你的軟體慢慢變成了硬體。此時，你再來考慮要採取什麼方式來對付這個force。

一次一個pattern，第一個pattern解決你目前首要凸顯出來的問題。套完第一個pattern之後，如果沒有其他未被處理問題，那就沒事了。如果還有（例如Mediator的coordinating logic變得太複雜），你再進一步思考要如何解決。

***

道理很簡單但你不一定能活用

幾年前有一次到客戶端幫忙看Scrum團隊運作情況，客戶覺得他們跑的卡卡的，劈哩啪啦跟Teddy描述一大堆「可疑現象」。經過Teddy實地觀察之後，發現問題的確並不單純。

要從何開始著手？如果用pattern解題的方式來思考，要先套用哪一個pattern？

Teddy發現客戶的Scrum團隊最大的問題就是他們並不是真正的跨職能團隊（cross-functional team），團隊成員主要都是程式設計師，沒有測試專長的人，也沒有UI/UX的人。上游（UI/UX）的步調搭不上下游開發團隊的步調。經常發生UI/UX自己覺得效率很好，但他們完成的工作，開發團隊可能好幾個sprint之後才會用到，甚至也有完全沒用到的時候，最後直接丟到「垃圾桶」。

伴隨著這個根本原因，團隊產生了很多病症，必且試圖用各種有創意的方式來延緩這些病症，但都無法長期維持下去。

其實這個問題很簡單，先讓自己笨一點，既然是跑Scrum，為什麼不直接聽Scrum的話，組織一個真正的cross-functional team，先傻傻套用這個pattern「試看看」。套用之後，跑一陣子，如果有其他的問題浮現，再思考要如何解決。例如，之後可能發現需求管理很困難，團隊對於產品願景與sprint目標不明確，此時再討論嘗試套用impact mapping與user story mapping的可能性，才顯得有其意義。

***

友藏內心獨白：這麼簡單的道理居然這麼久才想通啊。