l

2018年3月19日 星期一

為什麼要寫自動化測試?

March 19 22:00~22:40

螢幕截圖 2018-03-19 22.04.10


問對問題很重要

最近兩個周日到台中上「單元測試這樣學就會了實作班」企業內訓,有學員問到:「如果工程師不寫測試怎麼辦?」這是一個經常被問到的問題,Teddy想從另一個角度來思考這個問題:「為什麼要寫自動化測試?

Teddy曾經聽過一種說法:「公司不是花錢請你來寫測試,是請你來解決問題。」言下之意就是寫自動化測試並不重要,寫程式解決問題才重要。某種角度來看,這樣說也沒錯。但如果順著這個邏輯推演下去,這句話是不是也可以改成:「公司不是花錢請你來寫程式,是請你來解決問題的。」所以開發人員也不用寫程式了,整天想著怎麼解決問題就好了?這樣聽起來好像有點怪怪的。

除非你是老闆的兒女或親戚,否則公司當然是花錢請員工來解決某種類型的問題。所以Teddy覺得這句話應該這樣看:「公司是花錢請你來解決問題,如果寫程式不寫測試可以解決問題,那就不寫測試。如果寫測試可以解決問題,那就寫測試。如果什麼都不做可以解決問題,那就每天裝忙就好」。

所以現在問題變成:「自動化測試可以解決什麼問題?

***

測試的兩種價值

螢幕截圖 2018-03-19 22.17.42

自動化測試提供公司與開發團隊兩種價值:

  1. 確保系統品質(出貨前系統沒有明顯的bug)
  2. 讓軟體變軟(團隊不懼怕修改系統並加速產品上市時間)

一般人,尤其是沒有開發經驗的管理階層或是涉世未深的開發人員,很可能只看到自動化測試的第一種價值。因此,在時程很 趕的時候,測試就變成可犧牲對象。就好像以前,為了聯考音樂課、體育課、美術課這些「聯考不考」的課程都可以被借去上國文、英文、數學一樣。反正退一萬步想,還是可以在出貨之後「請客戶幫我們測啊」。

因此測試變成可有可無,或是為了趕上時程而應該也可以被拿來省略的一道工序。

***

真正的專家知道,自動化測試的第2個價值才是改變團隊與產品的根本,也是公司競爭力很重要的一環。如果你的產品寫好之後不需要修改與維護,大可不需要自動化測試。例如,用完即丟的活動性軟體、接外包專案寫好後丟給客戶自己維護的系統、注定沒人用的系統,或是開發完之後你就準備離職的那種系統。

如果你的系統會被長期使用,而且很可能需要修改,省略測試所「賺到」的時間,很快就會「還回去」。正所謂「出來混,總有一天是要還的」。用比較正式的說法,累積技術債的利息已經太高,高到還不起的程度。

***

結論

在《Clean Architecture》書中,用「龜兔賽跑」的故事來說明「一開始看起來很快不一定最後是贏家」的道理。敏捷開發強調團隊需要有穩定的開發步調,而自動化測試就是一種讓團隊保持穩定開發步調的方式。

公司不是花錢請你(程式設計師)來寫測試,是花錢請你來解決問題,完全正確。因為你是專業人士,所以你知道什麼時候寫測試可以幫助公司解決問題,什麼時候欠點技術債可以獲得更好的投資報酬率。

***

友藏內心獨白:炒短線與長期投資的操作手法一定不同。

2018年3月15日 星期四

Clean Architecture(2):Port and Adapter Architecture

March 15 18:56~19:12;21:01~21:40

螢幕截圖 2018-03-15 18.58.07


一個架構各自表述?

今天在北科上軟體架構講到Port and Adapter Architecture(接口與轉接器架構),這個架構又稱為Hexagonal Architecture(六角形架構),是Clean Architecture的核心。關於該架構的介紹可以參考Alistair Cockburn寫的〈Hexagonal architecture〉。

上課前一周請同學先閱讀〈Hexagonal Architecture Is Powerful〉這篇文章,有同學發問:「為什麼有些網路上的文章把Port畫在六角形外面,有些則是把Adapter畫在外面?」(請參考下圖)

▼圖1:Port and Adapter的兩種不同畫法。

