為什麼要寫自動化測試？

March 19 22:00~22:40

問對問題很重要

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

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

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

所以現在問題變成：「自動化測試可以解決什麼問題？」

***

測試的兩種價值

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

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

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

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

***

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

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

***

結論

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

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

***

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

Clean Architecture（2）：Port and Adapter Architecture

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

一個架構各自表述?

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

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

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

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

***

畫圖的角度不同

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

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

如果是從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）之間。

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

***

結論

嚴格來講，在《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

***

友藏內心獨白：轉接器越來越多，越來越貴。

Clean Architecture（1）：軟體架構的定義與目的

March 01 23:01~23:58

▲佩納宮

定義

這學期開始在北科教軟體架構，使用《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搜尋圖片下「美術館」關鍵字所找到的四個美術館，達到同樣的功能，但外型卻各異。

那形狀的目的是什麼？依據《Clean Architecture》的說法，形狀的目的是為了幫助：

• 開發（development）
• 佈署（deployment）
• 維運（operation）
• 維護（maintenance ）

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

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

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

***

好的架構要反應功能

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

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

tw.teddysoft.web

tw.teddysoft.controller

tw.teddysoft.domain

tw.teddysoft.database

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

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

***

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