直接套用Pattern還是Refactoring to Pattern？

Mar. 12 17:22~18:00

畫面節錄自電影「達摩祖師傳」

 

繼〈Top-down和Bottom-up設計方法〉和〈先學物件導向還是先學設計模式？〉，今天再來談一個和「由上而下」和「由下而上」的問題：「寫程式的時候，要直接套用Pattern還是Refactoring to Pattern？」

看過〈Top-down和Bottom-up設計方法〉和〈先學物件導向還是先學設計模式？〉這兩篇的鄉民們，現在應該很清楚了，直接套用pattern，就是「由上而下」的設計方法。反之，如果先不管三七二十一把程式功能寫好，在必要的時候才將程式重構成pattern，這種做法就屬於「由下而上」的方式。

***

Erich Gamma在訪問中提到：

Do not start immediately throwing patterns into a design, but use them as you go and understand more of the problem. Because of this I really like to use patterns after the fact, refactoring to patterns…

Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution.

Gamma提到在問題還不明確的時候就套用pattern，很容易產生一個synthetic design（人造、想像中的設計），也就是為了設計而設計，通常都會伴隨著over design（過度設計）的問題。如果直接實作，等問題的輪廓慢慢浮現之後，再思考可以套用，或是將系統改成pattern，這樣子會比較保險。

***

鄉民甲：所以Teddy你的意思是說開發系統的時候先不要套用任何pattern，先把功能寫好，等到有需要的時候再重構成pattern這樣比較好？

鄉民甲：達摩大師說—無所謂好壞，端看造化而定。

Teddy：怎麼你也學會這一招了。

鄉民甲：因為我看出你講話的pattern了。

Gamma的意思是說，如果問題不明確，不要急著套pattern。因為此時套pattern變成一種bottom-up設計方式（理想上應該是top-down），連要解決什麼問題（整體概念）都還不清楚就貿然套用pattern，就很可能產生bottom-up設計方法的缺點，那就是「系統長歪掉了」。所以在這種情況下先藉由實作，然後把問題慢慢釐清，如果有需要再套用pattern，這樣子會比較好。在這樣的套用流程中，原本未知的整體已經成形，之後重構成pattern就比較不會遭遇什麼困難。

相反的，如果問題已經非常明確，這裡就是需要一個Observer，Teddy覺得就直接套用pattern也沒什麼不好。

***

回想之前開發系統的經驗，遇到的問題時候，會先看看有沒有什麼pattern可以套用。如果可以立即發現有pattern可以很清楚的解決problem，就立刻套用。否則，就先把功能做出來再說。做出來之後如果還是覺得有套用pattern的必要，再重構成pattern，否則就先維持原狀。整體來說，直接套用pattern跟重構成pattern的比例，可能各占一半（有時是6:4，有時是4:6甚至3:7也有可能，要看開發專案的特性，以及開發人員對於問題熟悉程度）。

***

友藏內心獨白：又是那句「普通人隨緣即變，得道者隨緣不變」。

先學物件導向還是先學設計模式？

Mar. 12 16:12~17:03

 

在〈Top-down和Bottom-up設計方法〉中，Teddy比較Pattern Language與Design Pattern所採取設計方法的不同，前者是由上而下的設計，後者是由下而上的設計。今天把範圍再縮小一些，談談物件導向（OO）和設計模式的關係。

很多人可能已經知道，design pattern用到了OO技巧，因此學design pattern至少要懂一些基礎的OO觀念，像是類別、物件、介面、繼承、多形等。而design pattern相對來講好像是比OO還要「高級」的技術，所以非得把OO學個「精通」，最好再去考個什麼OO證照之類的東西，再來學design pattern應該比較容易。

很不幸的，這種單純的bottom-up方式，有可能一直困在OO這一層，而延緩了「升級」的時機。

***

有一派人士認為，只要稍微了解OO觀念之後，直接學習design pattern可以反過來加速對於OO的理解。Erich Gamma在訪問中提到：

I think patterns as a whole can help people learn object-oriented thinking: how you can leverage polymorphism, design for composition, delegation, balance responsibilities, and provide pluggable behavior.

從這個角度來看，由pattern去學OO，就是一種「由上而下」的學習方式。由上而下的設計或是學習方式的好處，在〈Top-down和Bottom-up設計方法〉裡面已經談過，因為「整體」先存在，所以透過整體分解的過程，只是讓整體的輪廓更加清楚，比較不容易「長歪掉」。也就是說，每一個pattern代表著某些良好的OO特性，直接去學習pattern也就學到了個別的OO優點。當然這些OO優點也可以用「由下而上」的方式慢慢兜起來，但是在經驗不夠的情況下，可能需要花一段時間，或是嘗試過許多錯誤之後，才會慢慢發現如何靈活運用這些好的OO技巧。

