l

2012年7月26日 星期四

Scrum框架下的跨界開發(8):寫到這邊突然想到Pattern Languages

July 25 22:33~July 26 00:21

螢幕快照 2012-07-25 下午10.50.21

 

先說明一下,本集內容有點玄,看不懂為正常現象(迷之音:文「玄」慎入,請勿越級打怪XD)。

話說跨界開發這件事寫到第八集,Teddy突然想到Christopher Alexander的pattern languages理論。先解釋一下上面這張圖,和昨天畫的那張圖很像,只是有些地方稍微修改一下。先解釋一下幾個名詞:

  • World:真實世界,也就是問題發生的地方。有問題,就代表有需求,所以才會有人說「需要為發明之母」。例如,鄉民們要開發甚麼ERP系統、汽車控制系統、體重控制軟體、雲端殺豬系統。這些系統都是因為要解決真實世界的某些問題而產生的,也就是說這些系統的「需求」發生在真實世界。
  • Machine:開發軟體以解決某個發生在真實世界的問題,就相當於製造一台「機器」。所以,這個Machine就是所謂的Solution。事實上,Teddy可以大膽說,鄉民們在學校或是工作中所受的訓練,絕大多數都屬於Solution的範疇,只有一小部分與Problem有關。例如,OOAD,A的部分(分析)是屬於Problem,其餘D的部分(設計),以及後來的實作、測試、寫手冊等等,都屬於Solution的範圍。再舉敏捷實務做法為例子,什麼持續整合、單元測試、pair programming、建構管理、shared code、測試驅動開發,這一些全部都是Solution。更別提程式語言、演算法、資料結構,當然也是Solution。
  • Application Domain:真實世界很大,而你所製作出來的機器很小…Orz。你的機器與真實世界相關的這個部分,就稱為Application Domain(應用領域)。例如,鄉民們可能有聽說過,某人是在負責銀行業、保險業、物流業、IC設計業等等。這些不同的「業別」,就可視為不同的Application Domain。看到這邊鄉民們可能會為:幹嘛分什麼Application Domain?很簡單,因為真實世界太大,而鄉民們(工程師)又太渺小,不可能做出一個可以解決全世界問題的機器出來。所以才要把世界切成不同的Application Domain,這樣問題變得比較小,而鄉民們才有辦法可以把機器給造出來。

World與Machine之間的箭頭,Machine的建造需要從World獲得需求。而隨著Machine的建造,應用到World中,則可以讓鄉民們更清楚的了解需求。

由上圖可以看的出來,很明顯的World和Machine各是一個孤島,要把World所發生的問題,轉成一個Machine,這中間的過程有一個很大的鴻溝,因此需要一座橋樑,讓這兩個孤島上的人,可以互相往來。這是從World到Machine的「跨界」。World的內部和Machine的內部也存在著跨界的問題,關於Machine內部的跨界問題Teddy在《Scrum框架下的跨界開發(2)》曾經提過,這邊就不在重複。

現在的問題是,「誰」,或者是「什麼東東」,可以扮演這個Bridge的角色?想到這個問題,Teddy的腦海中浮出兩個答案:

  • 流程:不管是傳統的結構化分析與設計、後來的物件導向分析與設計、RUP、敏捷方法(例如Scrum),都是在告訴鄉民們,如何從A—>D的過程。也就是從分析(What to do。要做什麼東東,也就是把問題搞清楚)到設計(How to do。問題清楚了,那接下來要怎麼做,解決方案是什麼。)所以,流程本身是一個很好的Bridge。
  • :10幾年前Teddy剛開始接專案的時候,從需求分析、系統設計、實作、測試、寫手冊、到客戶端裝機,全部都是一個人包辦。所以,人也是一種很好的Bridge。

***