螢幕截圖 2018-03-15 17.39.22

這難道是一個架構各自表述?

***

畫圖的角度不同

參考圖2,不同的文章從不同的角度來畫Port & Adapter,畫出來的圖自然不同。如果是從客戶端的角度來看整個系統架構,客戶端先接觸到Port,然後Adapter再把客戶端傳來的資料轉成函數呼叫,執行Use Case所提供的功能。

▼圖2:從不同角度來看Port and Adapter

螢幕截圖 2018-03-15 17.41.18


如果是從Use Case的角度來看架構,則Use Case透過Port與外界溝通,當傳輸資料時,先把資料傳到Output Port (定義在Use Case中的Interface),然後Adapter實作這個Interface,再把資料轉給客戶端。接收資料時,客戶端透過Adapter把資料轉成Port所能接受的格式,然後傳給Use Case。

附帶說明,Adapter與通常Use Case執行於同一個記憶空間(屬於同一個Process、同一個Runtime Environment或同一個虛擬機器),轉接客戶端與Use Case之間的互動。

***

摻在一起做成撒尿牛丸啊

也有人把架構畫成圖3的樣子,感覺起來有點圖1左、右兩圖的合體,但清楚標示Port與Adapter的相對位置,應該是有比較清楚一些。

▼圖3:Port在最外層,Adapter介於Port與Use Case(圖中的Mediation)之間。

螢幕截圖 2018-03-15 17.41.54

鄉民們可以參考看看各種不同的畫法,以後看資料的時候也許比較不會搞混。

***

結論

嚴格來講,在《Clean Architecture》裡面,每跨一個階層邊界 (boundary)就會產生一組Input Port與Output Port,也就是說整個系統中,不同的邊界都有個別的Port and Adapter。這也是Port and Adapter的特色:「體架構可以透過好多組Port and Adapter 一直不斷地串接下去」。

類似下圖的概念。MacBook Pro的Thunderbolt 3的Port,配上HyperDrive這款Adapter,提供了好幾種不同的Port。而這些Port,又可以透過其他Adapter,繼續轉接下去。例如,HDMI轉VGA或USB Type-A轉乙太網路。


▼畫面節錄自https://goo.gl/xBU3zN

螢幕截圖 2018-03-15 18.09.17

***

友藏內心獨白:轉接器越來越多,越來越貴。

2018年3月1日 星期四

Clean Architecture(1):軟體架構的定義與目的

March 01 23:01~23:58

螢幕截圖 2018-03-01 23.57.25

▲佩納宮

定義

這學期開始在北科教軟體架構,使用《Clean Architecture》當作教科書,這一系列文章節錄Teddy認為的重點介紹給鄉民。

要談軟體架構,首先就要先知道軟體架構的定義。很多組織都有「架構」,例如公司組織架構、學校組織架構、政府組織架構,這些都是一般人類可以理解的架構。從這些架構著手,可以類推軟體架構的定義。

以中型公司組織架構為例,有董事會、董事長、董事會、總經理、處室、組等,以及各部門裡面的員工。由組織架構圖可以看出,所有的架構一定有三個東西:

  • 構成組織的單元:也就是不同職能的員工,在Clean Architecture中則稱為元件(component)。
  • 人員的安排:階層式、扁平式、矩陣式,component team還是feature team。在Clean Architecture中稱為元件的排列方式(arrangement)。
  • 人員溝通的方式:直接溝通、透過部門主管或PM與其他部門或外部客戶與廠商溝通、禁止溝通、聖上垂詢才可開口等。在Clean Architecture中稱為(communicate)。

Clean Architecture》的原文如下:

  • The architecture of a software is the shape given to that system by those who build it.
  • The form of that shape is in the division of the system into components, the arrangement of those components, and the ways in which those components communicate with each other.

軟體架構的定義很多,這可以算是Teddy看過最簡潔、清楚又實用的定義。

***

形狀與功能基本上無關

