4.99人民幣的學習

June 01 12:48~13:28

▲James Coplien的DCI演講

最近Teddy對DCI（Data, Context, Interaction）架構很感興趣，花了點時間在研究它。相較於其他軟體架構，DCI算是非主流架構，網路上的資料也比較少，主要來自於James Coplien所寫的《Lean Architecture: for Agile Software Development》以及他的幾個演講（可在YouTube上用DCI搜尋）。

前幾天晚上Teddy找到一個張曉龍（中興通訊資深軟件架構師） 在ArchSummit深圳2019的中文演講，講題是〈當DDD遇上DCI〉，引起Teddy的興趣。該演講的錄影被放在中國的「極客時間」上當作一個課程販賣，人民幣4.99。

Teddy沒有微信也沒有淘寶支付，無法購買此課程。後來託Erica請他的中國朋友幫忙，好不容易才買到這個課程，差點上演4.99元逼死英雄好漢的戲碼 XD。

雖然Teddy對DCI研究還不深入，但聽完這個演講，看到演講分享的實作，感覺講者有點胡搞瞎搞。有幾個很明顯的問題：

• 亂用Context：DCI的C是Context，相當於Use Case，也就是Application Service，但講者卻想要用Context來進一步切割Aggregate，並且將C用DDD的Domain Service實作。這一點Teddy覺得有點「張飛打岳飛，打得滿天飛」的感覺。在講者所舉的例子中，除了造成不必要的人為設計複雜度以外（稍後說明），實在看不出什麼好處。
• 未透過領域事件解偶：講者開口閉口解耦合、提高內聚，但範例程式本身就把「轉帳」和「傳遞訊息到手機上面」這兩件事耦合在一起啊。在DDD裡面，這靠Domain Event去解耦合，但講者在拆分Aggregate的時候，不但方式很怪，也壓根沒提到Domain Event，彷彿Domain Event不存在一樣。
• 亂拆角色：講者對於Role（角色）的濫用與誤用到達一個讓人匪夷所思的境界，如圖1所示，講者以一個銀行轉帳的例子來說明他如何在DDD中套用DCI。他讓LocalAccount這個Aggregate Root扮演MoneyCollector, LocalMoneySrc, LocalMoneyDest, AccountInfo, Balance, Phone這五個角色。先不管這些角色的名字取的有多爛，Balance代表帳號餘額，光是Balance被獨立的一個角色這件事就非常詭異。其次，Phone這個角色存在的目的是為了轉帳成功之後通知使用者，為了具備通知的能力，一個LocalAccount需要去扮演Phone，這不是特別詭異嗎？LocalAccount去使用（use）Phone即可，為什麼要去扮演一支電話？難道你為了喝牛奶，需要扮演乳牛的角色嗎？
• 未反映真實事件：Teddy不是銀行這個領域的專家，但轉帳這件事，很明顯的不會只牽涉到來源帳號與目的帳號，至少中間還會有一個Bank的角色。講者號稱要使用DCI來幫助DDD切割Aggregate，但他切了一堆有的沒得角色，反倒是這個重要的Bank角色完全沒有被提到，這不是瞎忙一場嗎？

▲圖1：張曉龍在演講中所展示套用DCI之後的領域模型

***

正確示範

Teddy後來在〈An Empirical Study on Code Comprehension: Data Context Interaction Compared to Classical Object Oriented〉論文裡面看到一個比較像樣的DCI程式範例，如圖二所示。但這樣寫有沒有比較好，要再花時間想一下。

***

友藏內心獨白：胡搞瞎搞，勇氣可嘉。

領域驅動設計學習筆記（15）：領域專家缺貨

April 27 17:12~17:48

▲David West提到在1968年代，銀行的開發人員就是領域專家

不少朋友問Teddy一個問題：「Event Storming工作坊的時候如果領域專家不願意參加，或是勉強參加但卻都在擺爛，被動等著開發人員去問他問題，這樣該怎麼辦？」