***

鄉民甲：所以Teddy你的意思是說從design pattern來學OO這種方式比較好？

達摩大師：無所謂好壞，端看造化而定。

鄉民甲：切，又是這一句。

學習並不是一種線性的歷程，而是來來回回，逐步成長的過程，如此才能產生「層次」（怎麼跟敏捷開發那麼像）。所以，單一方向的top-down或是bottom-up，效果可能都不會很好。Teddy自己的經驗是，基本的OO觀念學一點，design pattern學一點，然後會對OO觀念有更具體與深刻的感受，再回頭學一些design pattern。依此類推，這種上下夾擊的方式比較容易累積功力。

不然賴尿蝦牛丸是怎麼來的。

***

友藏內心獨白：Context不同，原本的bottom-up就變成top-down了。

Top-down和Bottom-up設計方法

Mar. 12 08:40~10:10

Top-down（由上而下）和Bottom-up（由下而上）是兩種設計與解決問題的技巧。前者對問題先有一個整體的概念，然後再逐步加上設計細節，最後讓整體的輪廓越來越清楚。後者則是先將解決問題可能所需的基本元件、方案給準備好，然後再將這些基本元件組合起來，由小而大最後得到整體。

「由上而下」或「由下而上」這兩種解題方法，有時個別套用便可解決問題，有時則是在思考模式採取「由上而下」，把問題先分析、拆解之後，再採取「由下而上」的方式完成整體實作。

這兩個概念，其實很簡單，資訊相關科系大學生在學習程式設計的時候應該都會學到，沒什麼大不了的。但是其實案情並沒有那麼單純。Teddy在〈如何選擇第一個Pattern來設計軟體架構？〉提到：

Alexander說，套用pattern形成pattern language的精神是一種「整體先於部分，然後透過差異化的過程將整體逐步展開」。

Alexander的pattern language設計方法就是一種「由上而下」的設計方法？鄉民們可能會想：「由上而下就由上而下，那又怎麼樣？」接下來看一下GoF Design Patterns的設計方法。Erich Gamma（GoF的第一作者）在一次訪問中提到：

Alexander had a very ambitious goal which was to create architectures that improve the quality of life. To achieve this Alexander developed a pattern language. This is a set of patterns that build on each other. A pattern language guides a designer's application of individual patterns to the entire design. When we started design patterns we were not that ambitious. We used a more bottom-up approach based on micro-architectures.

以上這段英文請鄉民們花點時間稍微讀一下（保持原汁原味就不解釋了），接下來還有一段：

Rather than coming up with a set of interwoven patterns top-down, micro-architectures are more independent patterns that eventually relate to each other bottom-up. A pattern language guides you through the whole design, whereas we have these little pieces, bites of engineering knowledge. I confess that this is less ambitious, but still very important and useful. (註：micro-architectures就是design patterns)

***

讀完這兩段英文句子之後，先有一個概念：

Alexander的Pattern/Pattern Language設計方法是一種由上而下的方法，而GoF Design Pattern是一種由下而上的方法。

鄉民甲：那又怎樣啦？！

Alexander認為，如果要完成一個「整體性的設計」，無法經由「由下而上」的組合過程來達到。因為如果沒有先具備「整體」的概念，則「由下而上」的過程最後組裝出來的產品或是設計很可能會「長歪掉」。例如，你想要製造一朵真花，你必須從種子開始培育（由上而下）。如果將花瓣、花蕊、花粉、花蜜等採用由下而上的方式組合起來，你只能得到一朵「人造花」。

在上面第一段英文句子裡面，Gamma說：「Alexander had a very ambitious goal which was to create architectures that improve the quality of life.」Alexander的想法是希望設計可以達到Quality Without A Name的境界，從而改善人類的生活。因此Gamma說Alexander對於「設計」有一個雄心壯志的目標。

GoF Design Pattern則沒有那麼遠大的目標，主要的用途就是解決比較小的設計問題。至於採用「由下而上」的方式套用了一堆Design Pattern之後所形成的「整體」長得如何，是否「完整」，則不是Design Pattern所能或所想要解決的問題。這也是為什麼很多人，尤其是初學者，套用了一堆Design Pattern之後，雖然解決了一些特定的設計問題，但從軟體架構整體來看，設計的品質還有很大的改善空間。

***

鄉民甲：所以Teddy你的意思是說GoF Design Pattern比較不好？

達摩大師：無所謂好壞，端看造化而定。

Gamma自己評論說道：「I confess that this is less ambitious, but still very important and useful.」雖然GoF Design Pattern不像Alexander的Pattern Language有那麼大的企圖心，但還是很重要且有用的方法。

鄉民甲：Teddy，你搞得我頭好痛啊。

