l

2022年8月5日 星期五

套房還是雅房?

August 05 01:09~02:47

截圖 2022-08-05 上午1.22.57

▲圖1:標準版的ezKanban支援四種報表

 

前言

在外租屋的朋友,如果只租一間房間,一般而言有兩種選擇:套房或是雅房。套房是包含衛浴設備的房間,雅房則沒有專屬的衛浴設備,需要和其他人共用衛浴設備。前者組金比較高,後者比較便宜。

你喜歡套房還是雅房?

如果經濟許可,當然是有專屬衛浴設備的套房比較方便。

但是,從軟體開發的角度來看,軟體開發人員應該更喜歡雅房才對啊!為什麼? 因為這樣大家才可以共用(reuse)衛浴設備。每一個房間都裝一套衛浴設備,是一種duplicated code,這是一種程式開發的怪味道(bad smells),要加以去除才對。

但是,共用就不能獨立自主啦。如果你要洗澡的時候,別人正在洗澡,你就要等待。上一個上完廁所的人衛生習慣不好,沒有沖馬桶,你上廁所的時候就要幫前一個人善後。

所以,要不要共用,不是只有一個「是否會產生duplicated code」這個因素(force),還有其他條件需要考慮。今天Teddy講一個在ezKanban裡面關於共用與去除duplicated code的故事。

***

標準看板報表

如圖1所示,在ezKanban中,支援以下四種報表:

  • Lead Time Distribution Chart(交期分布圖),由GetLeadTimeDistributionChartUseCase負責產生,它透過LeadTimeDistributionChartProjection介面跟資料庫要資料。
  • Control Chart(控制圖),由GetControlChartUseCase負責產生,它透過ControlChartProjection介面跟資料庫要資料。
  • Cumulative Flow Diagram(累積流量圖),由GetCfdUseCase負責產生,它透過CfdProjection介面跟資料庫要資料。。
  • Due Date Performance Chart(到期日績效圖),由GetDueDatePerformanceChartUseCase負責產生,它透過DueDatePerformanceProjection介面跟資料庫要資料。。

因為ezKanban同時支援State Sourcing與Event Sourcing這兩種不同的資料儲存方式,上述因此每一個產生報表的使用案例所使用的Projection介面,各自有兩種實作。State Sourcing的實作使用PostgreSQL資料庫,Event Sourcing的實作使用EventStoreDB資料庫。也就是說,四個報表有八種不同的實作。

***

 

看板遊戲報表

2021年7月,ezKanban團隊基於原本標準看板的領域模型加以擴充,開發看板桌遊,如圖2所示。看板桌遊支援標準版的三種報表(Lead Time Distribution Chart、Control Chart、Cumulative Flow Diagram),另外增加看板桌遊專屬的Financial Report(財務報表)。

 

截圖 2022-08-05 上午1.36.06

▲圖2:ezKanban的桌遊模組所支援的四種報表

 

雖然看板桌遊的前三種報表和標準版的程式邏輯很像,但是有少部分不同。例如對於日期的處理,在標準版中報表的日期是領域事件產生的真實時間,但在看板遊戲中,報表的日期是遊戲中的日期,不是真實世界的時間。例如,圖3是看板遊戲的累積流量圖,X軸的時間分別是Day 8, Day 9到Day 18,這是遊戲設計的時間。圖4則是標準版的累積流量圖,X軸顯示的是真實世界的時間。兩個報表可以透過儲存在資料庫中相同的領域事件資料而產生,但關於時間的處理以及報表呈現的方式則略有不同。

 

截圖 2022-08-04 下午6.15.51

▲圖3:看板遊戲的累積流量圖

 

截圖 2022-08-05 上午1.47.27

▲圖4:ezKanban標準版的累積流量圖

 

ezKanban團隊一開始實作看板遊戲的前三張報表是直接複製標準版的程式碼,加以修改成看板桌遊的報表。因此又增加三個看板桌遊報表的使用案例,以及六支Projection的實作程式。

***

去除重複的程式碼