這是一個很常見的問題，因為許多公司，特別是大公司，雖然嘴上說導入敏捷好幾年了，但骨子裡還是傳統瀑布是開發方法，客戶（業務單位）與開發人員還是透過中間人所產生的文件來溝通。這個中間人可能是Scrum裡面的Product Owner（PO），或是傳統的專案經理或是系統分析師/商業分析師。客戶（業務單位）認為開發軟體是開發人員的事情，能講的他們都已經講完了，這些開發人員不要三不五時就跑來煩他們，趕快把東西生出來。

另一方面，客戶（業務單位）理論上雖然代表著領域專家的角色，但這並不表示他們有能力和開發人員一起析分商業流程，甚至有些商業邏輯的細節連他們也不十分清楚。再加上客戶（業務單位）的人日常工作量已經很多，自己的事都忙不過來，很難要求他們長時間配合開發團隊持續進行Event Storming並精煉領域知識以及共通語言。

***

所以，如果你的開發團隊有願意一起長時間配合的領域專家，恭喜你你的現況離理想狀況比較接近。如果沒有，也不要灰心喪志，日子還是要過下去。

領域專家「缺貨」怎麼辦？如果真的調不到「貨」，只好讓自己變成領域專家。

幾天前Teddy聽了David West的〈 The Past and Future of Domain-Driven Design〉演講，講者提到在1968年代，銀行的開發人員就是領域專家。在【搞笑談軟工臉書社群】上，有兩位朋友也分享了類似的經驗。

所以，萬一開發專案中真的沒有領域專案，而案子也還是要做下去，考慮訓練自己成為領域專家。這樣做一定會花費比較多的時間，走更多的冤枉路，但總是能緩慢往前移動，總比留在原地一動也不動來的好。

就算團隊中有領域專家，開發人員也不能完全信任領域專家，自己還是要動腦思考，畢竟要將問題領域（problem domain）轉化成解法領域（solution domain）的人，是開發人員，不是領域專家，開發團隊還是要多擔待一些。

***

友藏內心獨白：一個人或是一個團隊的End-To-End，就可以變得很靈活。

領域驅動設計學習筆記（14）：透過合約讓領域模型與通用語言更精確

March 18 21:18~23:13

【圖1】ezKanban的design-level event storming（部分）

工商服務

自學好久的領域驅動設計（Domain-Driven Design；DDD）卻連一個完整的小功能都做不出來嗎？覺得DDD要學得東西太多，總是抓不到重點嗎？想要透過事件風暴（event storming）來塑模業務流程並找出bounded context與aggregate，卻不知如何下手嗎？

你需要真實世界的DDD + Event Storming + Clean Architecture 教學與範例，歡迎參加2021年4月2、3、4日（五、六、日）的【領域驅動設計與簡潔架構入門實作班】課程（已確定開課）。

***

前言

在〈用合約彌補測試案例的不足（上）：撰寫合約〉與〈用合約彌補測試案例的不足（下）：透過合約發現系統行為缺陷〉這兩篇文章中，Teddy談到依合約設計（Design By Contract）在ezKanban系統中的幾個實際應用案例，這一集Teddy要談如何透過撰寫合約找到領域模型與通用語言的行為漏洞。

***

問題敘述

幾天前Teddy去客戶家上DDD與Event Storming企業內訓課程，沒有和ezKanban團隊mobbing。今天mobbing的時候團隊問Teddy一個關於Aggregate行為的問題，請先參考圖1：

• Workflow與Card是兩個Aggregate，前者代表看板的工作流程，後者代表一項工作。
• Workflow包含垂直的工作階段—Stage，與水平的工作階段—SwimLane。
• 使用者新增Card之後，Card被放在Workflow的Stage或SwimLane裡面，使用者可以調整卡片的順序（order），該順序紀錄於Stage和SwimLane身上。
• 由於Workflow與Card分屬不同的Aggregate，因此當使用者移動卡片（Move Card）之後，Card必須通知Workflow卡片已經移動，以同步Workflow身上關於卡片位置與順序的狀態。

