2009冬遊日本京都Day5-A嵯峨野小火車

Jan. 24 21:49~22:59

今天要去搭「嵯峨野小火車」，買了區間車票準備搭到馬堀驛。

 

早上9:06分，到好濃的霧啊。

 

到了馬堀驛，要步行10分鐘到龜岡驛，這一站才是搭小火車的地方。。

 

有圖有真相…XD。

 

快到了。

 

一路上的可以慢慢欣賞鄉村景色，不過霧還是很大，有種朦朧之美。

 

CSI 犯罪現場，這是有野生動物來偷吃嗎?!

 

09:18到達達龜岡驛，不過還沒開門啊，09:40才營業…Orz。

 

那就到附近隨便逛逛吧。

 

9:40開門了。

 

此時也來了一台遊覽車，有沒有那麼巧，居然是台灣觀光客啊。原本的寧靜，瞬間變成…很熱鬧的場子，完全展現出台灣人的熱情。

 

月台上有…應該是「狸貓」的雕像。

 

車站內有車廂座位圖。

 

當然也要有賣紀念品的。

 

火車來了、火車來了。

 

內部座位圖。

 

接下來就是路途中的照片，沿途景色真的很美，請看。

 

過山洞時車內的小燈會亮起，挺有意思的。

 

繼續看風景。

 

照相、照相。

 

到了。

 

這個車站比起另一頭的龜岡驛要大多了。

 

不過到了站外一看，站名卻是嵯峨驛。

這裡就是傳說中的嵐山，有很多景點可以逛。下集待續。

***

友藏內心獨白：小火車，好玩。

[工商服務]泰迪軟體敏捷開發訓練藍圖

Jan. 24 14:28~16:12

泰迪軟體敏捷開發課程訓練藍圖，虛線表示尚在規劃的課程

***

幾天前Teddy在整理泰迪軟體2013年公開課程的課表（請參考《2013年課表》），有鄉民看了課表之後問Teddy：「你會開refactoring（重構）的課程嗎？」Teddy這幾天思考了一下，覺得應該把目前自己心目中認為比較重要的敏捷開發技術列出來，讓鄉民們可以 提早存錢 對泰迪軟體所規劃的敏捷開發課程有比較全面的了解。

上面這張敏捷開發訓練藍圖所規劃的課程，主要可以分成三大類：

• 開發流程框架：這個分類有Scrum與Kanban，目前泰迪軟體提供的開發流程框架以Scrum為主，Kanban的課程還在規劃中。了解了開發流程框架之後，接下來的各種開發技術與實務做法，就可以依據團隊需要慢慢地導入。所以上面這張訓練藍圖的起點是從「Scrum敏捷開發實作班」這個課程開始。上過這個兩天的「Scrum敏捷開發實作班」的學員們，便具備了泰迪軟體的「Scrum之友」身分，之後參加泰迪軟體所舉辦的其他課程或是活動，都有特別的優惠（反之不亦然）。Teddy希望藉由這樣的安排，能夠多吸引一些鄉民們來接觸Scrum（迷之音：說不定人生會因此而改變喔）。
• 開發技術與實務做法：位在開發流程框架之下的所有課程都屬於這一個分類，今年度招生的課程有「Design Patterns這樣學就會了：入門實作班」、「Design Patterns這樣學就會了：進階實作班」、「單元測試與持續整合實作班」、以及全台灣僅此一家，別無分號，想學也找不到人可以教的「例外處理設計與重構實作班」（Teddy內心獨白：因為這是Teddy博士論文的研究內容，所以找不到別人可以教啊…XD）。其他的課程，除了「Web與手機App驗收測試實作班」有可能在今年下半年度開課以外，應該都要等到2014年才會開課（開發教材要花不少時間啊）。
• 敏捷需求管理：位在開發流程框架之上的課程屬於這個分類，目前只規劃一門「敏捷需求管理實作班」，快的話可能在今年下半年度開課，慢的話就要等明年了。其實需求開發或是需求管理這件事情，對於任何一種專案，都是極為重要的一個課題。因為需求搞錯了，做出來的東西品質再好，也賣不出去啊。目前Teddy的時間大都分配到上課、敏捷開發企業導入顧問、以及寫作上面，所以暫時比較沒有時間去整理這方面的課程教材。