既然軟體架構是建構軟體的人所賦予它的形狀,那麼這個形狀的目的是什麼?假設你要蓋一個美術館,你會給這個美術館什麼形狀(外觀)?不少人可能聽過「Form follows Function」這個說法,形狀會跟隨著功能而改變,換句話說,軟體架構的形狀應該也會跟著功能(use case或user story)而改變。但實際在軟體架構領域中,一種廣為被接受的說法則是架構基本上與功能無關。實際上在真實世界中也是如此,下圖是用Google搜尋圖片下「美術館」關鍵字所找到的四個美術館,達到同樣的功能,但外型卻各異。


螢幕截圖 2018-03-01 23.36.23


那形狀的目的是什麼?依據《Clean Architecture》的說法,形狀的目的是為了幫助:

  • 開發(development)
  • 佈署(deployment)
  • 維運(operation)
  • 維護(maintenance )

換句話說,決定軟體架構的因素,主要是考量如何有助於軟體開發、佈署、上線營運以及日後的維護與功能擴充。

總的來說,軟體架構的終極目標可以簡化成以下兩點:

  • 最小化軟體生命周期的總成本
  • 最大化程式設計師的生產力

***

好的架構要反應功能

最後一個重要的觀念就是雖然架構的外觀與功能基本無關,但好的架構本身卻需要能夠反應系統的功能。《Clean Architecture》有個例子,你看到住宅的架構圖(平面圖),你會知道這個建築的用途是住宅,你看到圖書館的架構圖,你會知道這是一個圖書館。

回到軟體本身,試想一個Web購物網站應用系統,當開發人員打開程式,看到的是

tw.teddysoft.web

tw.teddysoft.controller

tw.teddysoft.domain

tw.teddysoft.database

類似這樣的架構組織關係,還是可以看出來系統有顯示產品列表、加入購物車、結帳、付款、選擇運送方式、追蹤訂單等功能?

為什麼好的架構要反應系統功能?因為這樣才可以協助開發、佈署、維運與維護。

***

友藏內心獨白:架構形狀與功能無關但架構內在要反應出系統功能。

2018年2月28日 星期三

軟體架構課程的準備

Feb. 28 23:24~23:59

螢幕截圖 2018-02-28 23.56.55


今天是2月最後一天,這整個月一篇部落格文章都沒寫,實在是有點不好意思。不過Teddy也沒閒著,因為這學期在北科大資工所兼任一門新的「軟體架構」課程,所以這幾個月花了大部分的時間與腦力在準備新課程。看了十幾本軟體架構的書,好不容易決定使用使用《Clean Architecture》當作教科書,接著又花時間用力地把書本內容看懂、吸收,想辦法用簡單易懂的方式講給學生聽。

這門課打算用一個小專案來反映Clean Architecture,光是專案要做什麼也想了一陣子。題目不能太大,因為這門課的重點不是coding,不需要也不應該花太多時間在撰寫過於複雜的軟體功能。但專案也不能太小,否則就無法表達Clean Architecture的Entity、Use Case、Controller、Gateway、Presenter以及串接Database、Web、UI等外部系統的架構。

想來想去想到以前研究過的一個開放原始碼監控軟體:Nagios,這個軟體有詳細的說明文件,Domain Model(領域模型)也很清楚,因此學生只需要專注在如何從軟體架構的角度,開發一個微小版的Nagios,然後把它的軟體架構採用Clean Architecture即可。


▼超簡化版的Nagios領域模型。

螢幕截圖 2018-02-28 19.47.31


***

Teddy會採用迭代與增量的方法,讓學生分組逐一把Clean Architecture的每個階層(Layer)都實作過,這樣子會比較有感覺,也不容易忘記,日後也可以直接在新專案中使用此架構。

為了驗證這個方法可行,這幾天Teddy都在寫程式,進度完成了Entity、Use Case、Controller、Gateway,剩下Presenter還沒接上去。俗話說,魔鬼藏在細節中,《Clean Architecture》這本書,光是用看的,就可以學到很多實務上非常有用的觀念。自己實作一次,則可以讓觀念變成實際解決問題的能力。


▼Teddy目前的專案進度

螢幕截圖 2018-02-28 23.52.00


在實作範例的過程中,發現之前研究的Domain-Driven Design(DDD)也可以與Clean Architecture相輔相成,不過DDD本身有點複雜,Teddy還要花點時間融合這兩者,等過一陣子弄得比較清楚之後再跟鄉民們報告。

