Pattern是個雙面人（上）

May 30 23:18~May 31 00:20

 

如果有人問你：「什麼是pattern？」,你會怎麼回答。

 

鄉民甲：（跳、跳）選我，選我。

Teddy：請作答。

鄉民甲：A pattern is a proven solution to a recurring problem in a specific context。

Teddy：還有沒有其他的解釋嗎？

鄉民甲：糟糕，只背到這一句。ㄟ，沒有，等你教。

***

關於pattern，除了上面那一句常見的解釋，還有另外一句鄉民們可能比較少聽到，但卻也是很重要的觀念，那就是Alexander在《The Timeless Way of Building》書中提到的：A pattern is a process and a thing。

蝦米？Pattern是「流程」也是「東西」？此話何解？

一個pattern本身表達一件「東西」，這個東西，以建築領域來說，可能是一張代表該pattern意境的照片；如果是軟體的pattern，可能是高階的設計圖或是程式實作的邏輯描述。

如果鄉民們手邊剛好有《A Pattern Language》這本書（應該是沒有人會有…XD），翻開書中的每一個pattern，第一眼看到的就是一張代表該pattern的照片。看一下這本書第548頁代表Entrance Transition（入口的過度空間）這個pattern的圖，再接著看這個pattern的目的。

 

Buildings, and especially house, with a graceful transition between the street and the inside, are more tranquil than those which open directly off the street.

看完圖之後再讀這個pattern的意圖就比較容易理解。

很可惜GoF的Design Patterns並沒有像Alexander一樣在每個patter開始之前先給張圖瞧瞧。不過Design Patterns裡面的Structure某種程度也扮演著類似的角色。畢竟軟體設計的patterns有時候不是那麼容易可以用一張圖或是照片來表達它的意涵。但是，如果鄉民們patterns的書看得夠多的話，就會發現有些人所寫的patterns是會參考Alexander原本的風格，在開始用文字描述pattern之前先提供一張照片。例如，《Patterns For Fault Tolerant Software》這本書的patterns寫作方式就是採用Alexander在《A Pattern Language》書中的寫作方式。

總之，pattern的第一個面向就是：要能夠讓人讀了之後知道這個pattern所代表的「東西」是個什麼樣的玩藝兒（請捲舌）。

***

Pattern的第二個面向就是：它是一個流程。鄉民們心中可能會想：「拜託，pattern是一個東西我勉強還能夠接受，pattern是一個流程這又是那招？」流程，是waterfall還是RUP這種流程嗎？還是Scrum？

都不是，這裡說的流程是指「讀了pattern的解決方案之後，鄉民們應該有能力能夠把這個pattern給實做出來」。如果做不到，就表示這個pattern可能寫得不夠好（迷之音：當然也有可能是讀pattern的人太笨…Orz）。

總之，pattern的這兩個面向，是在學習撰寫pattern時很重要的觀念。以Teddy自己的經驗，要同時把「東西」跟「流程」都描述得很好其實並不容易（寫作本來就是一件很難的事情）。姑且先不管寫作pattern，畢竟大部分的鄉民都屬於「pattern使用者」，而非「pattern產生者」。請鄉民們思考一下，「A pattern is a process and a thing」這個事實對於「學習pattern」這件事有何幫助？

下集待續。

***

友藏內心獨白：難不成patterns是黑白郎君嗎？

六折出清

May 30 12:26~13:55

 

前幾天Teddy到天瓏書局買書，依照慣例一定都會走到賣patterns與agile原文書的那一櫃瞧一瞧。看到《Pattern-Oriented Software Architecture Volume 5: On Patterns and Pattern Language》這本書被貼上「六折」的貼紙已經有好一陣子了，依舊不動如山，內心不禁湧起一種淡淡哀傷之感。

Teddy當年還在唸書的時候，有好長一段時間都花在研究patterns和寫patterns上面。Teddy說的「研究patterns和寫patterns」不是指把GoF的23個design patterns拿出來研究跟寫程式實作，而是指「用patterns的方法來記錄或是描述特定領域的知識」。由於Teddy第一份工作是在做e-learning軟體開發，所以剛開始研究patterns寫作的時候，就以e-learning領域為標的，整理了應該有30-40幾個e-learning的patterns（最後實際寫出來的大概有10來個）。

這個e-language pattern languages研究做了應該快四年之後，在某種因緣際會之下，Teddy覺得e-learning這個領域實在是沒什麼搞頭（在台灣都被某批學教育出身和某校的大牌教授給把持了），決定還是回頭做跟軟體相關的研究算了。

