2016大阪姬路神戶考察之旅Day2-C岡山城

July 22 12:55~13:40

▼離開後樂園往旁邊的岡山城移動，兩點之間只隔著一條小河。

 

▼後樂園和岡山城相對位置。

 

▼河中可划船。

 

▼走過鐵橋。

 

▼再走一小段路就來到岡山城入口。

 

▼現存的岡山城天守閣是後來重建，原本的位置在此，剩下地上的礎石作為見證。

 

▼岡山城天守閣遠看很壯觀，近看就很平易近人。

 

▼買票進入天守閣。

 

▼登上天守閣頂，視野很好，看到一大片的櫻花樹。

 

▼遠眺後樂園，下午遊客比較多。

 

▼天守閣前方空地有音樂表演，類似表演在賞櫻季節的熱鬧景點很常見。

 

▼天守閣內有展示一些文物介紹岡山城的文物。

 

▼還可以體驗戰國大名搭乘的轎子。

***

友藏內心獨白：轎子有點小，坐起來不是很舒服啊。

2016大阪姬路神戶考察之旅Day2-B岡山後樂園（下）

July 21 17:35~18:10

▼從後樂園眺望岡山城，就在不遠處。

 

▼有人在園中拍婚紗照。

 

▼櫻花盛開。

 

▼以前藩主的船可以開進來。

 

▼烏龜曬太陽。

 

▼逛了80分鐘，也夠久了，準備前往旁邊的岡山城。

***

友藏內心獨白：還好有櫻花。

套用Design Pattern的時間點

July 29 10:10~11:04

 

上週末的「Design Patterns這樣學就會了–入門實作班」有學員問：「應該在什麼時間點套用設計模式（design pattern）？」這個問題Teddy曾經在〈直接套用Pattern還是Refactoring to Pattern？〉談過，今天從軟體生命週期的角度再來討論一次。

廣義的說，有兩個套用design pattern的時間點：

• 設計階段：如上圖所示，從物件導向分析與設計流程來看，在了解客戶需求也就是完成分析工作（建立use case mode與domain model）之後的設計階段（建立design model），此時是第一個套用design pattern的時機。例如，你要開發一個給DevOps使用的監控雲端服務軟體，在分析完問題之後，在設計階段你發現這個軟體可以套用State模式來管理被監控對象的狀態。當被監控的對象狀態發生異常時，可以套用Observer模式通知其他物件。在需求很明確的狀況下，可以直接套用設計模式而不至於產生過度設計的問題。
• 實作之後：有時候在設計階段套用design pattern的「作用力（force）」還不是很具體，只能先利用基本的物件導向設計方法來設計物件與分配責任。在實作幾個功能（use case或user story）之後才慢慢發現可以藉由重構方法來套用design pattern。
  

***

把套用design pattern的時機分成設計階段與實作之後看起來很簡單，但實際上這個過程還要再放到迭代與增量開發的流程中來討論。也就是說，每一個迭代（iteration）或衝刺（sprint）的每一個user story開發都包含了分析、設計、實作、測試等階段。在這種情況下，因為每個user story的範圍與大小相較於傳統use case或其他需求單位要來的小很多，所以相對來說比較不容易在專案初期的「設計階段」（還沒寫程式碼之前）就直接套用design pattern。換句話說，相較於傳統waterfall式的開發流程，在敏捷開發中先把程式寫完再重構成design pattern的機會可能比較多。

總之，需求如果已經很明確，要解決的問題也清楚，不需要先把自己變笨之後再將設計重構成design pattern。反之，先讓系統可以動，等需求明確之後再重構成design pattern也不遲。

***

友藏內心獨白：可以用就用，不能用就不要用。

讀學術論文有什麼用？

July 27 22:25~00:00

▲IEEE Software介紹，節錄自官網。

 

上禮拜某天有點空閒，看了幾篇刊登在今年IEEE Software雜誌的文章。看完之後挑了其中比較有趣的三篇連續三天在搞笑談軟工部落格上介紹，沒想到這三天部落格的平均點閱率成長100%以上，由此可見學術論文還是有不少鄉民有興趣（還是Teddy平常寫的文章太不好笑含金量又太低…Orz）。

念過碩士班的鄉民應該都有被指導教授要求讀學術論文的痛苦經驗，記得自己念碩士班剛開始讀論文的時候，先不說英文單字有很多都看不懂，就算是每個單字都查過字典，句子串起來也不知道在說什麼（論文的別名又叫做有字天書）。剛開始傻傻地以為只要一篇論文多讀幾次就會讀懂，殊不知除了英文障礙以外，更大的問題是缺乏該領域的背景知識（context）。