活到這把年紀,要偷懶也沒人會罵你,靠教新的課程來督促自己重新學習也是挺好的一件事。


***

友藏內心獨白:突破關卡之後還滿有趣的說。

2018年1月8日 星期一

關西機場的持續改善

January 08 10:07~11:23

r1900074119sq1324ps

▲照片節錄自 https://kknews.cc/travel/22qnoz.html


去年(2017)12月Teddy到日本考察,由關西機場入境。出發前想起2016年4月賞櫻季節入境關西機場人山人海的情景,足足排隊等了快兩小時才完成入境手續,此行雖然並非賞櫻季節,但每年到日本的旅客越來越多,還是有點擔心冗長的入境等待時間影響到後續行程安排。

到達關西機場,人潮比起賞櫻季節少很多。隊伍前方排了很多韓國人,跟著排隊人龍慢慢往前移動,來到接近入境審查關卡之前,動線突然轉個彎,隊伍被引導到一個新的關卡,類似下圖所示。


▼圖片節錄自〈日本3機場祭科技新法寶 旅客審查時間「縮短33%」〉,原圖節錄自日本法務省

日本入境省查


新關卡由好幾台如下圖所示的指紋掃描與拍照機器所組成的「陣列」。一組設備有六台機器,三位操作人員,當天現場有2~3組這樣的機器。每組機器就好像有三個核心支援hyper-threading的CPU,同時間可以處理六位旅客的指紋掃描與拍照工作。


▼圖片節錄自〈日本關西機場啟用信息採集車縮短入境審查時間〉,原圖取自日本共同社

ro8000p46949r9q7011


原本入境日本是不需要指紋掃描與拍照,但因為防恐的原因在約10年所增加的手續。這些工作,本來由入境審查面試官負責,因此拉長了入境審查的時間。根據新聞報導,把指紋掃描與拍照切割出來獨立成另一關卡,有效減少33%的入境審查時間。實際上,Teddy覺得節省的時間可能不只33%,因為有些旅客,尤其是上了年紀第一次到日本的旅客,不太清楚指紋掃描與拍照的流程,所以經常出現面試官需要重複告知與重試的情況,更拉長了入境審查的時間。

***

順利入境之後,Teddy趕到關西機場二樓的JR綠色窗口準備換JR Pass順便畫位。以往這是另一個大排長龍的地方,這次發現JR綠色窗口也做了流程改善。首先,櫃台人員直接說中文,減少與旅客溝通的時間。其次,以往可以在櫃台畫多個車次指定席的座位,現在改成只能畫一次指定席,其他車次請到其他JR車站畫位。乍聽之下好像變得不方便,但其實畫位是很花時間的動作,櫃台人員畫位之後還要重複與旅客確認。藉由限制旅可一次只可畫一個車次的座位,可以加速服務旅客的時間,舒緩排隊久候的問題

***

離開關西機場,Teddy想到這不就是敏捷開發所說的把大的user story切成小的user story,或是五步驟聚焦法(請參考〈目標:簡單有效的常識管理〉、〈利用五步驟聚焦法改善你的看板團隊〉)所提到的「非瓶頸階段配合瓶頸」的改善方法嗎?

持續改善就是沒有最好,只有更好的心態。

相關相聞:

***

友藏內心獨白:好多事情可學習。

2018年1月5日 星期五

【敏捷小酒館】第八夜:如何學好設計模式?

December 05 17:00~

image

▲練習看看上面這段程式中有那些forces沒有被平衡?


Erica找Teddy一月份到台中【敏捷小酒館】分享,原本想把「達摩祖師」拿出來重複使用,介紹導致軟體社群開始使用Patterns的歷史緣由,以及Patterns的起源—《The Timeless Way of Building》這本武功祕笈的最高心法。

但Erica覺得Teddy第一次來【敏捷小酒館】就下這麼猛的藥,怕鄉民們一下子承受不住,所以準備另一個比較通俗且具體的題目:【敏捷小酒館】第八夜:如何學好設計模式?


▼達摩祖師此次無緣上場XD(畫面節錄自電影達摩祖師傳)

image

***

GoF的《Design Patterns》設計模式這本書已經出版22年,多年來設計模式廣泛地應用在軟體開發的所有活動,從需求、分析、設計、實作、測試到流程,都有模式可遵循。

