2016大阪姬路神戶考察之旅Day6-F英國館 & 法蘭西館

Oct. 28 13:05~13:33

▼來到北野異人館區域的下方，這也是搭CityLoop觀光巴士下車處。

 

▼來到對面的英國館，顧名思義館內展示與英國相關的物品，主題是福爾摩斯。

 

▼館內有免費的服裝讓遊客換裝拍照。

 

▼館內展品，幾乎都和福爾摩斯有關。

 

▼館外有一個英式小花園，到處都是福爾摩斯的影子。

***

▼離開英國館來到隔壁的法蘭西館（洋館長屋），裡面展示法國文物。

***

友藏內心獨白：差不多了吧。

做了才有感覺

Nov. 25 10:40~11:34

 

昨天上午在北科上「敏捷與精實軟體開發」，一上課擔任「專案經理」角色的同學先報告上週專案進度，包含專案看板、用Cucumber寫成的自動化驗收測試、跑在Jenkinks上的整合報表。看完之後Teddy問了幾個問題：

1. 看板的邊界在哪裡？lead time怎麼計算？
2. 知道看板邊界之後，誰是你們的上游、誰是下游？你們和上、下游的關係如何？如何透過增進上、下游關係來改善你們的敏捷度？
3. 為什麼看板第一個工作階段「Backlog」沒有設定WIP？
4. 如何、何時決定把工作項目拉進Backlog？
5. 用Given-When-Then（GWT）格式寫成的自動化驗收測試Ｗhen的部分有兩條句子，用 and連接起來，為什麼要這麼寫？會不會有什麼問題？
6. 「定義測試DoD」這個工作項目已經完成了，當初該工作項目在看板流動的時候是經過分析、實作、才流到測試階段，還是直接從Backlog拉到測試階段？

針對這些問題和學生討論過後，他們也問了幾個問題，其中有一個比較有趣的問題：

學生：一個工作項目從「Backlog」拉到「分析階段」，分析完成之後發現太大，可以切成兩個工作項目嗎？例如「開發票」這個功能，經過分析階段之後發現可以分成「二聯發票」和「三聯發票」。

Teddy：為什麼要切？

學生：因為不切會做不完？

Teddy：何謂「做不完」？看板有要求你要在多久完成一個工作項目嗎？

學生：「做不完」的意思是要花比較長的時間才能完成。

Teddy：這個狀況在看板中會如何展現？

學生：就…會有比較長的lead time（交期）？

Teddy：對啊，所以發現lead time太長就是一種改善的訊號（看板六大原則第三條：Managing Flow）。你們應該是Scrum跑太習慣，所以地一個反應會想把工作項目切小一點，希望在「一個開發週期中完成」，忘了看板是「流（flow）」的概念。

Teddy：但是，這個問題也有另一個角度可以探討。請問你們Backlog工作階段的「DoR」（Definition of Read）是什麼？

學生：我們沒有訂。

Teddy：這會不會是問題的根源？因為工作項目沒有跟「上游的人」討論清楚就直接拉到Backlog，所以才會在分析之後想要把工作切小。為了縮短lead time，在看板中如果可以在工作進入Backlog之前就先切成大小相近且偏小的工作項目也許可以改善這個問題。

Teddy：最後退一萬步想，你可不可以在分析之後把一個工作項目切成兩個？你想這麼做也不會有警察來開你罰單。

***

友藏內心獨白：是不是比微積分簡單很多。

軟體架構模式（3）：Model-View-Controller

Nov. 23 09:27~11:20

▲圖片節錄自《POSA 1》

 

今天介紹的是鄉民們聽到耳朵都快長繭的Model-View-Controller（MVC）模式，看看《POSA 1》書中如何描述它。

Model-View-Controller

MVC模式將互動系統切割成三個元件：Model包含核心功能與資料、View顯示資訊、Controller處理使用者的輸入。View和Controller合在一起構成使用者介面，並透過異動通知機制確保使用者介面與model維持一致性。