後來發現論文不是只讀你想讀的那一篇就好。每一篇論文都有參考資料，很多時候要去讀參考資料，累積背景知識增加理解能力之後，再回頭看論文就比較容易看懂。

***

相信大部分的研究生畢業後就不再閱讀學術論文，一方面是這些論文絕大部分需要付費，另一方面論文總給人「理論」、「不實用」的刻板印象。出社會之後，每天 抓寶可夢 加班都來不及了，哪還有時間去讀這些沒用的論文。

其實學術論文也是有分不同種類，有些是純理論，有些是偏實務類型。像是IEEE Software、IEEE Compute這兩本「雜誌」就屬於比較流行與偏實務的刊物，可以實際應用的機會很多。雖然現在很多資料在網路上都找得到，也有很多技術網站或部落格分享最新的技術，但對業界人士來說，讀學術文章（在此指軟體工程類的文章）還是有以下幾個用處：

• 正確性與完整性：想要了解某個新領域的最核心概念，例如DevOps、物聯網或大數據，如果可以找到刊登在學術期刊上的介紹性文章，通常可以獲得比較完整且正確的觀點。雖然網路上也充斥很多資訊，但這些資訊很可能不夠完整，更慘的是不小心看到詐神的文章，可能被錯誤觀念誤了一生。學術文章因為篇幅有限，所以必須用最精簡的敘述來說明，讓讀者可以快速了解重點。
• 實用性：軟工類的許多文章會分析比較業界多家公司的實務作法，或是分享自己公司（通常是大公司）的經驗。這些經驗可視為被驗證過的方法，實務上具有一定的參考價值。
• 前瞻性：很多學術文章都是研究計畫的產出物，像昨天介紹的〈What Makes an Architect Successful?〉就是研究計畫的結果發表之一（無論國內外，做完研究之後不發表論文好像對不起出資者，下次可能就不容易拿到案子XD）。因此學術論文大都具備一定程度的前瞻性，而這種能力「市面上」可能還不是很普及，能學到就是你的，可以增加自己和別人的區隔性。翻成白話文就是，增加自己解決問題的能力，藉此抬高自己的身價。
• 省時間：什麼，讀論文可以省時間？你沒看錯，真的可以省時間。撰寫論文的人至少花了幾百個小時做研究、實驗、寫論文，你只要花幾個小時就可以吸收日月精華（好啦，讀慢一點後面加一個零，10幾20個小時應該可以讀完），可以節省大量自我摸索的時間。記得去年參加了一場兩天的DevOps研討會，雖然聽到不少對於DevOps的「定義」介紹，也學到一些工具的使用細節（這點很不錯），但兩天下來（實際上是一天半，最後半天有事先離開）對於DevOps的「整體感覺」沒有比閱讀〈DevOps: Making It Easy to Do the Right Thing〉和〈DevOps〉來的完整。這兩篇論文相信一般人都可以在一天（8小時）內讀完。

***

讀論文也不是沒有缺點，首先你要找到「合適的論文」來讀，有時候這比閱讀論文本身還要花時間。其次，讀論文是一種主動學習模式，需要花「腦筋」，不是只要 躺著 坐著聽別人灌資訊到你的腦袋，過程比較辛苦。

網路上的資料，你讀，我讀，大家讀。暢銷書，你看，我看，大家看。證照，你有，我有，大家有。剩下論文，沒人關注。

要產生區別性其實沒有很難。

***

友藏內心獨白：寫了這篇點閱率又要下降了。

是什麼讓軟體架構師成功？

July 26 12:10~12:58  14:50~16:32

 

今天繼續介紹IEEE Software的文章，前兩天介紹DevOps，今天換個主題改談軟體架構。在今年1/2月的IEEE Software有一篇名為「What Makes an Architect Successful?」的文章，討論軟體架構師成功的因素。

***

什麼是軟體架構師

在討論軟體架構師（software architect）的成功因素之前，先定義什麼是軟體架構師。文章提到有研究人員幫軟體架構師定義了200種責任、100種技能，以及100種知識領域。這種「規格」太高，一般鄉民無福消受。文中採取《Software Architecture in Practice》一書的說法，先討論軟體架構的定義：「軟體架構是理解系統所需的結構，每個結構包含了元件、元件之間的關係，以及元件與關係的屬性。」

軟體架構橋接了系統商業目的與實作。架構師的主要責任就是確保實作出來的系統可以儘量達到功能與非功能需求。

***

軟體架構師的三種角色

依據不同的軟體生命週期，文中提出三種不同的軟體架構師角色：