寫到這邊和pattern languages有何關係?Teddy想到當初Alexander發明pattern languages的出發點,其實跟上面這「流程」和「人」有很密切的關係。話說Alexander觀察到,在農業社會,絕大多數的人所居住的房子,其實都是自己蓋的。古時候沒有什麼「建設公司」幫忙蓋集合住宅,也沒有政府提供合宜住宅。再加上大部分的人口都是務農,也沒多餘的錢請人家蓋房子。所以,要房子嗎?好,爸爸蓋給你XD。

但是,現代工業社會因為強調所謂的「效率」,因此產生了「專業分工」以便於大量生產。所以,建商出現了,仲介出現了,原本人類具有的蓋房子能力,也因為專業分工的緣故而消失殆盡。

在此Teddy先插花一下,專業分工的這個觀念很重要,因為,傳統上大家都認為專業分工是很好的。但是請注意到Scrum的cross-functional team,以及XP的pair programming與shared code,其實多多少少存在著打破專業分工的精神。

簡而言之,Alexander希望人們可以重拾以往「具備自己蓋房子」的能力,而他所提出的方法就是pattern languages。鄉民們還記得pattern的最簡單的定義是什麼嗎?

A pattern is a proven solution to a recurring problem in a specific context.

一個模式是在特定領域中,針對一個重複發生的問題,已被證明有用的解決方案。

Pattern包含了problem和solution,所以一個pattern就是一個什麼?想到了沒?

每一個pattern就是一個小小的bridge,可以解決一個小問題。一堆相關的pattern,就形成一個pattern language,可以解決一個較大的問題。

***

Alexander在他的書中說過,pattern is a process and a thing。這個觀念Teddy在《Pattern是個雙面人(上)》和《Pattern是個雙面人(下)》有解釋過。Teddy認為Alexander當初要解決的問題,基本上就是一個「跨界」的問題:讓沒有具備建築能力的廣大鄉民們,能夠在學習pattern之後,具備這樣的能力。這不是跨界是什麼?不只跨界,還跨很大哩。

鄉民甲:我以前是水電工,去了鋸匠之後,我現在是建築師XD。

Teddy:這也是一種跨界喔。

***

寫到這邊Teddy自己也不知道在寫些什麼…Orz。最後一個重點,為什麼繼Scrum課程之後,Teddy要在8/25開「Design Patterns這樣學就會了:入門實作班」這門課?Design Patterns不是寫寫程式,或是買本書看一下就懂了嗎?10幾年前Teddy剛學Design Patterns的時候,Teddy只是把Design Pattern看成是一種高深的物件導向設計招式。但是讀了Alexander的書之後,慢慢覺得pattern與pattern language方法其實是一種很好的分析問題工具,可以幫助工程師們把困難的問題經過pattern的訓練,深刻了解問題的本質。

但是,為什麼要深刻了解問題的本質?每天跟派大星一樣爽爽地過日子不是很好?!答案很簡單,因為要成為一個更好的工程師。聽起來很無聊,但是Teddy認為,這是一個很重要的能力。曾經有人問Kent Back,XP的做法是否會排斥能力很強,但是可能不喜歡跟其他人合作的人。Kent Beck說:什麼叫做很強的人?從他的角度來看,能夠讓你的同事把原本認為很難的問題,經過你的協助之後,馬上開竅,具備解決問題的能力。這種人才是Kent Beck所認為的很強的人,而非自己很強但卻不管別人死活的那一種人

Teddy認為Alexander的pattern language方法可以協助工程師們變成Kent Beck所說的那種很強的人。但是,此方法有點抽象,直接學習可能會死人XD。其實是怕說開這樣的課應該沒人來上。所以Teddy只好循序漸進,先從比較實用的Design Pattern開始教起,在課程中慢慢灌輸一些Alexander最原始提出pattern的想法。

難道課名叫做「Design Patterns這樣學就會了」是一種幌子,實際上是要在課堂上傳授邪教?

想太多,來了就知道。

***

友藏內心獨白:怎麼本篇又被置入性行銷啦XD。

沒有留言:

張貼留言