團隊遇到的情況是：他們在寫Card.move() 的前置條件（如圖2），原本希望除了檢查參數不是null，以及order >= 0 以外，還能夠檢查order不會大於該卡片所要加入的那個Stage/SwimLane的卡片總數。例如，使用者在To Do這個Stage加上一張卡片，To Do原本已經有2張卡片，move收到的order參數是8，則前置條件檢查失敗。團隊希望能在Card.move()的前置條件檢查這個限制。

【圖2】Card.move方法的前置條件

但是，因為一個Stage/SwimLane身上有多少張卡片的資料是儲存在Stage/SwimLane身上，Card並不知道，所以也就沒辦法在Card.move()方法加上這一條前置條件。

於是團隊問Teddy：「是不是應該把move方法移到Workflow上面，這樣就可以在前置條件中檢查Card的順序？」

***

思考邏輯

這個問題，可以從以下兩點來思考：

1. Single source of truth：Card與Workflow分屬不同的Aggregate，兩者之間透過領域事件達到狀態最終一致性。因此，第一個思考點就是：「關於一張卡片移動至哪個Stage/SwimLane這件事，擁有第一手資訊的人是誰？Workflow還是Card？」Teddy覺得應該是Card。
2. 關於檢查Card順序這件事，除了原本的Card.move()方法以外，另外一個地方就是Workflow.commitCardInLane這個方法，請參考圖3第270~271行，檢查了卡片的順序不能大於現有Stage/SwimLane裡面所擁有的卡片數量。

【圖3】Ｗorkflow.commitCardInLane()方法的前置條件

現在假設一個情況：

• 一張卡片要移到To Do上面的第8個位置。
• To Do身上只有2張卡片。

因此，圖3第270~271行的前置條件會失敗，丟出PreconditionViolationException並且終止程式執行，代表呼叫它的人有bug。呼叫commitCardInLane的人是誰？是CardMoved領域事件發生後的Policy，簡單來說就是Card有bug，這個bug很可能是前端傳過來錯誤的order。

***

如果不希望因為卡片順序有問題就終止整個系統執行，另一種可能性是放寬Workflow.commitCardInLane()的前置條件，把270~271行拿掉，改成在程式裏面（commitCardInLane的method body）判斷，如果條件不成立則丟出一個CardCommittedFailed領域事件，並通知Card執行交易補償（因為Card已經把它自己的狀態改成移動到新的To Do裡面，但Workflow判斷卡片所移動的順序是不合法的，所以請卡片移回它原本的位置）。

如果選擇這種作法，則原本圖1要再加上CardCommittedFailed領域事件，如圖4所示。

【圖4】讓領域事件以及Workflow Aggregate與Card Aggregate的行為更加完整。

***

結論

無論是選擇上述兩種方式的哪一種，系統的行為都因為撰寫合約而變得更精確。最後團隊與Teddy選擇了第二種方式--交易補償，因為這種行為模式容錯能力比較好。

看到這裡如果還沒跑開的鄉民，應該可以發現以下結論：

透過撰寫合約讓領域模型與通用語言更加完整。

***

友藏內心獨白：寫合約可以找到系統行為的漏洞。

用合約彌補測試案例的不足（下）：透過合約發現系統行為缺陷

March 10 14:28~16:05

【圖1】ezKanban領域模型（部分）

前情提要

上集〈用合約彌補測試案例的不足（上）：撰寫合約〉提到兩個撰寫合約的例子，今天介紹透過撰寫合約發現ezKanban系統bug的實際案例。

***

commitCardInLane的測試案例

在講解透過合約找到系統行為bug之前先介紹ezKanban的Board bounded context的部分領域模型，如圖1所示。圖1包含兩個Aggregate，Workflow與Card：

• Workflow是Aggregate Root，它包含多個Lane。
• Lane有兩種，垂直的叫做Stage，水平的稱為Swimlane。
• Card是Aggregate Root，它代表看板上面的一張卡片。Card放在某個Lane上面，兩者之間的關係用CommittedCard表示。