• Initial designer（初始設計者）：專案初期從無到有設計系統架構，此時架構師的設計重點著重於如何滿足重要的功能與非功能需求，並且要確保系統架構的概念完整性（conceptual integrity）。架構師還需要考量所設計的架構最好可以和開發團隊的技能與經驗互相匹配、可以用增量方式開發，並且支持持續整合和持續交付。這個階段的架構師可能會參與實作，但其實作的主要目的在於製作雛型與驗證架構的可行性。

為了或得概念完整性，成功的Initial designer需要具備「大處著眼」以及良好的抽象能力。這種能力通常需要結合實務經驗與正規訓練。

• Extender（擴展者）：當系統上線之後，開發團隊還是經常需要撰寫新的功能或是與其他系統進行整合。此時架構師的責任就不是從無到有設計新的架構，而是需要了解現有系統並且尋求擴充與整合方案。因此，架構師需要實際動手操作系統程式碼以便或得第一手資訊。假使增加的新功能不在Initial designer的規劃中，Extender便可能需要犧牲原本系統架構的概念完整性以達到擴充新功能的目的。例如，在系統中加入特殊判斷條件以支援新功能。

Extender的成功則需要仰賴對於現有系統的深入理解、現有系統所使用的技術以及與它有關的週邊系統（例如資料庫、中介軟體、應用程式框架等）。相較於Initial designer從無到有做出設計需要很強的分析功力，Extender對於分析能力的要求比較少。

• Sustainer（維持者）：當系統已經上線好一陣子之後，架構師的角色轉變成Sustainer。此時系統還是持續提供服務但越來越難以維護與擴充。此時Sustainer的責任就變成在避免改變系統的前提之下，儘量將其的價值發揮到最大。例如，原本的系統只可以跑在Windows 98上。在微軟停止支援Windows 98之後，有沒有什麼辦法繼續幫系統「續命」，讓它持續提供服務。

Sustainer最重要的能力是溝通。他要說服有關人等系統依然可以提供價值，並說明要以何種方式持續利用系統的剩餘價值，如何以最小的代價繼續壓榨系統。Sustainer不需要提升自己的設計能力，而且通常只關注成熟或是以經過時的技術。

***

失敗模式

了解Initial designer、Extender與Sustainer這三種架構師角色與其責任和成功要素，作者最後提出三種失敗的架構師模式：

• Wrap-around：將一個成功的既存系統的Sustainer調到新專案中扮演Initial designer。這種狀況在業界很常見，因為既然Sustainer「最懂舊系統」，何不讓他擔任新系統的架構師呢？例如，將原本用VB撰寫的單機版程式改成Web-Based系統。雖然Sustainer很懂VB，但卻不懂Web-Base架構，所以很有可能無法勝任。
• Rising star：一個開發人員在系統上線之後成功扮演Extender角色，完成了幾個系統整合的功能。因為這些成功經驗公司決定讓他獨挑大樑，在新的案子中擔任Initial designer。但是這位開發人員出身的Extender很可能沒有受過正規的分析與設計訓練，例如沒學過物件導向分析與設計（OOAD）和軟體架構課程。在這種情況之下所設計出來的架構可以符合團隊的技能，但卻可能無法滿足重要的功能與非功能需求。
• Overprotective parent：一個Initial designer在系統上線之後持續擔任Extender，但是他不甘心原本設計的架構為了滿足新功能而必須在概念完整性上有所妥協。所以他採取昂貴、大規模修改的方式來擴充功能，因此導致系統無法快速交付新功能而被競爭者追過去。

***

以往談論軟體架構師，總是以「從無到有」的角度來看待這個角色，也就是文中所提到的Initial designer。但實際上在軟體生命週期的各個階段，還是需要架構師協助，只是在不同階段架構師所需要的技能與成功因素不同。忽略這些差異性往往會造成文末所提到的那三種架構師失敗模式，值得留意。

***

友藏內心獨白：人人都是架構師，有可能嗎？

DevOps技術簡介

July 25 22:05~00:00

▲DevOps基礎生產與佈署流程，參考文中論文重繪

 

今天介紹另一篇也是刊登在今年5/6月IEEE Software的文章，標題只有一個字：「DevOps」。這篇文章深入淺出介紹DevOps概念以及所牽涉到工具。

***

DevOps觀念

DevOps是關於如何快速且有彈性地開發與供裝（provisioning）商業流程的一門課題。DevOps有效率地整合開發、交付及維運，讓這些傳統上隔離的孤島可以精實且流暢的連結在一起。DevOps牽涉到開發、品管與維運部門。為了達成上述目的，DevOps運用自動化的方式在以下三個領域：