***

友藏內心獨白：每天寫部落格也花了不少時間啊。

讓軟體變軟的兩個原則

Jan. 22 16:02~18:10

之前Teddy曾寫過一篇《什麼是軟體工程 (2)》，文中提到：

1. 軟體不是軟的。事實上，軟體很硬。
2. 軟體工程的目的：
   • 讓你可以把軟體做出來。
   • 讓你的軟體變軟。
   • 讓你在可接受的成本範圍內達成上述兩件事。

今天Teddy想談一下，「如何讓軟體變軟」的兩個原則。

***

為什麼軟體很硬

在介紹這兩個原則之前，先幫鄉民們複習一下，為什麼軟體會變成「硬體」？所謂「軟體很硬」指的是以下現象：「只要一修改或增加新功能，便很容易導致原本正常運作的功能發生錯誤。更慘的是，這些錯誤通常過了一陣子之後才被發現，導致非常冗長的debug週期，最慘的情況甚至導致整個團隊都沒有人知道要如何修復這些問題」。所以，漸漸地團隊成員沒有人 敢 願意動手修改現有可運作的程式。在這種情況下，要達到XP（eXtreme Programming）所說的「擁抱改變」是不可能的，「抵死不變」反倒成為團隊追求的目標。如果鄉民們手邊的專案也有上述「症頭（症狀）」，恭喜您，正式從「軟體開發」升等為「硬體開發」。

方法一：自動化測試

讓軟體變軟的第一個方法，就是導入自動化測試（單元測試、整合測試、功能測試…等等）。為什麼做自動化測試可以讓軟體變軟？答案很簡單：

• 有了自動化測試，每次修改程式之後，重新執行一次測試案例，讓這些測試案例幫忙確認「原本正常的功能，在本次修改之後還是正常的」。 若測試案例執行失敗，便可知道很可能是因為剛剛修改程式所導致的問題。此時要debug找出問題相對來講會容易許多。
• 自動化測試可以支持軟體重構（refactoring），而軟體重構有點像是「SKII 保養品」，可以「消除皺紋，讓皮膚緊緻，找回青春」。也就是說，藉由重構可以讓漸漸僵硬的軟體，恢復昔日柔軟的身軀。

方法二：提升設計能力

在眾多的軟體設計原則中，有一個最基本的概念，就是「提高內聚力，降低耦合度」（請參考《亂談軟體設計（1）：Cohesion and Coupling》）。如果軟體的耦合度太高，軟體中各個元件的相依性就變得很高，因此當軟體被修改之後，很容易發生「牽一髮而動全身」的「漣波效應」。這種現象正是軟體變硬的原因之一，如果可以讓修改所造成的影響局部化，就可以避免漣波效應產生。

但是在實務上要如何做到「提高內聚力，降低耦合度」，或是「區域化修改所造成的影響」？方法很多，例如：

• 從基本的物件導向觀念著手，正確使用Class、Object、Interface、Inheritance、Polymorphism、Composition、Delegation這些基本功夫便可達到不錯的療效。
• 從物件導向設計原則著手，例如Open-Closed Principle、Single-Responsibility Principle、Liskov Substitution Principle、Dependency-Inversion Principle、Narrow Inheritance Interface Principle等等。
• 從模組化設計原則著手，例如Reuse-Release Equivalence Principle、Common-Reuse Principle、Common-Clouse Principle、Acyclic-Dependencies Principe、Stable-Dependencies Principle等等。
• 從GoF的23個設計模式著手，請上最新的「Design Patterns這樣學就會了：入門實作班（平日班）」與「Design Patterns這樣學就會了：進階實作班」XD。
• 從軟體架構著手，請自行參考軟體架構書籍。

***