GoF Design Pattern出版至今已快20年了，當初剛出版的時候軟體領域的Pattern被整理出來的還不夠多，無法形成一個「生態系」。所以學習個別Pattern就好像是在「背單字」，至於可以用這些單字來組成何種概念，就只能「兄弟登山，各自努力」，交由個別程式開發人員自己去創造、發現。有些人成功，可以用GoF Design Pattern做出很棒的設計，有些人比較不成功，GoF Design Pattern搞了很久，系統的軟體架構還是長得像「違章建築一樣」。

這20年來，軟體領域的Pattern越來越多，從分析、架構、設計、實作、測試、流程、介面設計等，各種尺度的Pattern已經很完備了。把這「一拖拉庫」的Pattern全部視為一個整體然後由上而下，一個Pattern一個Pattern套用，就很接近Alexander的Pattern Language的境界。也就是說，在設計軟體架構的時候，可以靈活採用「由上而下」、「由下而上」，或是兩者合用的策略。

***

GoF Design Pattern用了一陣子但是對於設計軟體架構還是覺得力不從心？此為正常現象，因為「Design Pattern就是只是Design Pattern，只解決較小尺度的軟體設計問題，並不是Architecture Pattern」。當「由下而上」的方法卡住時，可以考慮先跳到「半空中」，採取「由上而下」的角度來看問題，說不定卡住的地方一下子就豁然開朗。

***

友藏內心獨白：我還是不明白啊…Orz。

[工商服務] 2014年5月Scrum課程開放報名

Mar. 24 22:45~11:00

 

Scrum敏捷開發方法在歐美甚至是對岸的中國大陸早已成為主流的軟體開發方式，很可惜在寶島台灣還是屬於「小眾市場」。最近「服貿」議題非常熱門，不管支持也好，反對也罷，提升自己與公司的競爭力，都是身為軟體從業人員時時刻刻不能鬆懈的任務。否則就算別人不來搶我們的工作，我們自己也會因為沒有競爭力而被淘汰。

不知道為什麼很多不錯的制度傳入國內之後最後都流於「形式化」。Scrum的觀念本身不難，但是實際導入之後要避免流於形式，把敏捷開發方法的精神「確確實實地做到位」，卻不是很容易的一件事。您正因為自己或是團隊每天處在熬夜加班的爆肝生活，想解脫卻苦無良方嗎？難道除了「上班打卡制，下班責任制」以外沒有其他更好的做事方法提升大家的競爭力嗎？

不是不知道方法，而是沒有找到對的人來傳授練功心法。還有沒有救？有，想幫您自己以及軟體開發團隊「換骨」提升戰力與生活品質的朋友們歡迎參加第九梯次「Scrum敏捷方法實作班」，開課日期為2014年5月3~4日（週六、週日），課程報名網頁在此。

課程特色：

• 任何人都可以上：不限軟體開發人員，只要想要了解Scrum的朋友們都可以報名參加，包含大老闆、專案經理、產品經理、介面設計師、工程師、技術經理等。
• 由Teddy授課：在歡笑聲中不小心就學會了Scrum。
• 最符合台灣現況的Scrum導入經驗：由Teddy在課程中分享不同產業導入Scrum的成功與失敗經驗。
• Scrum活動實作：課程搭配大量的練習活動（產生product backlog、sprint planning meeting、task break down、task board建立、daily scrum、retrospective meeting等） ，讓學員們在課程結束之後具備實際帶領Scrum團隊的基本能力。
• 小班分組模式：課程搭配實際帶領過Scrum團隊的助教，協助各組練習各項Scrum活動。
• 贈送Scrum工具包：課程推廣期間贈送一組Scrum Master必備的Scrum工具包，讓學員上完課之後可以帶著工具包立即協助團隊導入Scrum。
• 售後服務：上課學員可加入Facebook上專屬的「泰迪軟體敏捷開發課程社團」，課後有任何問題皆可在此發問。

課程進行方式請參考：

• 第一梯次：Day 1、Day 2。
• 第二梯次：Day 1、Day 2。
• 第三梯次：Day 1、Day 2。

詳細課程說明資料請參考報名網頁。

***

友藏內心獨白：認識無常，才能擁抱改變。

談談XP（3f）：Primary Practice

Mar. 11 21:44~23:55

 

介紹完Sit Together、Whole Team、Informative Workspace、Energized Work、Pair Programming、Story、Weekly Cycle、Quarterly Cycle、Slack、Ten-Minute Build、Continuous Integration，今天介紹最後兩個XP Primary Practice：