• 開發
• 佈署
• 基礎建設的監控

DevOps不是只有自動化工具的採用，而是組織結構與流程的改變，將傳統各行其事的部門串接起來組成跨職能團隊，以便持續提供客戶服務。

***

DevOps工具

該論文將DevOps依據階段不同分成三類：建構（Build）、佈署（Deployment）、維運（Operation）。再依據工具類型區分為建構（Build）、持續整合（Continuous integration）、配置管理（configuration managment）、日誌記錄（Logging）、監控（Monitoring）。請參考下圖：

▼DevOps自動化工具，參考文中論文重繪（CI: Continuous integration；CM: Configuration management）

***

其他

文章還提到幾個與DevOps相關的議題：

• 真實世界的DevOps：介紹Amazon Web Services（AWS）的幾個工具，包括AWS Elastic Beanstalk、AWS OpsWorks、AWS CloudFormation、AWS CodeDeploy、AWS CodePipeline、AWS CodeCommit、AWS CloudWatch。
• 微服務（ Microservices）：微服務出現在10年前，是服務導向設計（service-oriented architecture；SOA）的後續演化結果。微服務拆分複雜的軟體架構以達到隨選交付服務以及提升效能。DevOps可以協助開發、佈署與管理微服務容器生態系。
• 文化轉移：文中提到四種主要的挑戰：
  • 將複雜的軟體架構與功能集切分成可獨立開發與佈署的小區塊模組。
  • 維護一個配置與建構環境以便清楚了解佈署服務或元件的版本與相依性。
  • 引入一個從傳統應用程式生命週期管理所衍生的特意建構之開發與生產環境（這一點看不懂）。
  • 橋接傳統上各自為政的開發與維運文化。

此外，在DevOps文化中，開發人員必須採取全端開發策略（full-stack developer），負責開發、測試與釋出環境。除了coding以外，他們還必須擴展資料庫管理與測試等能力。測試與持續整合對開發團隊都是必須具備的工作，測試人員可以和開發人員一起結隊開發，雙便皆可因此獲取更多技術知識。品管團隊則需要確認自動化所有測試案例以及程式涵蓋率。維運人員則需要更緊密的與開發團隊協作，以達成持續提供服務的目的。

***

結論

最後直接引用論文結論中的兩句話：

• Building on lean and agile practices, DevOps means end-to-end automation in software development and delivery.
• Because products and life-cycle processes vary, each company needs its own approach to achieve DevOps, from architecture to tools to culture.

***

友藏內心獨白：最後一段麻煩自己英翻中。

DevOps：更容易做正確的事

July 22 22:50~00:00; July 25 09:50~11:15

 

▲圖片節錄自Google搜尋結果

 

今天介紹一篇刊登在5/6月IEEE Software 的文章：「DevOps: Making It Easy to Do the Right Thing」。文章主角是澳洲最大旅遊電商平台Wotif集團，旗下擁有Wotif.com和多個品牌（該集團在2014年底被Expedia收購）。在2013到2014年間，Wotif大幅整修他們的軟體釋出流程，將平均釋出時間從數週降低到數小時。文章介紹他們採用DevOps與持續交付（continuous delivery；CD）縮短釋出時間的經驗。

***

背景介紹

2012年時Wotif公司的工程部門有約170名員工，其中包含：

• 一個集中的營運團隊包含11位系統與資料庫管理員。
• 約60位開發人員。
• 30位測試人員。
• 15位業務分析師（business analyst）分佈在三個不同城市的12個開發團隊中。

以上人員約有20%（23人）不參與本篇文章所介紹的DevOps活動，也就是說實際牽涉人員約93人。

雖然工程部門的管理相當扁平，只有三個階層，但是他們的釋出流程卻非常的官僚。在產品釋出的前幾週就要先預定時間，但為了「夾帶」高優先權的功能，釋出的內容往往拖到最後一刻才決定。釋出流程並須經過層層關卡的檢查，例如所有釋出功能都要經過48小時的效能測試。

因為釋出流程很麻煩，團隊便想要塞進更多跨功能的異動到每次的釋出中以便減少釋出的次數，但卻因此造成每次釋出的內容變得很大一包，更增加釋出前的準備工作。如此一來團隊就很難滿足企業對於快速上市的需要，而且也沒時間去處理技術債。

為了解決這個問題，工程部門決定把延用了八年的Java EE架構改成微服務（microservices）。雖然在架構上他們覺得微服務有其優勢，但為了微服務卻引入更多的釋出工作因為他們必須要手動佈署與測試每一個微服務。結果原本的問題沒解決之前，還產生更多的問題。