Ｗorkflow身上有一個commitCardInLane方法，表示某張卡片被放入某個Lane，其介面如下：

public void commitCardInLane(CardId cardId, LaneId laneId, int order, String userId)

• cardId：要放入的card Id
• laneId：要放在哪個lane上面的lane id
• order：順序
• userId：執行該操作的使用者 id

ezKanban採用TDD方式開發，針對commitCardInLane已經有一個測試案例如下：

【圖2】commitCardInLane的單元測試

由於workflow.commitCardInLane是一個很簡單的方法，它的實作類似以下兩行程式：

Lane lane = getLaneById(cardCommitted.getLaneId()).get();
lane.addCommittedCard(cardCommitted.getCardId(), cardCommitted.getOrder());

因為卡片實際上是放在lane上面，因此還需要幫lane.addCommittedCard寫一個測試，如圖3所示。

【圖3】這個測試案例規範一個行為—卡片的順序等於它被加入lane的順序。

寫完這兩個測試案例，感覺就差不多了，程式跑起來也都沒什麼問題。

***

commitCardInLane被疏忽的行為

再看一次圖4的commitCardInLane介面：

【圖4】commitCardInLane介面

當ezKanban團隊與Teddy幫commitCardInLen撰寫合約的時候，首先寫出以下幾個沒爭議precondition (前置條件)：

• car id is not null
• lane id is not null
• order >= 0
• user is is not null
• 要加入的那個lane必須存在

接著想到，既然卡片是要放到某個lane裡面，因此還需要一條：

• 要加入的card 不存在lane id所屬的那個lane裡面

上述precondition只規範了同一張卡片不能同時存在同一個lane裡面。寫完之後又想到另一個問題：「卡片可以同時存在不同的lane裡面嗎？」不行，一張卡片只能出現在一個lane裡面，所以剛剛那條precondition寫得不夠精確，要改成：

• 要加入的card 不存在所有的lane裡面

最後的precondition如下圖所示：

【圖5】commitCardInLane的preconditions

加上圖5的preconditions之後，就可以確保在這些前置條件滿足的情況之下，加入一張卡片之後，它就一定會依據正確的順序被放入正確的lane裡面。

最後，補寫一個單元測試用來確認剛剛最後一條前置條件所規範的行為，參考圖6。

【圖6】補寫測試案例來記錄由合約所發現的系統行為

***

討論

看到這裡，有經驗的鄉民可能會說：

從TDD/Specification by Example（實例化規格）的角度，「要加入的card 不存在所有的lane裡面」的這一個系統行為也是可以被找出來啊，只要在實例化規格的時候列舉出這個例子不就好了？根本不需要寫合約也可以發現。

這樣講「理論上」是沒錯的，但實際上：

• 在實例化規格「找例子」的時候，也是有優先順序之分。團隊通常會把與領域專家開會的寶貴時間拿來討論最重要的系統行為。像是commitCardInLane（把一張卡片放到lane裡面）這種有點重要又不是太重要的行為，能夠想出「卡片要成功放入lane」以及「卡片的順序要和放入的順序一致」這兩個例子，已經算及格了。在有限的時間與壓力之下，在想例子的當下不見得很容易就想到「一張卡片不能重複放在多個lane」這個例子。
• 寫合約就不一樣，因為人只要講到「簽訂合約」，立刻會從「君子模式」切換到「小人模式」。針對合約內容，能多挑剔就多挑剔，除了保護自己不要上當以外，還要幫自己取得最大利益。因此，光是從method介面，就很容易可以想出很多系統行為的「邊界條件」。

寫合約還有一個好處，它不需要像測試案例一樣，為了讓測試案例跑起來，需要：

• 準備測試資料
• 執行待測程式
• 比對測試資料

寫合約只需要……寫合約。就是用一段程式碼描述程式的行為即可，這段程式碼一開始甚至可以是空的，只需要有名稱即可。例如圖5的205行card_not_committed_to_any_lay()用來代表「一張卡片不能重複放在多個lane」的前置條件。先把合約的名稱（要描述的系統行為）想好，在撰寫合約的檢查內容即可。