不過還是那句老話，以上都不是重點。重點是，平常學習各種不同的patterns（不只是GoF那本書裡面的23個patterns）就已經覺得有點吃力了，但是鄉民們有沒有想過一個問題，如果要讓你自己寫出一個pattern（不是寫程式，而是用文字敘述的方式描述一個pattern），甚至是整理出一套pattern language，你知道要怎麼做嗎？

鄉民甲：你神經病啊，幹嘛自己寫pattern，浪費時間又不能賺錢。

鄉民乙：很簡單啊，pattern不是都有一定的格式，什麼pattern name、context、problem、forces、solution、resulting context，把這些內容掰一掰就搞定了啊。

***

Teddy剛開始準備自已動手寫patterns的當下，也跟「鄉民乙」的想法很像，不就是寫作文嘛，有什麼難的。等到自己真的動手之後，才發現還真的有夠難，至少比寫程式還要難N倍以上。如果只是要寫出「長得很像patterns的東西」，那的確是不難。但是這樣的作品是經不起考驗的，也不會有人想用（應該說也不能用）。當時Teddy也不知道該怎麼辦。於是指導教授就建議Teddy去讀Alexander的書，看看原本patterns與pattern languages起源的想法是什麼。在讀了《The Timeless Way of Building》、《A Pattern Language》、《The Oregon Experiment》與《Notes on the Synthesis of Form》（最後一本看不太懂…Orz）之後，雖然有更深入了解patterns領域的「地形地物」，但是說真的對於自己所寫出來的patterns還是沒有十分滿意。

2007年6月16日Teddy在天瓏買了《Pattern-Oriented Software Architecture Volume 5: On Patterns and Pattern Language》這本書，覺得這本書真是寫得太棒了。不像這一系列前四冊都在介紹不同的architecture patterns，這本書其實是在教大家「如何寫patterns與pattern languages」，好高興地球上終於有人寫了一本這個主題的書。但是，這種書在台灣是賣不出去的，因為沒什麼人對這麼冷門的主題有興趣。

***

鄉民們有看過「達摩祖師傳」這部電影嗎？Teddy自己是還滿喜歡的，看過好幾次重播。在電影中達摩祖師講過一句話：「看那看不見的東西，聽那聽不見的聲音，知那不知的事物，才是真理。」聽起來很有道哩，但是要怎麼「修行」到這樣的境界？每次專家學者們在檢討台灣經濟發展問題的時候，總說台灣應該要培養「關鍵技術」的能力，要有能力能夠自製「關鍵零組件」。那麼軟體哩，軟體的關鍵技術與關鍵零組件是什麼？

在讀了Alexander一系列的書之後，並沒有讓Teddy賺到更多的錢，在凡事講究投資報酬率或是C/P值得時代，研究這些東西底有何好處？

抽象的來說，就是培養「看那看不見的東西，聽那聽不見的聲音，知那不知的事物」的能力。舉個例子，在讀Alexander的書之前，Teddy覺得那一票做agile methods的人都好厲害啊。為什麼能夠「發明」有那麼多看起來違反常理，但是卻又那麼實用的做法。讀了Alexander的書之後，Teddy發現很多agile methods裡面的思想，其實跟Alexander對於建築的想法是很接近的。所以，雖然Teddy原本讀Alexander所寫的那幾本書的出發點是為了學patterns，但卻也得到一個很好的side effect（副作用），就是用另外一個角度把agile methods搞得更熟。這種體會，跟直接去讀agile methods書籍相比，還是有層次上的不同。

***

友藏內心獨白：最近出刊時間越來越晚啊…Orz。

完美是動詞

May 29 09:55~11:19

 

昨天下午約了人在台北車站附近談點事情，下午三點二十「會議」結束之後，Teddy想說既然來台北車站，就順便到天瓏逛一下好了。此時台北天空正下著大雨，Teddy撐著一把小雨傘快速地走到天瓏。不知是下雨的關係，還是時間的緣故，或是兩者相乘的效益，有點大又不會太大的天瓏書局，顧客人數加起來應該沒有超過五個。Teddy原本是計畫去購買前幾天提到的「設計模式之禪」這本書，想說這本書用了「禪」這個字想必有其獨到之處（真的嗎？）。一翻開目錄，哇哩勒，怎麼跟「大話設計模式」那麼像？內容都包含了Robert C. Martin在《Agile Software Development: Principles, Patterns, and Practices》這本書裡面Section 2所提到的那幾個設計原則（Single-Responsibility、Open-Closed Principle、Liskov Substitution Principle、Dependency-Inversion Principle、Interface-Segregation Principle）。Teddy還以為拿錯了書，不小心拿到「大話設計模式」。正面思考一下，這應該說「英雄所見略同」吧。把這幾個設計原則講解一下的確是有助於理解design patterns。

