l

2012年5月31日 星期四

Pattern是個雙面人(上)

May 30 23:18~May 31 00:20

image

 

如果有人問你:「什麼是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的目的。

螢幕快照 2012-05-30 下午11.47.01

 

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是黑白郎君嗎?

2012年5月30日 星期三

六折出清

May 30 12:26~13:55

螢幕快照 2012-05-30 下午12.49.04

 

前幾天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。

2012年5月29日 星期二

完美是動詞

May 29 09:55~11:19

螢幕快照 2012-05-29 上午11.13.26

 

昨天下午約了人在台北車站附近談點事情,下午三點二十「會議」結束之後,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。

***

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

2012年5月28日 星期一

重讀舊書有感:Debugging The Development Process

May 28 10:43~12:11

image

十幾年前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年5月27日 星期日

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

May 27 10:03~11:17

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

01

02

 

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

03

04

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

05

06

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

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

07

 

明治神宮入口的鳥居。

08

 

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

09

 

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

10

 

這個不曉得是什麼。

11

 

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

12

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

13

14

 

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

15

16

17

 

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

18

19

20

21

22

有人在修剪大樹。

23

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

 

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

24

 

路人甲。

25

 

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

***

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

2012年5月26日 星期六

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

May 26 17:10~18:10

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

01

 

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

02

 

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

03

 

想太多,還是看櫻花吧。

04

05

06

07

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

08

 

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

09

 

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

10

 

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

11

12

 

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

13

 

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

14

 

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

15

16

17

18

19

 

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

 

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

20

21

22

 

Kay點的義大利麵。

23

25

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

24

 

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

26

 

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

***

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