***

工商服務

在套用領域驅動設計的時候，你的物件導向領域模型都生不出來嗎？針對領域模型的狀態正確性感到很棘手嗎？你想透過撰寫合約來增加領域模型的正確性嗎？

你需要補充基本的物件導向養分，歡迎參加2021年4月20日（週二）的【敏捷開發懶人包：物件導向技能】一日課程。

***

友藏內心獨白：合約就是用規格取代舉例。

用合約彌補測試案例的不足（上）：撰寫合約

March 09 23:05~March 10 00:55

工商服務

在套用領域驅動設計的時候，你的物件導向領域模型都生不出來嗎？針對領域模型的狀態正確性感到很棘手嗎？你想透過撰寫合約來增加領域模型的正確性嗎？

你需要補充基本的物件導向養分，歡迎參加2021年4月20日（二）的【敏捷開發懶人包：物件導向技能】課程。

***

前言

前一陣子Teddy與ezKanban團隊將ezKanban系統重構成能夠支援event sourcing，在重構的過程中，不免破壞了一些原本正常執行的測試案例。由於被影響的測試案例數量太多，雖然都是一些介面修改的小地方，但是數量一多還是很費工夫。

這個現象讓Teddy注意到原本的測試案例可讀性有點降低的趨勢，於是花了幾天重構測試案例。在這個過程中，Teddy發現雖然目前ezKanban系統一共有380個測試方法（test method），但還是有一些程式行為沒有涵蓋到。

另一方面，有些測試案例感覺又過於簡單，簡單到幾乎不會出錯，好像也沒什麼撰寫的必要，但是不寫又覺得心不安。例如，修改Board名稱的單元測試，最原始的程式碼就只有：

this.name = name;

簡單到不會出錯的程式就可以不用寫自動化測試，但是，因為採用領域驅動設計的方式開發ezKanban，所以除了this.name=name以外，還要發出BoardRenamed領域事件，這也增加了另一個需要測試它的動機。

因此，Teddy想到很多年前學過的Design By Contract（DBC；依合約設計），透過撰寫合約可以定義程式的行為，並在runtime自動驗證這些合約是否成立。若合約被違反，便代表程式有bug。合約撰寫越完整，可以大幅減少撰寫測試案例的數量。

這兩集Teddy要談在ezKanban中撰寫合約的方式，以及如何透過撰寫合約找到新的bug，之後再談如何簡化單元測試。

***

準備撰寫合約工具

合約有三種：precondition（前置條件）、postcondition（後置條件）、class invariant（類別不變量）。要在程式中撰寫合約需要程式語言支援。但可惜的是知名的商用程式語言除了Eiffel以外，Teddy就沒有聽過其他語言有內建支援合約。

退而求其次，如果有工具、框架支援，也是可以。但支援DBC的框架雖然有好幾個，但感覺都是實驗性質的成分比較多，而且很多都已經不再維護。

結論就是，離開Eiffel語言以外，先不要在其他程式語言追求完整的DBC支援。先求有，再求好。Teddy就是秉持這個精神，開始在ezKanban中撰寫合約。

一條合約就一個assertion，中文翻成斷言，也就是結果為真的敘述。講白了合約就是一個結果為true的if條件式。

例如，以下敘述都是assertion：

• Teddy是泰迪軟體創辦人
• 台灣中南部現在缺水
• Pascal是Teddy收編的貓
• 海水是鹹的
• 你走路的速度小於光速

所以只需要把一個if條件式包在代表precondition與postcondition的method裡面，就可以用最陽春的方式撰寫合約，如圖1所示。

【圖1】土炮撰寫合約的Contract類別

***

合約範例1

【圖2】Board類別的rename method

先看一個簡單的範例：幫Board類別的rename method寫合約，如圖2所示。因為ezKanban套用了event sourcing，54~59行代表發出BoardRenamed領域事件，真正設定board name = newName 的程式碼在另一個私有方法handleBoardRename身上，如圖3所示。