對許多開發人員而言,學習模式就好像背英文單字一樣,並不是一件輕鬆且容易駕馭的活動。就算好不容易學會某些模式,也經常發生誤用模式過度設計的問題。

實務上使用模式還有另一個問題,就是團隊中只有你自己會沒有用,要其他團隊成員也要懂、願意使用才能發揮模式的效果。Teddy聽過好幾個類似的情況:公司同事出差,某人把該同事原本寫的程式改成套用設計模式,結果同事回來之後就森七七了。「我的程式可以正常執行你沒事幹嘛亂改?你改成這樣這麼複雜反而看不懂,我以後要怎麼維護。」

最後,同事還是把程式碼改回原本的寫法,徹底落實小瑛總統所說的「維持現狀」

***

Teddy在本次敏捷小酒館將分享學習設計模式的經驗,希望可以減少鄉民們學習設計模式的門檻,並且可以知道何時該用,何時不該用設計模式。

迷之音:桌上的核武按鈕不可以隨便按。

***

友藏內心獨白:下次再恭請達摩祖師上場。

2017年12月31日 星期日

2017葡萄牙與西班牙考察之旅Day4-C葡式蛋塔創始店 & 發現者紀念碑

December 24 14:14~14:42

▼貝倫區地圖,景點都還滿集中的。

螢幕截圖 2017-12-24 14.23.00


▼離開熱羅尼莫斯修道院在路旁看到很多人在排隊,那家店就是葡式蛋塔創始店。從馬路上看起來好像排隊人龍很長,但這些都是外帶的人,店內空間很大,往內走稍待一下就會有位置。

Screenshot - 2017_12_24 , 下午 2_16_32Screenshot - 2017_12_24 , 下午 2_16_13


▼蛋塔味道不錯,咖啡也很好喝。

Screenshot - 2017_12_24 , 下午 2_15_27Screenshot - 2017_12_24 , 下午 2_15_40

Screenshot - 2017_12_24 , 下午 2_15_45Screenshot - 2017_12_24 , 下午 2_15_49Screenshot - 2017_12_24 , 下午 2_15_54Screenshot - 2017_12_24 , 下午 2_15_59Screenshot - 2017_12_24 , 下午 2_16_09Screenshot - 2017_12_24 , 下午 2_16_37

***

▼吃完蛋塔喝完咖啡往發現者紀念碑前進,會先經過公園與帝國廣場。

Screenshot - 2017_12_24 , 下午 2_25_57

Screenshot - 2017_12_24 , 下午 2_25_16Screenshot - 2017_12_24 , 下午 2_25_25Screenshot - 2017_12_24 , 下午 2_25_36Screenshot - 2017_12_24 , 下午 2_25_41Screenshot - 2017_12_24 , 下午 2_25_46Screenshot - 2017_12_24 , 下午 2_26_21


▼一群小朋友聚集在冰淇淋小販前面。

Screenshot - 2017_12_24 , 下午 2_26_12


▼發現者紀念碑,外牆刻有葡萄亞大航海時代有功人員的雕像。

Screenshot - 2017_12_24 , 下午 2_32_54Screenshot - 2017_12_24 , 下午 2_30_06


▼買門票搭電梯上去頂樓欣賞風景。

Screenshot - 2017_12_24 , 下午 2_28_11


▼360度視野絕佳。

Screenshot - 2017_12_24 , 下午 2_28_45Screenshot - 2017_12_24 , 下午 2_28_30Screenshot - 2017_12_24 , 下午 2_31_38Screenshot - 2017_12_24 , 下午 2_31_42

Screenshot - 2017_12_24 , 下午 2_28_07Screenshot - 2017_12_24 , 下午 2_28_22Screenshot - 2017_12_24 , 下午 2_28_25Screenshot - 2017_12_24 , 下午 2_28_41Screenshot - 2017_12_24 , 下午 2_28_55Screenshot - 2017_12_24 , 下午 2_29_05


▼遠眺貝倫塔。

Screenshot - 2017_12_24 , 下午 2_28_59

***

友藏內心獨白:淡水河口是不是也可以蓋個什麼塔。