• Test-First Programming（測試先行程式設計）：在改變或新增任何程式之前，先為它寫一個失敗的自動化測試。Kent Beck說這個實務做法同時解決了：
  • scope creep （範圍蔓延）：Teddy在〈組織要如何解決更複雜的問題？〉提到：「先寫test code是要界定solution的context（因為直接設計出solution可能不容易，或是不小心會陷入over design的陷阱）」，所謂「界定solution的context」就是不要造成production code的「範圍蔓延」。因為用戶端的程式已經先寫好了（以test code的形式存在），所以production code這個solution也就固定了。依據Alexander的說法，當你有一種方法可以用來詳細描述context，則設計問題便不存在。
  • coupling and cohesion（耦合和內聚）：Teddy在上設計模式或是單元測試課程的時候經常提到，很多開發人員不寫測試，是因為測試程式很難寫，寫不出來。其實絕大部分的情況並不是「測試程式很難寫」，而是待測程式（production code）設計得很爛，導致很難測試。當測試程式寫不出來的時候，開發人員就知道設計出了問題，要想辦法降低耦合提高內聚。
  • trust（信任）：如果某人寫的程式動不動就出包，大家對這個人的信心指數將大幅降低。為了不讓你變成「某人」，先寫測試並利用自動化測試展示自己開發的程式功能正常，可以提高別人對你的信任感。
  • rhythm（節奏）：寫程式的人一定都遇過那種寫到頭昏腦脹，不知道自己在寫程式還是在寫bug的窘境。Test-First Programming的開發步驟—test、code、refactor，周而復始，讓程式開發養成一個規律的節奏。
• Incremental Design（漸進式設計）：每天投資一點時間在設計系統上面，努力讓設計完美滿足當天系統所需即可。很多鄉民聽到 「漸進式設計」，就會想到Martin Fowler這篇著名的文章〈Is Design Dead?〉，然後導出「big up-front design」（花很多時間在事前設計）不好，然後再簡化成「任何的up-front design都不好」的結論。Kent Beck在書上提到，如果你已經 很有經驗，「漸進式設計」並不是說事前設計是很糟糕的。它只是建議，當需要的時候再做設計工作，是比較有效率的方式。這種看法和Alexander所說的piecemeal growth（逐步成長），還有精實開發所說的「儘量延遲決策時間」，都是一樣的道理。

Kent Beck提到一個很基本的提升設計品質方法，大家都知道但卻很難做到，那就是「eliminate duplication」（消除重複）。所謂「重複」不單只是「程式碼一模一樣」才叫做，結構或邏輯重複也算。

***

要支援「漸進式設計」以及「測試先行程式設計」，都需要仰賴refactoring（重構），而重構有需要有足夠的測試案例來確保重構後的程式沒有改變系統外在行為。

最後補充一點，Test-First Programming和Test-Driven Development（TDD）有什麼不一樣？Teddy原本一直以為這兩個實務做法是一樣的東西，只是XXX-driven development這樣的「命名pattern」在軟體界很常見，什麼TDD、BDD、DDD，而Test-First Programming縮寫變成TFP，就不像TDD那麼酷了。

剛剛google了一下，還真的有人列出這兩者的相同與相異之處。雖然Teddy覺得這樣的差別似乎不是很重要，基本上把就算是提到TFP，大部分的人腦袋裡面應該都是直接以TDD代換。有興趣的鄉民可以自行參考一下這篇文章：〈The Differences Between Test-First Programming and Test-Driven Development〉。

***

友藏內心獨白：終於寫完了XP的13個Primary Practice。

2013北京考察之旅Day3-B國子監

Mar. 12 11:20~12:18

結束故宮購票之旅，決定改去國子監。出了地鐵站之後，看到北京的公共自行車租借站。雖然沒有實際試用，但是光是看車輛的外表，從「以貌取人」的評分標準，台北的Ubike大勝。捷安特製造的Ubike，號稱一台成本一萬多台幣，也算是真材實料。

***

國子監從隋朝以後就是中國官方最高學府，是讀書人研究學問的地方，也招收外國留學生，所以也包含給留學生讀書與住宿的建築物。

進入國子監，裡面非常幽靜，古木參天，很有一種回到古代的fu。首先看到的大型建築物是建於乾隆四十八年（1783年）的「琉璃牌坊」。正面刻有「圜橋教澤」，背面則是「學海節觀」（什麼意思？）。

***

「辟雍」是國子監的中心建築，蓋在一個圓形水池中央的四方高台，代表天圓地方，非常漂亮的一個建築物。在乾隆皇帝之後，只要有皇帝即位都會來這裡開講，表示朝廷對於讀書人的重視。

***

「彝倫堂」早年是皇帝講學的地方，蓋了辟雍之後改為藏書處。印象中門鎖著不能進去。

***

在辟雍左右兩側有33間房，合稱為六堂：率性堂、誠心堂、崇志堂、修道堂、正義堂、廣業堂，以前是讀書的教室，現在變成展示廳。

***

在某個角落找到「中華民國」。

***

友藏內心獨白：難得的寧靜。