不過這不是重點，由於天瓏書局沒什麼人，Teddy就在裡面稍微逛一下（PS：老闆，冷氣可以開涼一點嗎？）。逛著、逛著看到一本叫做《講演之道：一個專業演講家的告白（Confessions of a Public Speaker）》的書，好像滿有趣的，就順便買一本帶回家（奇怪，書名那有「講演之道」這幾個字啊。怎麼現在任何書隨便都可以加上禪、道、藝術什麼的）。

這本書還滿有趣的，昨天晚上睡前不小心就看了三章，不過這也害了Teddy失眠了一整晚，搞到早上快五點天都亮了才睡著。要不是一早九點接了通電話，Teddy現在應該還在與周公開會。本書的作者提到他辭掉工作當一位專業的作家與演講著的心得報告。Teddy覺得本書大致可分為兩個主題：

• 幫讀者洗腦，告訴讀者演講這件事情其實並不可怕。
• 提供讀者如何做好演講的方法與技巧。

Teddy今天要講的是這本中譯本第四頁的一句話：

如果你希望變得擅長某件事情，那麼第一件必須扔出窗外的就是「完美」這個概念。

這句話說得太好了。前一陣子有一位朋友告訴Teddy，說他覺得自己做了許多事情，但是自己認為沒有把每一件事情都處裡的很好。之後他開始有點對自己失去了信心，面對新的挑戰時總覺得自己「還沒準備好」而不敢放手去做。Teddy非常能夠體會這樣的心情，因為Teddy也經常會有這樣的擔憂。「課程或演講的內容準備得夠不夠充分，萬一聽眾席中隱藏著什麼絕世高手，內容講錯被抓包或是被問倒了該怎麼辦？」

這種擔憂，往好的方面想，是激發講者多做準備的動力。但是，事情也可能會演變到黑暗的那一面。因為追求完美，所以討厭感冒。嗯嗯，想到感冒藥的電視廣告去了。因為想要追求完美，或是要等待那種「準備好」的感覺，所以在「還沒準備好」之前，遲遲不肯也不敢跨出第一步。看到這邊鄉民們就知道這又是一個先有雞還是先有蛋的無解難題。越不敢跨出第一步，就越不可能「準備好」，無解。

作者接著說：

因為太執著完美會讓你停止成長。你會停止冒險，也就是說你會停止學習。

所以哩？很簡單，套用敏捷方法逐步成長（incremental growth）與回饋的概念。準備（計畫）—>做—>修正。是這樣的過程讓人們往「完美」的目標邁進。所以，完美是一個動詞，不要把它當成名詞。

寫到這邊突然覺得，敏捷精神已經快滲透到各種不同的領域與行業之中。軟體開發就不用說了，Lean Startup和這本書裡面提到的幾個重要觀念，其實就是敏捷精神的應用。不過話說回來，這兩本書的作者以前好像也都是搞軟體的…Orz。好吧，至少搞軟體的人失業之後知道可以去做什麼工作了。就是，當作家…XD。

***

友藏內心獨白：在台灣當作家即應該會餓死。

重讀舊書有感：Debugging The Development Process

May 28 10:43~12:11

十幾年前Teddy剛剛脫離那種「單兵作業（一人開發軟體）」模式，開始學著如何帶領一個6-7人的小團隊一起開發軟體。如果是現在，Teddy當然知道可以讓團隊採用Scrum以及各種敏捷實務做法來開發軟體。很不幸的，當年開始做專案的時候完全沒有聽過這些東西。不過在那個年代Teddy的確也讀到幾本不錯的書，某種程度影響了Teddy對於軟體應該如何開發的「信仰」。

《Debugging The Development Process》就是其中的一本好書，Teddy手邊這一本是由當年紅極一時的「華彩軟體（已經倒閉）」所發行的中文版，中文書名叫做《微軟研發致勝策略》（感覺好像電影的命名方法，英文片名和中文片名完全連不起來…XD）。這本書的中文定價才240台幣，真的好便宜啊。Teddy記得當時華彩好像發行了2-3本類似的書，除了《微軟研發致勝策略》以外，Teddy手邊還找的到的有一本《微軟專案求生手冊》，英文書名是《Software Project Survival Guide》，這本留待以後有機會再談。