Context：你所設計的互動應用系統包含靈活的人機介面。

Prooblem：如何分解一個系統？

Forces：

• 相同資訊以不同的方式顯示在不同的視窗或使用者介面上。例如分別用長條圖與圓餅圖顯示總統候選人的支持度、用數位與類比方式顯示目前溫度。
• 資料顯示與應用程式行為必須要立即反應資料操作結果。例如溫度改變必須立刻被反應在使用者介面上，或是使用者透過介面調整電腦時間必須被寫回電腦系統。
• 改變使用者介面應該要很容易。
• 支援新的 "look and feel" 標準或移值使用者介面不應該影響到應用程式核心程式碼（model可以繼續使用）。

Solution：將互動系統切割成三個範圍：processing（Model）、output（View）、input（Controller）。Model封裝核心資料與功能，並且獨立於特定的顯示方式與輸入行為。View負責顯示Model的資料，一個Model可以包含多個View。每一個View有一個Controller用來接收輸入（例如滑鼠或鍵盤事件），並將其轉換成對Model或View的呼叫。

區分Model與View/Controller讓我們可以使用多個View來顯示相同Model。如果使用者透過某個View的Controller改變Model的資料，所有其他相依於該Model的View將會收到Model關於資料異動的通知，如此一來這些View便可從Model接收異動的資料並用來更新自己所顯示的資訊。

Resulting Context：

• 可以使用多個View來顯示相同的Model。
• 顯示相同Model的多個View之間可以保持同步。
• 可插拔的View和Controller。因為View/Controller和Model分離，所以可以改變用來顯示Model的使用者介面，甚至可以在runtime做出這樣的改變。
• 當系統轉移到其他平台的時候，可以只更換使用者介面而繼續保留Model。
• MVC可以被使用於應用程式框，減化互動程式的開發。
• 增加複雜度。嚴格區分MVC有時候會增加系統複雜度，例如在menu或簡單的text元件上套用MVC可能就變成殺雞用牛刀。
• 當Model改變的時候可能會造成過度的異動通知，例如也許不需要通知最小化的視窗去去更新資料。
• 雖然MVC區分了Model、View、Controll，但View和Controller其實是緊密偶合的元件，很難各別被重複使用。
• View/Controller和Model之間有緊密的耦合關係，如果Model改變很可能會造成View/Controller也跟著改變。
• 更新View所造成的低效率資料存取。為了更新資料，View可能需要呼叫Model好幾次以獲得所需資料。不必要的讀取未異動資料將降低執行效能。
• 移值到不同使用者介面平台存在對於View與Controller不可避免的修改。「理論上」和使用者介面有關的部分都被封裝在View和Controller身上，移值到不同的使用者介面應該只要替換View和Controller。實際上View和Controller有時會包含一些與平台有關的程式碼，在這種情況下如果系統未來有移值的需求則需要進一步將這些與平台相依的程式碼封裝起來。
• MVC與圖形使用者設計工具的整合。不同的圖形使用者設計工具可能有它自己的框架，並不一定與MVC相容。例如有些工具會把輸入事件自動轉派給特定的callback function，因此就不需要額外在提供一個Controller元件給View。

Known Uses：Smalltalk、MFC、.Net MVC、Spring MVC。

***

在實作上MVC有很多變形，以《POSA 1》書中為例，View和Controller都實作Observer介面，都可以接收到Model的資料異動通知，也都有機會去更新View。下圖是《POSA 1》書中對於View和Controller的責任描述，其中更新資料是View的主要責任（implements the update procedure），對Controller來說則是次要責任（implements the update procedure, if required）。有一種作法是讓View和Model自動綁在一起，因此使用者就不需要去實作更新View的程式。另一種作法則是減少View和Model之間的耦合，讓Controller全權負責View的資料更新。還有另一種極端則是把一個視窗中所有View的Controller都集中到一個稱為Presenter的元件身上，讓它集中負責View的更新與輸入，而View只負責最簡單的顯示，這種模式稱為Model-View-Presenter（MVP）。