【圖3】BoardRenamed領域事件的處理程式

圖3是rename方法的實作細節，訂合約的時候不用去理會他，把焦點放在圖2，幫rename撰寫合約：

precondition:

requireNotNull("Board name cannot be null", newName);

postcondition:

ensure(format("Board name is '%s'", newName), getName().equals(newName));

這段合約表示：如果呼叫rename給定一個非null的字串newName（precondition的內容），則rename執行完畢後，Board name就會等於newName（postcondition的內容）。這也就是rename的語意。

看到這裡Teddy要請問一個問題：「Board name可否為空字串？！」

依據precondition，board name是可以接受空字串。如果你們的商業邏輯是規定board name不能是空的，就需要再加上一條precondition:

require("Board name cannot be empty", 

!newName.isEmpty());

***

合約範例2

最後看一個複雜一點的合約，Workflow類別的moveLane方法，如圖４所示。一個看板的Workflow（工作流程）可以有多個Lane，每個Lane代表一個工作步驟，它底下可以有多個sub lane。

【圖4】Workflow類別的moveLane方法

moveLane的：

precondition

• lane id不能是null
• new parent id不能是null
• order是正整數
• User id不能是null
• 要移動的lane必須存在workflow裡面
• 要移動的新位置(new parent)也必須存在workflow裡面
• 不能移動到自己身上，或是自己的子節點

postcondition

• lane的parent id等於new parent id（確定有移動到新的節點之下）
• lane的order等於new order (移動後的順序是對的)
• lane從原本的parent移除（確定lane已經不存在原本的parent，是移動而非複製）
• 新parent的子節點都已排序
• 舊parent的子節點都已排序

以上，如果合約訂得夠完整足以代表程式的行為，測試案例只要去呼叫這些method即可，不需要在測試案例裡面寫太多assertion，因為合約正確就代表程式行為正確。

但前提是，你的合約要寫對。因為合約也是程式碼，也可能會寫錯XD。

***

友藏內心獨白：既使沒有程式語言的支援，合約也是一種很棒的設計方法。

領域驅動設計學習筆記（17）：與外部系統的互動

Jan. 26 22:10~22:59

▲ezKanban使用者註冊範例

學員的問題

今天Teddy和ezKanban團隊mobbing的時候，有一位去年上【領域驅動設計與簡潔架構入門實作班】的學員突然傳訊息給Teddy。一開始對方說要詢問anti-corruption layer實作的問題，但依據Teddy多年的經驗，當有人覺得他的問題是A的時候，通常他的問題都不是A，而是X或Y或Z。

討論到後來對方給了Teddy一張從網路抓下來的圖如下：

▲圖1：學員用來詢問Teddy的例子，擷取自網路

對方將付款服務定義一個介面，放在application service layer（也就是clean architecture的use case layer）。他的問題是：

• 當付款成功之後，是否由application service 發出Paid Successfully領域事件？
• 如果是，但DDD不是提到領域事件是由Aggregate Root所發出，從application service發出領域事件OK嗎？

***

區分不同的視角

Teddy記得Martin Fowler在《UML Distilled》提到，一個class diagram有三個不同的視角（perspective）：

• Analysis
• Design
• Implementation

如果讀者把analysis class diagram當成implementation class diagram來解讀，一定會覺得圖中少了很多細節，甚至會誤解這張圖。

同樣道理，這位學員從網路上看到的event storming例子，頂多就是process level的圖，還沒到design level，所以直接用這張圖來推論實作，就可能會造成誤解。Teddy從design level的視角，將圖1重新繪製如圖2。

▲圖2：將圖1加上Aggregate，進入design level event storming

圖2有兩個Aggregate，因為還不知道要叫什麼名子，先用AA和BB代表。圖2的主流程如下：