上個週末因為某個原因Teddy必須要把《微軟研發致勝策略》這本書拿出來翻看一番，此時赫然發現，其實書中很多觀念跟廣義的敏捷方法，或是Scrum與XP的精神都很雷同。其實這也沒什麼好大驚小怪的，古人早就有說：「英雄所見略同」不是嗎。本書的內容先不管他，直接看到封底的文字敘述，標題就是Teddy最喜歡的：

您了解如何讓研發專案如期完成，且不需要加班嗎？

根據封底的介紹，這本書要告訴讀者：

• 如何增進團隊工作效率，且讓每個人都樂在其中。
• 為什麼你會想把超級程式設計師趕走算了。
• 如何避免落入行政程序的天羅地網。
• 有那些小小的改變，可以換取極大的獲益。
• 不必加班就可以如期完成軟體的秘訣。（讀完這本書之後Teddy好像只記得這一點啊…XD）
• 如何讓所有的工作都價值加倍。
• 如何讓團隊保持鮮活的創造力。
• 如何提升程式設計師的整體技術水平。

奇怪，現在回頭一想，當年Teddy讀完這本書的時候，好像沒有學到那麼多耶…Orz。應該是當時功力還不夠，所以無法全部吸收。總之，上面這八個問題，相信時至今日還是很多軟體開發團隊想要追求的目標。如果鄉民們身為專案團隊領導者，有沒有想過，自己所帶領的團隊，上面這八個問題可以做到幾點呢？或者換個方式來問，如果鄉民們有在導入Scrum，那麼上面這八個問題，目前已經被解決了幾個？剩下沒有辦法解決的原因在那裡？這些尚未解決的問題就是未來可以改善的目標。

翻開這本書，挑幾個Teddy當初有畫重點的地方。第4頁：

領導者的任務是努力消除程式設計師工作上的一切障礙，讓程式設計師全力專注在真正重要的工作---改善產品。

還好現在有專職的Scrum Master可以做這件事。什麼，你們的Scrum Master都在寫程式！這樣不行啦，趕快來報名http://www.accupass.com/go/ezscrumcourse201206這Scrum課程吧…XD（迷之音：這就是所謂的置入性行銷嗎？）。

所以，主管沒事不要一直找工程師來開會。會議能不開就不開，真的要開的話也要跟女生的迷你裙一樣，越短越好。不該有的會議與報告最好全部廢除。還有，不要一直因為一些小事去中斷工程師手邊正在進行的工作。

第18頁：

明確的目標之所以帶來效率，正是由於它能幫助你擋掉別的專案丟過來不相干的垃圾，讓你專注在本專案的策略性事項。…組員的努力應該有代價，而長期加班、飽受壓力的小組，多半是工作漫無目標的後果。

很可惜，很多老闆、業務、行銷、產品經理、專案經理都不知道專案的目標是什麼。

產品經理：誰說我不知道，專案目標就是要拍老闆的馬屁啊。錯，應該說生活的目的，在於拍好老闆的馬屁。生命的意義，在於讓在其他人失去工作的動力。

Teddy：又是一隻「牠」。

第44頁。

要求程式設計師一發現bug就立即清除。

看到這一點Teddy知道有人在偷笑了。「哈哈，如果這一點做得到，那手邊的專案就不會累積數十到上百個bugs了」。

直接跳到第127頁。

不要讓程式設計師的學習停滯不前，要讓程式設計師有機會磨練不同領域的技術，培養十八般武藝樣樣精通的組員。

所以Teddy才會經常建議團隊除了要組成cross-functional team以外，還要採用pair programming與shared code這兩個practices。

最後一點，第181-182頁。

別誤信加班等於增加生產力，長期加班只會傷害生產力，對專案沒有幫助。成功的人不都是拼命工作的嗎？…有更多人的人日以繼夜工作卻一事無成，只是我們部會津津樂道他們的故事。批命工作並不是成功的關鍵，成功的關鍵是有一個明確的目標、具體且切合實際的計畫，以及每天不斷向這個目標邁進。

***

