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

July 25 22:33~July 26 00: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。