MVC還有其他的變形，以後有機會再介紹。

▲View和Controller的CRC卡，節錄自《POSA 1》

***

友藏內心獨白：MVC是互動應用程式的基本款架構。

軟體架構模式（2）：Pipes and Filters

Nov. 22 16:16~18:05

▲圖片節錄自《POSA 1》

 

今天繼續介紹《POSA 1》書中另一個很常用的架構模式：Pipes and Filters（管線與過濾器）。

Pipes and Filters

Pipes and Filters提供一個處理資料流（data stream）的架構，每一個處裡步驟被封裝在filter元件中，資料則是透過pipe在兩個相鄰的filter之間傳遞。透過重組filter可以建構出不同功能的系統。

Context：你所設計個系統需要處理或轉換一個輸入資料流。

Prooblem：如何分解一個系統？

Forces：

• 開發人員或終端使用者可以藉由交換或重組處裡步驟來增強系統功能。
• 小的處裡元件比起大的處裡元件更容易在不同的情境（context）中被重複使用。
• 不相連的處裡步驟不需要共享資訊。
• 存在不同的輸入資料來元，例如網路連線、硬體感應器傳回的資料。
• 最終的處裡結果可以採用多種方式來表現或儲存。
• 如果讓使用者自行用檔案儲存處理過程的中間結果以便做更進一步的處理，很可能產生雜亂的目錄且很容易出錯。
• 可能會採用平行處理的方式來處理資料。

Solution：將系統切割成數個循序的處理步驟稱為filter，並透過稱為pipe的資料流將這些步驟串接起來。一個filter的輸出資料成為下一個filter的輸入資料。Filter並非一次處理完全部的輸入資料再一口氣將其輸入，而是採用增量方式處理與產生資料以降低延遲與支援平行處理。系統的輸入稱為data source，例如文字檔案、網路連線串流影音資料，系統的輸出資料流至data sink，例如檔案、終端機、動畫程式、影片播放軟體。Data source、filter、data sink透過pipe循序地連接在一起，每一個pipe實作連接相鄰兩個filter的資料流。Filter與pipe的串接順序稱為processing pipeline（處理管線）。

Resulting Context：

• 不需中間檔案，但有需要時可以透過「T型接頭（T-junction）」產生中間檔案以供檢查之用。
• 相同功能不同實作的filter彼此可以有彈性的替換。
• 透過重組filter可以產生不同的processing pipeline達到不同的處理功能。
• 可重複使用filter。
• 可以藉由重組filter快速產生資料處理系統的雛形，之後再逐步優化系統。
• 可以透過平行處理來增加效能。
• 共享狀態的代價較高或不靈活。如果多個處理階段需要共享大量的全域資料，套用Piples and Filters幫不上什麼忙或是無法提供該模式的全部優點。
• 平行處理所獲得的效率有時候會是一種幻覺（眼睛業障重）。很多原因會減低平行處理所帶來的效率提升，例如在filter之間傳輸資料的成本、有些filter可能把所有輸入資料全部處理完之後才一口氣產生輸出、thread之間的context-switching成本、filter之間透過pipe同步資料的成本等。
• 為了提供最高的彈性，Pipes and Filters採用單一資料結構做為所有filter的輸入與輸出，但付出的代價就是filter可能需要付出資料轉換的成本。例如假設所有傳輸資料都使用字串格式，某個處理數字的filter需要先將輸入字串轉成數字型態，處理完畢之後再轉換成字串型態輸出。
• 錯誤處理是Piples and Filters架構的痛點，至少必須規範一個共同的錯誤回報策略並且在整個系統中都使用它。具體的錯誤回復與錯誤處理策略相依於processing pipeline所要解決的問題，因為Piples and Filters提供彈性的processing pipeline組合方式，所以具體的錯誤處理也變得更加困難。

Known Uses：UNIX系統、影音播放軟體的編碼器與解碼器、Microservice架構。

***

友藏內心獨白：Piples and Filters符合單一責任原則。