1. 使用者執行付款（Pay，藍色便利貼）命令
2. 該命令送給AA（黃色便利貼）
3. AA與外部系統（粉紅色便利貼，此範例的外部付款系統為PayPal）溝通付款細節
4. 如果付款成功則產生Paid Successfully領域事件（橘色便利貼）
5. 該領域事件引發一條規則（紫色便利貼）—寄送付款成功的信件給使用者
6. 因而又觸發了寄送Email（Send Email）命令
7. 以此類推

根據以上分析，很顯然付款服務應該是一個domain service而非application service。AAA呼叫付款服務這個domain service，並依據付款的成功與否送出不同的領域事件。如此一來便回答了學員的問題。

***

友藏內心獨白：視角清楚，思慮也跟著清楚，答案就在不遠處。

愛上Mob Programming（下）

Jan. 21 18:22~19:50

▲喵星人也要一起mobbing

前言

乍看之下，mobbing是一種浪費，整個團隊一起開發卻只用一台電腦寫程式，感覺是把原本可以平行同時工作變成只能循序工作。今天Teddy從敏捷與精實開發的角度來看，為什麼值得做mobbing。

首先，所有的開發工作，不管是多少人一起開發，大致可以分成兩種工作模式：

• Component Development：開發人員專注於開發軟體系統的某個元件，例如，寫後端領域邏輯、設計資料庫schema與下SQL、寫前端JavaScript、寫CSS。這種模式底下開發人員所完成的工作並不能直接使用，需要經過另一個人整合之後，例如串起前後端，才會變成一個完整的功能。傳統的瀑布式開發，大多採用這種專業分工的模式。
• End-to-End Development：又稱為feature development，開發人員需要負責整個功能，也就是所謂的全端開發。全端開發工作並不限定一個人的全端，也可以是交由一個團隊來完成。例如Scrum團隊就是一個可以交付功能的跨職能團隊（全端團隊）。

***

單人開發

單人開發是一般人最熟悉的開發模式，又稱為Solo Programming。如果是採用component development的單人開發，所完成的工作並不能直接交付給使用者，也就是無法直接產生價值，還需要靠整合流程將所有的元件合併成可使用的功能。

從精實開發的角度來看，這種模式所完成的工作都是半成品（work in process/progress；WIP），做得越多，只是累積更多庫存，徒增浪費。

如果是feature development的單人開發，這個人就是所謂一條龍全端工程師，可以獨立產生價值。好的全端工程師非常難得，可以做到一個人的end-to-end。但人的能力總有侷限，有些全端工程師是屬於比較偏後端的全端工程師，有些則是前端比較強的全端工程師，也有那種前後端都不熟的全端工程師XD。

在這種情況下，全端工程師的產出，就受限於他自己最弱的一環。假設Teddy的後端能力有100分，前端能力只有20分，Teddy的總產能，不是 (100 + 20) / 2 = 60分，而是只有20分。這就是瓶頸，流程中生產力最弱的那個環節將會決定整個系統的輸出。

此外，單人開發還會造成維護的問題。如果這個人離職了，他所負責的程式通常連他自己都看不太懂了，更何況要找一個人來交接工作，難上加難，錯誤百出。

***

雙人編程

為了解決單人開發的問題，eXtreme Programming（XP）很早就鼓吹雙人編程或稱為結隊編程的pair programming。兩個人一起開發，一位扮演司機，另一位扮演領航員，兩人彼此互補，兩顆腦袋一起使用，可以減緩單人開發所遭遇到瓶頸的問題。假設採用feature development：

• 小明：後端能力90分，前端20分，系統產出20分。
• 小英：後端能力40分，前端60分，系統產出40分。

兩個人一起合作，整個系統的產出是60分。看到這邊你可能會覺得Teddy在莊孝維。小明、小英個別開發，20 + 40 也是 60分啊，而且搞不好個別開發速度更快。

但實際上，個別開發的速度，除了受限於每個人自身的能力，還受到很多因素影響。例如，專注力、解決bug的能力、當下看出設計問題的能力等等。一個人開發經常會陷入自己的盲點，導致被一些很簡單的「低級bug」給困住跑不出來，徒增很多試錯的時間。