看了這本書對於作者Steve Maguire的介紹，說：「在過去十九年中，Maguire一直在美國和日本從事專業的程式設計工作」。嗯…日本…難道有學到Toyota生產管理那一套嗎？Teddy猜測Steve Maguire書中提到的作法應該不是那個年代微軟公司內部主流的開發方法。不過經過10幾年後再往回看，本書提到的大多數做法（不是全部，其中有一些Teddy覺得有點過時。例如，deadline到了但是產品品質不夠好，就把deadline延期）到今日不只是依然適用，而是成為軟體開發的主流做法…嗯嗯，至少看起來在國外是如此，至於台灣，落後國外何止十年啊。

***

友藏內心獨白：公司裡面有太多牠，怎麼可能搞好軟體。

2012日本東京賞櫻Day4-C東京車站與明治神宮

May 27 10:03~11:17

離開吃午餐的餐廳之後很快來到東京車站。耶，怎麼是一個大工地啊。

 

東京車站在整修，很多地方都被圍籬給圍起來。在圍籬上面還順便介紹一下東京車站的歷史。

很多看過東京車站的人都說，東京車站跟台灣的總統府好像。沒錯，東京車站的設計師是「辰野金吾」，總統府的設計師「長野宇平治」是「辰野金吾」的學生。學生應該是「參考」了不少老師的設計…XD。

東京車站在整修也就沒有在這裡停留很久，走吧，搭地鐵到下一站：明治神宮。

在地鐵站看到一台賣香蕉的自動販賣機，滿有趣的。

 

明治神宮入口的鳥居。

 

整個明治神宮的範圍基本上就是一座大森林。

 

就是一條大路，兩旁伴隨著很多大樹。

 

這個不曉得是什麼。

 

這好像是各國送給明治天皇的酒。

大鳥居，木頭是從台灣運過來的。

 

路旁還有介紹明治維新歷史的看板。

 

又看到一個鳥居，終於來到了目的地。這算是…祭祀明治天皇的神社嗎？

有人在修剪大樹。

說真的明治神宮占地大歸大，不過覺得有點小無聊，沒有讓人很印象深刻的感覺。唯一印象深刻的的方就是，地好大，腳好痠。

 

準備離開明治神宮的時候，在入口（也是出口）處看到有賣吃的，就在這裡休息一下再走吧。

 

路人甲。

 

剛剛看了一下照片，怎麼接下來的行程記錄的不是很清楚，那就直接跳過好了。下一集是今天晚上要去六本木，下週見。

***

友藏內心獨白：可能是走太累跑回旅館休息啦。

2012日本東京賞櫻Day4-B千鳥淵與二重橋

May 26 17:10~18:10

接近11點，終於走到了千鳥淵。來到這邊才知道原來千鳥淵對面就是靖國神社（該跑過去抗議嗎XD），下圖日本國旗下方的那個超級大鳥居，看起來應該不是木頭（去那找那麼大的木頭啊），而是銅製的。

 

這裡的景色真的很美，只可能櫻花還沒全部綻放啊。

 

看到這張照片就想到黃舒駿的一首，算是老歌的歌詞。「她，以為她很美麗。其實只有背影還可以」…XD。

 

想太多，還是看櫻花吧。

東京理科大學就在附近，環境也太好了吧。想到貴校XX科技大學就只有買電腦和電子零件比較方便…Orz。

 

其實今天主要來是看看櫻花開放的狀況，既然還沒全開就沒有在這裡待很久。準備到下一站，二重橋。走回地鐵站，真的有靖國神社和日本武道館的指示牌。

 

來到了日比谷驛，這裡有寫出口往二重橋方向。

 

走出地鐵站才發現，這個地鐵出口就蓋在護城河旁邊耶。

 

出地鐵站還好走好幾分鐘才會到二重橋。

 

過了上面那個馬路之後，還要走這一段才看到的。

 

看到了，但是好像覺得還好而已，不過因為是知名景點所以要過來看一下。雖然照片上看不到，不過這個景點的陸客有夠多，一輛輛遊覽車不停的載過來。

 

看看時間已經中午12點10分了，該吃午飯了。不知道這附近那裡有吃的，想說到東京車站附近用餐，順便看一下東京車站建築物。

 

往東京車站的路上，走了30分鐘之後，看到一家還不錯又不會太貴的餐廳，就在這邊吃飯吧。

 

Kay點的義大利麵。

Teddy點的一大塊豬肉加白飯，還滿好吃的耶。而且飲料（果汁跟咖啡）居然可以無限喝到飽。

 

兩個人吃了1780，應該不算貴吧。

 

還好有吃飯休息一下，不然真的走不動了，接下來繼續往東京車站出發。下集待續。

***

友藏內心獨白：今天上午幾乎都在走路，好累啊。