軟體架構模式（1）：Layers

Nov. 21 16:35~17:43

 

上禮拜六上完「Design Patterns這樣學就會了：進階實作班」有學員問Teddy除了GoF的23個patterns有沒有其他pattern可以介紹？想來想去先從比較常見的軟體架構模式介紹起，這一系列文章挑選《POSA》（Pattern-Oriented Software Architecture）書中比較常聽到的模式來介紹。

Layers

首先介紹Layers（階層、分層）架構，它的主要用途是將系統分解成若干個具備相同抽像層次的群組，每個群組就稱曾一個layer。

Context：你所設計個系統其主要特性必須要解決高階與低階的議題，在其中高階的議題相依於低階的議題。

Problem：如何分解一個大系統？

Forces：

• 某個元件的異動不應該引發漣波效應影響到整個系統。
• 界面應該非常穩定，甚至被標準組織訂為規格。
• 系統的部分元件可以被其他實作方式替換而不影響系統其餘部分的運作。
• 在日後可能會使用相同的底層功能來建構其他不同的系統。
• 相似的責任應該被放在一起以助以理解與維護系統。
• 沒有標準的元件粒度大小規範。
• 複雜的元件需要更進一步的分解。
• 跨越元件邊界可能會有損效能。
• 系統由一組開發人員所建構，而且工作必須要切割成清楚的界線。需求通常在架構設計階段被審視。

Solution：將系統切割成合適數量的階層，從最低階層的抽象化開始定義，稱它為Layer 1。以此為基礎逐層往上定義，讓Layer J在Layer J-1之上，一直到最上層Layer N為止。

Resulting Context：

• 只要Layer有清楚的抽象層，它可能可以在不同的情境（context）被重複使用。
• 支援標準化與互換性。
• 相依性被控制在區域端，標準化的階層介面讓相依性控制在上下兩個階層之間。
• 階層內的行為（介面）改變可能會引發一連串的行為改變。例如，將網路底層由10Mb的乙太網路換成155MB的ATM網路，上層模組可能因為記憶體、執行效率等問題的支援導致一連串的修改。
• 階層可能導致執行效率降低。
• 非必要的工作。如果低層所做的若干處裡並沒有被高層模組所使用到則會造成非必要的浪費。例如在網路傳輸中底層為了多工（multiplexing）傳輸而增加了額外欄位來處裡，但高層應用程式並不一定需要多工服務。
• 階層的粒度（granulartty）不容易定義，定義太少階層可能降低重複使用性與替換性，定義太多階層造層不必要的複雜性。

Known Uses：Virtual Machines、Information System（一般資訊系統可分為Presentation、Application、Domain、Database這幾層）、Windows NT（迷之音：好古老的例子）。

***

在傳統的階層架構中，上層會相依於下層。如果要避免這個問題，可以參考〈Dependency-Inversion Principle〉，相依反倒原則。

***

友藏內心獨白：分層負責。

2016大阪姬路神戶考察之旅Day6-E北野天滿宮 & 六甲牧場霜淇淋

Oct. 28 12:37~12:58

▼北野天滿宮就位於風見鶏的館的右手邊，之前從風見鶏的館所看到的一片盛開的櫻花就位於野天滿宮境內。

 

▼爬上這段階梯就到了。

 

▼北野天滿宮不算大，但視野極佳。不但可俯看櫻花，還可遠眺神戶港。相較於風見鶏的館前方廣場的人潮，這裡的遊客也比較少，鬧中取靜。

 

▼因為北野天滿宮獲得意外的賞櫻行程。

 

▼可清楚看到櫻花、風見鶏的館的屋頂、神戶港，三種願望一次滿足XD。

***

▼還有幾個異人館尚未參觀，繼續往山下走途經販賣六甲牧場霜淇淋的商店。六甲牧場是神戶有名的牧場，買了隻霜淇淋和Kay一起吃。因為太好吃了忍不住又買了一隻。

***

友藏內心獨白：日本幾乎到處都有霜淇淋。