一開始直接複製原本標準版的程式加以修改,團隊很快就寫好看板桌遊的報表。寫完之後團隊也沒有打算要修改它,因為看板桌遊的需求並不會改變,所以雖然有重複的程式碼,對整個軟體持續開發活動並不會有什麼特別的影響。有一天團隊將開發看板桌遊的經驗整理成論文,寫到處理報表問題的地方,突然覺得:「既然報表邏輯大部分的一樣,是不是可以重構一下,拿掉重複的程式嗎?」

當然可以啊,從寫出Clean Code的角度來看,去除重複性是很基本的要求,於是團隊便安排時間重構這些產生報表的程式。

怎麼重構?首先最大的問題就是看板遊戲的報表顯示的是遊戲中的虛擬時間,因此團隊一開始採用注入一個TimeConverService的作法來轉換時間。如果是標準版的看板,就注入一個NullTimeConverService,如果是看板桌遊的報表,則注入KanbanGameTimeConverService。

但後來ezKanban也重構的「向資料庫要資料」的設計,一開始採用將查詢資料的method寫在一個ReportRepository裡面。後來覺得這樣做不好,因為ReportRepository的介面太肥大,違反了介面分離原則(Interface Segregation Principle)。此外,因為ezKanban也套用了CQRS,在查詢端套用Repository設計模式,容易和命令端套用Repository設計模式產生混淆。因此團隊把查詢端的Repository改為Projection,然後讓一個Projection身上只有一個query method,只負責一種查詢條件(等於套用了GoF的Command設計模式)。

改用Projection之後,為了解決看板桌遊處理時間的問題,團隊又在Projection設計上套了Decorator設計模式,透過KanbanGameDecorator來轉換領域事件的時間。

故事還沒完,除了原本針對State Sourcing與Event Sourcing各有一個Projection的實作,這裡面也有重複的程式碼。從產生報表的角度來看,原本Projection的設計耦合了以下兩種責任:

  • 責任1:從State Sourcing資料庫或是Event Sourcing資料庫找資料的責任。
  • 責任2:找到資料資料(找出的資料是一堆領域事件),利用這些領域事件產生相對應的報表。

不管是State Sourcing或是Event Sourcing,產生報表的邏輯(責任2)都是一樣的,因此團隊又針對責任1設計一個ProjectionPeer介面,讓責任2的程式碼只要在Projection中維持一份即可。至於每一個Projection要到PostgreSQL資料庫或是EventStoreDB撈資料,只要注入不同的ProjectionPeer實作即可。在這裡,等於又套了Adapter設計模式

 

***

值得嗎?

整個重構過程,套了好幾個設計模式,完全去除了重複程式碼,也達到程式碼重用的目的,同時還滿足領域驅動設計、CQRS、Clean Architecture,真的好棒棒啊。

如果真的這麼棒,Teddy就不用寫這一篇文章了。

雖然報表重構的過程還沒結束,但也到了尾聲的階段。回顧整個過程,Teddy學習到一件很重要的事:

針對Write Model的重複程式碼,值得花時間透過重構加以去除。至於Read Model的重複程式碼,除非寫完之後有經常需要修改的可能性,否則重複就重複吧。

***

ezKanban是為了研究與學習而開發的軟體,因此才會設計成「同時支援State Sourcing與Event Sourcing」。因為這個需求,才導致操作資料庫的程式碼出現duplicated code的問題。這個問題,在一般「正常專案」應該是不會出現,因為沒有人吃飽沒事讓自己的商用軟體同時支援不同的儲存方式。

ezKanban為了這個需求,導致整個資料庫存取層的設計變得複雜許多。在一般情況下,在Write Model中,一個Aggregate對應到一個Repository介面;而該介面通常也只需要一個實作,因此不會有duplicated code。在Query Model中,一個查詢對應到一個Projection介面;同樣地,該介面也只需要一個實作,也不會有duplicated code。

所以整個結論就是:

程式碼重用和去除重複性,要看Context來決定。如果鄉民們的專案不需要跟ezKanban一樣同時支援State Sourcing與Event Sourcing(絕大部分應該都屬於這種情況),在資料庫存取層可以用更簡單、更直接的設計就好。

***

友藏內心獨白:套用設計模式的第一個原則就是,不套模式能不能解決問題?