雙人編程可以減少上述問題的發生，又可以自然產生一種良好的「備胎效益」—所有的程式碼至少有兩個人以上都有能力開發與維護，萬一人員異動也不至於整個停擺。

但雙人編程也會造成其他問題，例如如何搭配成員。把兩個菜鳥搭配在一起顯然無法減少瓶頸所造成的限制生產力問題，把兩個高手高高手安排在一起，可能大部分的時間都在吵架「華山論劍」，樂於忙著練功卻忘了實際的開發進度。

***

團隊編程

在mob programming的情況下，團隊成員每個人同時間都貢獻他自己最強的能力在同一件事情上面。例如團隊有五個人：

• 小明：UI/UX擔當。
• 小華：JavaScript高手。
• 小英：後端專家。
• 小龍：新人。
• 小陳：Product Owner（PO）。

在mobbing的情況下，這五個人一起開發。假設現在要開發ezKanban的使用者註冊功能，如下圖。

▲ezKanban使用者註冊流程

如果是跑Scrum，PO需要先寫好user story，然後在sprint planning meeting帶過來跟團隊解釋。此時團隊可能選擇估算每一個user story的大小，接著再將user story切成tasks。

Spring planning結束後，產出spring backlog並將其布置成task board。然後每天Daily Scrum的時候團隊在task board前面報告三件事並認領新的工作。Sprint結束後還有review與retrospective活動，

如果改用mobbing，因為整個團隊一起開發，所以也就不需要另外再開會。要開發註冊功能，就直接從event storming的圖中選出Register User這個使用案例，如果開發人員對需求有問題，例如：

• 要如何註冊？在ezScrum保存一份使用者註冊資料，還是結合Facebook、Google、Line的帳號即可？
• 要不要整合LDAP做到企業內部單一登入？
• 註冊畫面需要填寫那些資料？密碼的長度有限制嗎？

以往這些問題可能會在spring planning討論，如果沒有討論到，例如要不要支援LDAP，等到實作的時候，開發團隊就必須要再去詢問PO。但PO不一定可以立即被找到，因此就產生所謂等待浪費。也有可能開發人員自作主張，覺得應該要做到很有彈性，所以在沒有詢問PO的情況下自己加入支援LDAP的功能，導致過度設計，等review的時候才發現這個問題。過度設計，或過度生產，也是一種浪費。

在mobbing的情況下，有任何需求面的問題，當下就可以和PO討論，減少大量部必要的浪費。

在開發整個註冊功能的end-to-end過程中，有時候處理UI/UX、有時候處理後端、有時候處理前端、有時候釐清需求，團隊中每一個對該領域最擅長的人都可以貢獻自己全部的力量。當遇到自己不熟的領域，也可以從別人身上學習，逐步加強自己的能力。

至於新人，加入團隊當下就可以有貢獻。因為mobbing的時候大家輪流當司機（拿鍵盤與滑鼠的那個仁），就算自己不知道怎麼寫，導航員也會告訴你怎麼做。這種在工作中學習的模式，可以達到最快上手的目的。

***

單件流

Mobbing可以做到精實開發提到理想工廠單件流的效果，在生產線上，每個節拍時間就有一個工作在每個工作站中流動。不需要庫存，也沒有浪費（假設沒有缺陷XD）。Mobbing與生產線單件流的差別在於，mobbing是整個團隊跟著工作跑，當工作處於開發後端階段，整個團隊就開發後端；處於開發前端階段，就一起開發前端，只有一件工作在每個工作站流動。

Teddy以一個會寫程式的PO的角色，和ezKanban團隊mobbing近七個月，這段時間沒開過以往Scrum裡面的任何會議，但卻比以往任何時間更了解產品開發的進度與品質。

開發軟體，應該和打籃球、打橄欖球一樣，整個團隊同一時間一起在同一個球場打球。現在想一想，這不是再自然也不過的事嘛！

***

友藏內心獨白：用過就知道，說破嘴也沒用。