自動化測試和提升設計能力是息息相關的兩項技能。Teddy經常聽到鄉民們抱怨：「測試好難寫，所以不寫測試了」。「測試好難寫」這件事，背後的真正原因，除了鄉民們尚未學習到撰寫測試的方法之外，另一個常見的原因則是「軟體設計不良」（請參考《需求變來變去的情況下需要寫單元測試嗎？》）。如果鄉民們能夠接受「撰寫程式」這件工作同時包含了「寫production code」與「寫testing code」這兩個活動（何者順序優先都可以），那麼你的軟體一直維持在18歲的機率就蠻高的。就算沒有辦法一直維持在18歲，也絕對是個「美魔女」啊。

***

友藏內心獨白：常吃富含膠質的食物可以讓軟體變軟嗎 ？！

台灣工程師，好棒

Jan. 21 21:21~22:47

成立泰迪軟體之後，Teddy認識了不少朋友。後來才慢慢發現，原來在台灣（主要在台北）有那麼多各式各樣的活動，舉凡軟體開發、創業、介面設計、人生哲理…真可說是應有盡有。更難能可貴的是，很多工程師利用下班或是假日的時間，藉由參加這些活動或是課程，不斷地吸收新知與成長。現在想起來，Teddy真的是挺懶的。這些活動，在還是身為上班族身分的時候，一個也沒參加過。

***

在上禮拜《第二梯次Design Patterns這樣學就會了入門實作班，Day1》上課的時候，Teddy依照慣例請每位學員談一下為什麼會來報名這門課的原因。幾乎每個人都提到：「目前工作上所負責開發或是接手維護的軟體程式碼都很混亂，很難理解與修改，希望能藉由套用設計模式來改善這個問題」。另一個常見的原因則是「同事抱怨看不懂套用設計模式之後的程式碼，覺得幹嘛把一件事情變得這個間接，感覺套用設計模式之後程式反而變得更不容易理解。雖然自己覺得應該要套用設計模式，但是卻又不知道要如何說服同事一起在程式中使用模式，所以希望上完課之後可以將設計模式融會貫通，回去之後有能力可以說服同事，一起在工作中套用設計模式，提升他們的設計能力。」

Teddy內心獨白：那你應該找你同事來上課，這樣讓Teddy直接教化他不是比較快嗎 ？

每次Teddy看到報名參加泰迪軟體公開課程的學員報名資料，內心都覺得很感動。台灣的工程師，真的好拚、好認真。參加課程的學員，利用假日來進修，而且幾乎每堂課有70%以上的學員都是自費參加。自掏腰包學得一身「絕世武功」之後，繼續貢獻給公司或跳槽（Teddy內心獨白：為什麼很多問題公司都丟著不管，反而是基層的小工程師要自己想辦法哩？）。

希望台灣的大老闆們，能夠好好珍惜這些認真打拼的員工，撥點錢讓他們來上Teddy的課吧…嗯嗯，應該是撥點錢讓他們接受妥善的訓練。跟Teddy一樣開課提供教育訓練服務的單位，也要好好的設計課程，找最好的講師，用心授課，這樣才不會辜負學員們繳交的學費。這些都是大家辛辛苦苦「賣肝」存下來的錢啊。

***

友藏內心獨白：台灣經濟奇蹟幕後的無名英雄，絕對不是「阿B」啊。

第二梯次Design Patterns這樣學就會了入門實作班，Day2實況報導

Jan. 20 23:52~Jan 21 00:23

每一組都有一位助教協助學員們實作練習

***

第二天的課程一開始介紹Observer，Teddy設計例子是「保全監控系統異常狀況通知」。

 

每一個pattern都有練習活動，實作的時候現場突然變得安靜起來，大家進入「工作模式」。

 

接下來是介紹State模式。實作State模式的第一步就是要劃出state transition diagram，把每個狀態用一個State類別來表示。

 

介紹完有點小複雜的State，接下來穿插一個比較簡單的Facade模式。講解完畢之後請學員們思考一下如何在自己的工作中應用Facade。

 

最後用一個逐步演化的例子，一口氣介紹Simple Factory、Factory Method、與Abstract Factory這三個有點像，又不會太像的模式。

***

這兩天的下午茶都是東區粉圓。昨天的燒仙草太甜了一些，跟商家反應之後，得到的solution是：「太甜的話，可以加點冰」。

Teddy內心獨白：我點的是熱的耶。

***

友藏內心獨白：發功發太久，到第二天下午就沒力了。