因為導入微服務，不同部門所撰寫的微服務行為並沒有統一的規定，例如啟動服務的腳本、設定檔、管理端點、日誌檔的位置等等。這些問題又讓釋出的流程更加複雜，也造成維運團隊的困擾。

***

定義對的事

為了解決上述問題，Wotif成立一個CD團隊（持續交付團隊），包含兩個開發人員、一個系統管理師與一個流程改善業務分析師。該團隊採取一些策略來縮短釋出時間：

• 找出釋出流程的瓶頸，也就是只有11人的營運團隊。
• 藉由標準化應用程式包裝與佈署的機制來改善開發與釋出流程的一制性與可預測性
• 採用漸進式改變來擴充、精簡與自動化現有的基礎建設與工具。例如，繼續使用他們現有的資料中心，而不是把平台改成公有雲。

經過與開發團隊以及營運團隊的溝通，CD團隊整理了一份輕量級應用程式佈署標準，含蓋約30個規範，包含日誌檔位置與格式、初始化腳本位置與呼叫方法、配置檔位置、應用程式打包規範等。

***

簡化

CD團隊採取以下方法簡化開發與維運團隊實作上述標準的時間：

• 提供自動驗證測試套件（採用Fabric Python SSH函式庫開發），透過基本的Linux指令檢查每一個應用程式佈署之後，系統與程式是否正確。該驗證套件在開發人員每次提交程式碼時會在驗收測試環境中自動執行。
• 提供helloworld-service參考實作，該服務會被佈署到包含production的所有環境，用以展示與測試點到點（end-to-end）的佈署自動化過程。當Frbric Python版本升級時，它也做為自動驗收測試案例，確定此次版本升級沒有造成問題。helloworld-service也做範本，開發人員可以直接從它開始撰寫新的服務。
• 開發DevOps toolchain達成佈署與測試自動化。該DevOps toolchain包含Git、TeamCity、Yum、Hiera、Puppet，用Fabric Python將這些工具串起來，用以替代原本手動釋出的工作。為了測試服務的正確性，開發團隊需要針對每一個服務提供smoke test腳本。自動化佈署與測試完成之後，節省了85%的佈署時間，將原本需要幾個小時的時間縮短成幾分鐘。
• 要求服務必須獨立釋出。做到上述三點只解決各別服務佈署的問題，但是一個系統是由多個服務所構成，很有可能因為其中某一個服務升級，導致與其他服務發生不相容的問題。為了避免這個問題，所有的服務被要求必須要提供向下相容性，以便可以獨立釋出又不會影響到原本正常工作的其他相依服務。
• 訂定新的釋出流程，包含以下五項規則：
  • 讓異動獨立（keep changes independent）
  • 釋出過程不可以有人工測試
  • 不可以預約釋出時間
  • 應用程式必須符合最新的佈署標準
  • 維運人員可以將服務退回到之前的版本

在落實新的產品釋出流程之後，平均產品釋出時間從2週縮短到1天。

***

聽到DevOps許多人第一個印象就是找一堆工具來自動化測試與釋出流程，由這篇文章可以知道，工具與自動化只是其中一環。在自動化之前，必須找出流程上的瓶頸，接下來才能擬定改善計畫。如果流程沒有改變（改善），只是希望透過自動化工具加速錯誤流程的時間，就算是戴上DevOps這頂流行的帽子也不會讓你的團隊與產品看起來好棒棒。

怎麼找出瓶頸？最後置入性行銷，打個廣告：歡迎參加8月18日舉辦的「瓶頸遊戲：運用五步驟聚焦法持續改善流程」工作坊。

***

友藏內心獨白：要先do the right thing再do the thing right。

2016大阪姬路神戶考察之旅Day2-A岡山後樂園（上）

July 21 16:40~17:20

▼吃完Super Hotel早餐。

 

▼從JR新大阪驛搭8點左右的新幹線前往岡山。

▼約44分鐘後到達岡山。

 

▼岡山有兩個景點，岡山後樂園和岡山城。兩個景點相連在一起，岡山後樂園是岡山城的花園。從JR岡山驛先搭一小段有軌電車，下車後走個15分鐘左右可達。

 

▼徒步前往岡山後樂園，剛好遇到櫻花滿開，好幸運。

***

▼進入後樂園後看到一間賣霜淇淋的，還不錯吃。

 

▼古色古香的後樂園，占地頗大，不虧為日本三大名園。

 

▼園中還養了幾隻丹頂鶴。

***

友藏內心獨白：居然有丹頂鶴。