五倍直播間

Blogs - Sidebar

Image Credit: [Freepik](https://www.freepik.com/free-photo/change-word-wooden-background_4973642.htm)

在八月份的開發者對話主題是「Domain-Driven Design（領域驅動開發，以下簡稱 DDD）」算是最近很常被提到的關鍵字，雖然還在學習相關的知識，不過我們還是藉由活動一貫的問答方式跟大家一步步深入討論不少相關的問題。

## 前提

因為我認為「戰略（設計）」是 DDD 最為重要的部分，大部分的文章也都會提醒這點，雖然很快的都會接入到「戰術（實作）」的部分，也因此我們大多數人都是從戰術來理解 DDD 的，我也不例外，這篇文章的討論也會以此為前提。

> 我認為很多討論都要建立在有「領域專家」的協助才能夠成立，像是我們該如何判斷當下的邊界（Bounded Context）來劃分出領域（Domain）和子領域（Sub-Domain）等等，因此在討論戰術時我們都會先給一個假設

## 規模

因為是從「公司想導入 DDD 在 Rails 使用但覺得奇怪」作為起始，我先拋出「DDD 是為了解決怎樣的問題」來進行分析。

以我的了解來看 DDD 的很多案例都是 Java 或 .NET 為前提，這些都是企業級的系統在使用的，然而在 Rails 中更多被新創公司所採用，即使有像是 GitHub、Shopify 這樣的成功案例，也不代表他們使用 DDD 來解決問題。

> 假設一個系統非常簡單，我們真的需要用 DDD 去處理嗎？

## 特性

接下來我們針對「奇怪」這件事情分析，當我們將以其他語言作為範例的「戰術」應用到 Rails 裡面時，無視語言特性的話，會出現格格不入的狀況。

舉例來說，當我們沒有 Interface（介面）的概念時，如何處理像是 Repository 實作的問題。同時 ActiveRecord 提供了 ORM 機制，也跟 Domain Layer 中的 Entity、Repository 設計互相衝突的。

剛好我前陣子在一篇討論 DDD 的文章看到了 DHH 的在 Twitter 上的討論，相比在 Rails 使用 DDD 而是更偏向 DCI（Data, Context and Interation） 的方式，然而這並不代表 DDD 無法被應用在 Rails 之中，而是我們需要理解 Rails 框架跟 Ruby 語言兩者的特性。

> 在維基百科的 [DCI]([https:/](https://zh.wikipedia.org/zh-tw/%E6%95%B0%E6%8D%AE%E3%80%81%E5%9C%BA%E6%99%AF%E5%92%8C%E4%BA%A4%E4%BA%92)/) 條目也提到屬於一種 MVC 的補充，以 Rails 來說確實更加適合。然而 .NET MVC 也能夠使用 DDD 這也表示在符合某些條件下，我們還是能夠在 Rails 中使用 DDD 的設計。

## 借鑑

在了解 DDD 的過程中，我認為對 Rails 工程師來說需要了解的是 DDD 想傳達的精神，以及在戰術應用的方式。

最廣為人知的就是分層架構，在學習過程中我也發現跟 Clean Architecture 有相似之處，而且分層架構我們也能很順利的在 Rails 找到對應的角色，雖然界線不一定那麼明顯，但還是有跡可循。

| 層級|分析| 
| -------- | -------- | 
| Presentation Layer（表現層）| View 類型，Rails 原生就支援輸出不同格式| 
| Application Layer（應用層））| 在 Clean Architecture 也叫 Use Cases 基本上就是 Controller 的 Action（動作）| 
| Domain Layer（領域層）| 基本上就是 Model 的部分，因為直接涵蓋所有 Domain Object 類型，也因此過去有 Fat Model 的說法，實際上很多衍伸的物件也是由此細分| 
| Infrastructure Layer（基礎層）| 基本上就是 Rails 框架本身提供的，像是 ActiveRecord 提供了跟資料庫的連線等等| 

上面是很粗略的區分，然而我們還是能觀察到 DDD 的分層架構基本上就是對一個應用的分析，我們在實作上不一定要完全侷限教科書、網路文章的方式，而是根據語言、框架順勢實作。

## 解析

基於上面的「借鑑」我們再稍微深入的分析幾個觀念，來幫助大家在使用上可以不要被範例侷限住，而是去思考背後的意義。

## 流程

因為 Application Layer 的實作基本上上就是 User Flow（使用者流程）或者稱為 Use Case（使用案例）因此我們要注意的是不要把「邏輯」放在裡面。

就我認為，所謂的流程就是「完成一件事情」的步驟，以「結帳」來說我們會到櫃檯檢查商品、統計金額、從錢包拿出對應的金錢。

除非發生例外，不然是不會中斷的，因此我在 Controller 裡面開始避免使使用 if 來做檢查，因為預期外的事情是例外（Exception）是會中斷流程的。

> Rails 有提供 rescue_from 來協助我們在 Controller 處理例外，因此使用例外來中斷「流程」是沒問題的。

## 邏輯

我們也可以用「商業邏輯」來表示，裡面就會包含了「判斷」這件事情，延續流程的結帳流程，我們在過程中就會有需要「檢查錢包金額足夠」的動作。

既然 Domain Layer 被用來集中整個商業邏輯，在原本的 Rails 中我們統一由 Model 來掌管這些事情，最後變得過大而難以維護，也因此發展出了 Concern 這類特性。

除此之外，經常被 Rails 教學提到的 Service Object 其實很明顯的就應該是 Domain Service 裡面封裝了數個處理特定流程的「邏輯」來對應這些情況，很多時候我們會發現每個專案的用法都不太一樣，主要就是因為我們沒有意識到這件事情。

> 我們可以延伸思考，在 Rails 中 Repository、Entity 跑去哪裡，要怎樣才能夠在不影響整個框架設計的前提下，引入這些概念。

## 順勢

最近在思考該怎麼把程式寫好時，發現了一個很重要的觀念就是「順勢」每個語言、框架都有他的特性、擅長的部分，除非我們在設計新的特性，不然應該要思考作者在設計時的想法，順著這個方式去實踐。

雖然前面我們提到 DHH 對 Rails 框架的認知是偏向 DCI 的，然而 DHH 所在的 37signals 這間公司，在他們的 E-Mail 產品 Hey 中還是有使用到 [Domain Driven](https://world.hey.com/jorge/code-i-like-i-domain-driven-boldness-71456476) 的概念，但從文章的例子來說對 Rails 確實是非常自然的。

## 範例

這篇文章是我在 Facebook 的貼文的延伸，[範例程式碼](https://gist.github.com/elct9620/84f1c94726064b4be942f3f5b6cbf06a)可以參考一下前面我所瞭解到的戰術應用，在 Rails 中應該是怎樣的。

透過提煉 DDD 的概念，我希望在我的 Rails 專案中能達到這幾件事情。

## 可讀的

一段好的程式應該要讓所有人都能輕鬆理解，因此基於 User Flow 的區隔可以清楚描述「行為意圖」當我們需要知道更多細節時，就可以往下了解商業邏輯。這也跟我們在學習一個新的領域的知識接近，先看整理後再去了解每個環節的細節。

## 內聚的

因為 DDD 提倡的是充血模型，而這個想法跟原本 Rails 提倡的 Fat Model 基本上都是類似的，如果是一個 Entity 那麼所有改變自身狀態的行為都應該被聚合在這個 Entity 之中，Rails 的 Model 其實也有這樣的性質在。

簡單來說，在設計物件的時候從商業邏輯的角度思考，將相關的邏輯整合在一起，這樣也能夠讓我們從流程深入探索到邏輯時，能夠更快速的理解，而不需要花時間在不同物件之間來回尋找。

## 可測試的

因為今年（2022）上了 Odd-e 的 LeSS 敏捷課程，讓我重新了解到敏捷開發的好處，其中一個環節就是 E2E Testing 的優點，這點在 DDD 的可測試性上也有很大的好處。

我們使用 E2E Testing 就是為了確認使用者可以正常使用，幾乎就是 Happy Path 的情況，其實就是對 Application Layer 的流程進行測試。

當我們確認使用者在正常情況下可以使用後，就可以縮小範圍到單元測試（Unit Test）針對 Domain Layer 的物件小範圍的檢查不同的情境，進而打造一個更容易擴充的系統。

## 探索

因為 DDD 是「設計」層級的問題，其實是很難透過一篇文章就解釋清楚，除此之外也需要花時間不斷的實踐跟驗證，才能找到適合 Rails 的應用方式。

所以，該停下來把 Java / .NET 的 DDD 戰術應用在你的 Rails DDD 戰術上，從「了解 Rails」開始，只要我們朝著正確的測試、重構前進，最終還是會得到跟 DDD 類似的架構。

最後，我跟朋友正在開發一款遊戲，也被我用來驗證敏捷開發、DDD 的可行性，有興趣的話可以觀看我每週一的直播 - [Build Game in Rails](https://www.youtube.com/playlist?list=PLnY6meQl8ifGFjqrU5Q1no5fGi-_u0abG) 也歡迎提出問題，一起討論在 Rails 實踐上的問題。

> 本文引用自弦而時習之的[在 Rails 導入 Domain-Driven Design 是解藥還是毒藥](https://blog.aotoki.me/posts/2022/09/16/use-ddd-in-rails-is-antidote-or-poison/?fbclid=IwAR0KZxDlheMSh2KlAuoGmgs0eqMZAyUYyJJ_t2Hht2jIbliSUqxuPw2ZnRU)
>
> 如果你喜歡這篇文章，想要更深入了解技術，我們有開設蒼時弦也的 📒 「[開發必學的需求分析法](https://5xruby.tw/courses/system-and-requirement-analysis)」以及「[Rails 開發者的進階實戰](https://5xruby.tw/courses/rails-foundation-skills)」課程唷 ❤️️ 歡迎報名！

在 Rails 導入 Domain-Driven Design 是解藥還是毒藥

Image Credit: [standret on Freepik](https://www.freepik.com/free-photo/double-exposure-caucasian-man-virtual-reality-vr-headset-is-presumably-gamer-hacker-cracking-code-into-secure-network-server-with-lines-code_10139053.htm)

之前在查資料時，在 Twitter 上看到 DHH 對 DCI (Data Context Interaction) 的[看法](https://twitter.com/dhh/status/280738513522155521)同時上週的[我對 Domain-Driven Design 的理解（2022 年）](/posts/my-understand-of-domain-driven-design/)這篇文章也提到了 DDD 跟 DCI 不互斥，而且能夠改善某些設計上的問題。

## MVC 的限制

現今大多數的網路服務都是基於 Model-View-Controller 這樣的架構下去設計的，同時框架本身提供了 ORM（Object–relational mapping）的機制，也因此我們會很直覺的認為資料表跟模型（Model）物件是一個直接的映射關係。

也因此，在使用像是 Rails 這類框架時，我們大多會像這樣使用。

```ruby
class WalletController < ApplicationController
  # ...
  def deposit
    @wallet = current_user.wallets.find_by(currency: params[:currency])
    @wallet.balance += params[:amount].to_d
    @wallet.save

    redirect_to @wallet
  end
end
```

單就這段程式碼來看，其實沒有什麼大問題，不過有經驗的人其實很清楚現實狀況非常複雜，因此不太可能這麼單純。

## DCI 的目的

簡單來說 DCI 是針對 MVC 的補充，用來更清晰的釐清當下的情境，也因此是一個關於資料（Data）在怎樣的情境（Context）能做出怎樣的互動（Interaction）的使用場景。

我們回到上一個段落的 `deposit`（儲值）的情境來看，整個情境是這樣的：

- Data - 某個貨幣的錢包餘額
- Context - 儲值的狀況
- Interaction - 儲值

把他們跟 MVC 關聯起來，則會是：

- Data - `Wallet` Model 的資料
- Context - `Wallet` Controller
- Interaction - `deposit` 的處理

在這裡會發現一個有點「奇怪」的狀況，那就是我們的情境為什麼是 `Wallet` 呢？是不是應該有個 `DepositContext` 來處理比較合理？

就這件事情來看，我認爲沒有「正確」的答案，假設 Wallet 相關的處理都很單純，那麼我們直接把他視為一個 Context 來看待是完全沒有問題的，或者說理想上能保持這樣的狀態我們的應用會更單純。

如果過於複雜，以往我們會拆分 Service Object 來解決，就這點來說也沒有問題，因為他可以是 Domain Service 而且 Service 的層級上來說比 Context 還小一點的。

## 還能做什麼？

照上面的解說來看，我們似乎沒有事情可以做了？這樣子 DCI 的用意在哪裡，當我們使用 MVC 的時候不就已經符合條件了嗎？

我們回到前面仔細觀察這兩行，就會發現似乎有哪裡不對勁：

```ruby
@wallet.balance += params[:amount].to_d
@wallet.save
```

在這兩行裡面，我們並沒有描述「互動」是怎樣的，也就是說這個 Wallet 物件的互動是直接把 balance 屬性拿出來修改，並沒有給定「互動」的定義。

因此，更合理的方式應該是

```ruby
@wallet.deposit(params[:amount].to_d)
```

我們需要明確的描述這個物件「能做的事情」也就是 `#deposit` 方法，也因此這個 DCI 的敘述是「有一個 Wallet 在處理 Wallet 的情況下可以被儲值（Deposit）」進而構成了對情境的完整敘述，那麼我們在 Ruby 最常使用的 BDD（行為驅動，Behavior-Driven Development）測試框架 RSpec 就能夠自然的「對應」這件事情。

```ruby
RSpec.describe WalletController, type: :controller do
  describe 'POST /deposit' do
    # ...
    context 'when currency is USD' do
      # ...
      it { expect { deposit }.to change(wallet, :balance) }
      it { is_expected.to redirect_to wallet_path(wallet) }
    end
  end
end
```

像這樣子，我們可以用 `describe` 描述一個場景，接下來就可以針對這個情境用 context 給予不同的資訊，來驗證這個場景下所發生的各種事情，進而很自然的就能將 Controller 和測試對應起來。

## Concern 與角色

當我們將大量的方法集中到一個 Model 上，構成充血模型（Rich Model）後就面臨了另一個問題——物件過於巨大難以管理，這也是以往 Rails 提倡 Fat Model 後面臨的問題，也因此才會有許多專案選擇用 Service Object 來抽離這些邏輯。

然而，一個物件的狀態（或稱屬性）應該要由物件本身自己來管理，也就是所謂的「高內聚」的狀態，當我們將一部分的行為抽離出來後反而讓這個狀態流失，甚至要為了維持狀態操作正常，而將一些本應該是私有的行為曝露出來。

然而在 Ruby 語言本身就具備了 Mixin（混和）的性質，在這樣的前提下 Rails 採用了 Concern（相關）的機制來解決這個問題。

假設我們的模型中有數種類似 `Wallet` 而且可以被「儲值」的情況，我們就可以將它獨立成一個模組。

```ruby
module CanDeposit
  extend ActiveSupport::Concern

  included do
    # DSL ...
  end

  def deposit(amount)
    self.balance += amount
  end
end

class Wallet
  include CanDeposit
end

class Account
  include CanDeposit
end
```

如此一來，我們利用了 Mixin 的特性將「可以儲值」的性質混合到數種不同的物件上，在 DCI 的觀點中，有一些文章會用角色（Role）來描述這樣的關係，在這個例子中我們就是賦予了 `Wallet` 和 `Account` 具備「儲值對象」這一個角色，並且給予了 `deposit`（儲值）這一個互動選項。

那麼回到我們在 Rails 負責的 Context 的 Controller 上，這段程式具備的意涵就完全不同。

```ruby
class WalletController < ApplicationController
  # ...
  def deposit
    @wallet = current_user.wallets.find_by(currency: params[:currency])
    @wallet.deposit(params[:amount].to_d)
    @wallet.save

    redirect_to @wallet
  end
end
```

我們可以明確的知道在「Wallet 的情境下要進行 deposit 時，會有一個 Wallet 的資料參與（扮演 CanDeposit 的角色）因此可以對其執行 deposit 的操作」

如果我們還想更近一步，加入 DDD 在建模上以「領域（Domain）」為基礎的方式實作，讓整個場景更佳「完善」則可以加入像是 Value Object（值物件）的實作來更近一步的描述現實世界的情境。

```ruby
class WalletController < ApplicationController
  # ...
  def deposit
    @amount = Money.from_cents(params[:amount], params[:currency])
    @wallet = Wallet.from_user(current_user).find_by(currency: @amount.currency)
    @wallet.deposit(@amount)
    @wallet.save

    redirect_to @wallet
  end
end
```

樣我們就可以明確地表達出這個情境中的資訊有金錢的單位、幣種（`Money.from_cents`）以及錢包（`Wallet.from_user.find_by`）互動是儲值（`deposit`）等等資訊，就自然而然的構成了一個不需要註解也能清晰描述情境的實作。

> Rails 的 Concern 機制是方便使用 Rails 的 DSL 所設計，假設沒有需要使用 DSL 的話並不一定要加入 extend ActiveSupport::Concern 在內。

> 本文引用自弦而時習之的[自然地在 Rails 中應用 Data Context Interaction](https://blog.aotoki.me/posts/2022/10/28/use-data-context-interaction-natively-in-rails/)
> 
> 如果你喜歡這篇文章，想要更深入了解技術，我們有開設蒼時弦也的 📒 「[開發必學的需求分析法](https://5xruby.tw/courses/system-and-requirement-analysis)」以及「[Rails 開發者的進階實戰](https://5xruby.tw/courses/rails-foundation-skills)」課程唷 ❤️️ 歡迎報名！

自然地在 Rails 中應用 Data Context Interaction

Image Credit: [ArthurHidden on Freepik](https://www.freepik.com/free-photo/close-up-man-writing-code-laptop_7621112.htm)

因為把 Domain-Driven Design: The First 15 years 看完後腦中有了非常多想法，為了不要太快把這些東西忘記，只能盡快寫成文章記錄下來。

簡單來說，我認為 Domain-Driven Design 是一種「觀念」而不是理論或者實踐，他更接近於將「模型（Model）」的概念帶入到程式設計中，也因此在書中提到 Domain-Driven Design 是沒有嚴格規定，只有接近跟遠離核心的差異。

## 建構模型

實作一個軟體的方式很多，而 Domain-Driven Design 的一切討論是基於模型（Model）的概念，也就是我們該如何把「現實世界存在的資訊轉換為程式」並且讓程式來幫我們處理這些問題，這也讓像是 Value Object（值物件）跟 Entity（實體）這樣的概念在實作中被界定出來，因為我們需要找出一些跟現實世界的關聯性。

然而，這件事情其實是受到程式語言、領域上的影響。以最近很熱門的人工智慧領域來看，機器學習（Machine Learning）建構「模型」的方式是利用大量訓練資料來建構，而 Domain-Driven Design 則是透過觀察、分析來決定。

這都會影響到我們最後怎麼去實作、定義，以書中其中一個章節的 F# 範例來看，在 F# 中可以做到這樣的事情。

```fsharp
type EmailOnly = Email of string
type AddressOnly = Address of string
type BothMethods = {
  EmailOnly: EmailOnly,
  AddressOnly: AddressOnly
}

type ContactInfo =
  | EmailOnly
  | AddressOnly
  | BothMethods
```

像這樣很直覺的就可以建造出只有 Email 或 Address 或者兩者同時存在的情況，並且「其中一個符合」的定義出來，相比其他語言更加直觀。

## 觀察世界

既然要對真實世界進行「建模（Modeling）」那麼我們就需要對世界進行觀察，而 Event Storming（事件風暴）是其中一種手段，如果我們有更好的方式，並不一定要採用這個方法，然而大多數時候這個方法更加容易。

Event Storming 的觀察方式是將現實世界以時間順序為基礎，以「事件」作為節點來描述一件事情，並且最終會停在某個事件作為結束，有點類似大眾所知的量子力學「在觀察之前不會知道結果，最終會得到一個結果」的感覺，我們透過描述被觀測到的結果來檢查在這個領域中會出現的情況。

接下來進一步的將觀察的資訊詳細描述，加入參與者（Actor）、觸發事件的行為（Command）、影響結果的因素（Data or Read Model）、造成事件的機制（System）、事件產生的影響（Policy）來完善這個模型，讓我們得以從中找出 Value Object、Entity 這類在實作上所需的線索，以及對整個領域中造成影響的範圍建構概念，進而得到 Bounded Context（界限上下文）

> 這個過程也是建構 Ubiquitous Language（共通與言）的好時機，因為所有人都在用自己的方式描述這個模型，大量溝通的過程中就會逐步地將在特定「語言」完善，有點類似第一個翻譯語言的人，雙方用各自的語言描述相同的事物的感覺

## 與模型互動

當我們能夠將現實世界的事物以一個模型來描述時，我們還需要搭建一個可以跟這些模型互動的環境，也因此 Layered Architecture（層級式架構）這類方案就被使用在這之中，用來建構一個可以跟模型互動的環境。

以 Layered Architecture 為例子，Presentation Layer（表現層）劃分出了使用者對這個模型的觀察，可能是顏色、狀態等等。而 Application Layer（應用層）則描述了如何跟模型互動的方式，至於 Infrastructure Layer（基礎層）就負責提供實現這個模型的基底。

## 模型玩具的例子

我們用「迴力車」來作為例子，以 Event Storming 的角度來看，我們會觀察到「車子往前」這樣的事件，並解加入操作者（小孩）、往後拉（最多只能 3 公分）、因為彈簧驅動車子向前等等資訊。

如果將其轉換成 Domain Model 我們可以先從「資料（Data）」的方式轉換成有意義的「資訊（Infromation）」那麼會先得到一個「能量」的資訊來表示向後拉的數值，同時「最多只能 3 公分」會被定義在這之中，因為這個「能量」僅限於這個領域。

```ruby
class Power
  include Comparable

  # 描述 Domain Knowledge
  MAX_VALUE = 3
  MIN_VALUE = 0

  attr_reader :value

  def initialize(value = 0)
    @value = value
  end

  def ==(other)
    @value == other.value
  end

  def +(power)
    charged_value = [value + power.value, MAX_VALUE].min
    constrained_value = [MIN_VALUE, charged_value].max

    Power.new(constrained_value)
  end
end
```

接下來 Value Object 就可以繼續組成 Entity 來表示一個「模型」的基礎單位，並且具備了改變自身狀態的行為能力「蓄力（Charge）」和「前進（Run）」

```ruby
class Car
  # 對 Domain Modle 們來說只認識有意義的 Value Object 而不是 Data
  NO_POWER = Power.new(0)
  STEP_POWER_USAGE = Power.new(1)

  attr_reader :id, :power

  def initialize(id:, power: NO_POWER)
    @id = id
    @power = power
  end

  def charge(power)
    @power += power
  end

  def run
    @power -= STEP_POWER_USAGE
  end
end
```

根據領域的複雜程度，我們的 Entity 可能是一個更大模型的一個零件，還會有 Aggregate（聚合）以及多個模型要互動時需要的 Service（服務）

然而，我們只有「領域模型（Domain Model）」是不足以讓使用者使用，因此在基於架構方面的理論，建構出一個足以使用的環境。

```ruby
class RunCarService
  def run(car)
    return until car.power == Car::NO_POWER

    car.run
    puts "The car is running..."
  end
end

class CarController
  def play(input)
    # ToyBox 是 Repository 用於表示「玩具」的集合
    car = ToyBox.find_a_card("Aotoki's blue car")
    # Ruby 的 Hash 是天然的 DTO 因此沒有另外實作 ChargeInput
    power = Power.new(input[:value])

    # Application Layer 以描述行爲的「步驟」為主
    car.charge(power)
    run_car_service.run(car)
  end
end
```

在 `CardController` 我們可以看到能夠使用一種叫做 `#play` 的方法來讓這台車動起來，並且只需要提供「能量的數值」

> 為了控制篇幅這邊稍微簡化到只保留 Application Layer 的部分

然而，我們仍在上面的例子看到一些不太合理的地方，像是該如何解釋 Input/Output 的來源以及去向、該如何構成一個「行為」以及操作者的角色是誰等等，也因此像是 Clean Architecture 或者 DCI（Data Context Interaction）等等不同理論也被提出或者加入到 Domain-Driven Design 的討論中，用以改善這些不完善的部分。

> Domain-Driven Design: The First 15 Years 中有提到 Eric Evans 認為當初寫下的藍皮書（Domain-Driven Design 原作）是不夠完善的，也因此在 Domain-Driven Design: The First 15 Years 這本書中有很多「解釋」跟「批判」和「補充」類型的章節，持續的去完善整個體系。

## 已知與未知

從 Event Storming 或者建模的過程中，不難看出來整個實踐是基於「已知」的前提去進行的，也因此「領域專家（Domain Expert）」就變得非常重要，因為我們需要在過程中盡可能的提取知識，來確保整個模型的建構是足夠完善的。

這也是爭議的一部分，也就是會有人認為「花太多時間」或者「過度設計」的狀況存在，雖然在 Domain-Driven Design: The First 15 Years 中有參考了敏捷開發（或極限編程）的概念，但也是有些人選擇「融入」有些人選擇「否定」這樣的方式。

然而，模型在 Domain-Driven Design 中也是會逐漸改變的，至少現實世界中的「模型」也會隨著技術發展、使用者的變化（長大）有些許的轉變，因此我在這件事情上的觀點更傾向於「情境」本身決定實踐方式。

舉例來說，我們已經是一個成熟的「企業」那麼利用 Event Storming 來了解原有的系統並且界定出界限上下文、子領域，是非常合理的情境。另一方面，在 Domain-Driven Design 被提出的時期，也差不多是敏捷開發開始逐漸成熟的時期，某方面來說敏捷開發是對應了對「未知」探索的方法，也因此原本 Domain-Driven Design 用來處理「已知」的方法可能就不太適合。

以我今年最喜歡的 Acceptance Test Driven Development（驗收測試驅動開發，A-TDD）作為例子，以由上而下的方式逐漸探索一個系統，實際上也足以打造一個可用的軟體，跟 Event Storming 的觀察方式剛好完全相法，一個是「黑箱」的方式觀察，另一個則是「白箱」的方式觀察。

實際上，在「建模」這件事情上可能是沒有差異太大，需要專注的是 Domain（領域）的邊界跟劃分以及減少造成昂貴修改成本的情況，從敏捷開發的角度勢必會有一段時間是單體的（Monolithic），直到我們將邊界探索完畢。

## 開放心態

整體觀察下來，其實 Domain-Driven Design 對我來說更接近是一種觀念，或者說「Model-based（以模型為基礎）」的程式設計的實踐方式，同時整個社群的目標也不外乎是思考「如何建立適合的模型」並且以此為目標努力。

基於這樣的理由，假設有一天 Top-down（自上而下）的探索方式能夠提供「對未知探索」的建模足夠完善的解決方案，也許會被寫在新出版的書中。又或者像是 DCI 這個針對 MVC 的補充，在 15 年後被加入到書中用來呈現在怎樣的情況下，可以去補足原本 Domain-Driven Desing 的不足。

之前在發文時也有人提到「基本教義派」這樣的存在，不過也很難去界定說怎樣是「基本教義派」的定義，不過 Domain-Driven Design 的邊界隨時都在變化的狀況下，我想「基本教義派」其實就是那些在心中建立一個「固定範圍」的人們，所以我們才會覺得他們的建議「過時」跟「不合理」因為沒有隨著整個領域一起「進步」

最後，我會選擇把 Domain-Driven Design 的理論忘掉，或者說「精煉」出來。一方面是我專注的領域更多是 Startup（新創）類型的專案，因此「已知」的探索幫助並不大，同時我主要使用的是 Rails 框架，不論是 Ruby 語言或者 Rails 框架對於現有的 Domain-Driven Design 架構都是不夠契合的，即使 Rails 框架其實隱含了非常多 Domain-Driven Design 的概念，這也就表示需要去「探索」適合用在 Rails 框架的方法，而不是在已知的方法中想辦法「套用」

當然，我很喜歡 Domain-Driven Design 帶給我很多觀念上的衝擊，以及解答非常多實作上遇到的疑惑，因此我還是會持續關注、探索，直到有一天我確定我專注的開發技巧可以被稱為 Domain-Driven Design 或者無法。

> 本文引用自弦而時習之的 [我對 Domain-Driven Design 的理解](https://blog.aotoki.me/posts/2022/10/21/my-understand-of-domain-driven-design/)
> 
> 如果你喜歡這篇文章，想要更深入了解技術，我們有開設蒼時弦也的 📒 「[開發必學的需求分析法](https://5xruby.tw/courses/system-and-requirement-analysis)」以及「[Rails 開發者的進階實戰](https://5xruby.tw/courses/rails-foundation-skills)」課程唷 ❤️️ 歡迎報名！

我對 Domain-Driven Design 的理解

Image Credit: [snowing on Freepik](https://www.freepik.com/free-photo/young-adult-business-man-typing-using-laptop-office_1203140.htm)

在遊戲開發中寫測試一直以來都是被認為相當困難的一件事情，雖然有很多人嘗試，但我們仍沒有找到一個很好的方法解決。

同時，寫測試對許多人來說是一種拖慢開發速度的工作，這次我在每年都會參加 Global Game Jam 中挑戰用 48 小時的時間開發，運用這段時間學到的 Domain-Driven Design（領域驅動設計）、Clean Architecture（清楚架構）、敏捷開發、ATDD（驗收測試驅動開發）等技巧來做實驗。

- 遊戲：<https://ggj2023.aotoki.cloud/>（可能要等一下）
- 原始碼：<https://github.com/elct9620/GlobalGameJam2023>

## 時間與取捨

黑客松最為困難的地方在於有限的時間，因此有經驗的開發者大多會選擇盡全力的限定開發的範圍與排序實作的優先順序，這也是「敏捷開發」的核心精神之一，我們需要捨去無法交付價值的功能，專注在最重要的地方。

過去的經驗中，像是大學的畢業專題（3D 動作遊戲）、工作跟客戶的互動，其實都會遇到這樣的狀況，也經常因為無法取捨而讓最後無法交付完善的成果。不過這次抽到的隊友不論是美術、遊戲企劃、音效都對這件事情有共識，因此我們能集中力氣在完成一款「可以玩」的成品。

> 實際上主辦單位每年都會提醒大家，再加上每組都會有幾位有經驗的參加者，通常都會很好引導隊友做出能夠交出作品的決策。

## 設計與規格

影響後續開發最關鍵的其實是（架構）設計跟規格這兩塊，這一次受限於工具的狀態（我們沒有使用遊戲引擎，也來不及準備企劃能做的自動測試）因此沒有在規格上過多著墨，然而因為遊戲大多會專攻一個機制以及進行事前的討論，因此大多數時候還是相對明確的。

至於架構設計在有多位工程師的團隊中，就扮演非常重要的角色。因為團隊的另一位工程師是跟我一起工作多年的同事（[西瓜](https://pastleo.me/)）因此還是相當有默契，同時選用我們都熟悉的 JavaScript 來開發，以 [PIXI.js](https://pixijs.com/) 為基底，用 [Inversify.js](https://inversify.io/) 和 [RxJS](https://rxjs.dev/) 搭配來進行實作，另外也順便嘗試了 Vite。

最後的版本大致上是這樣，這是我結束後重新整理的版本，不過前期開發也是以這個為基礎去進行。

![設計與規格](//images.ctfassets.net/8er52l3j5u76/5bl7yRd7Vdz5mkDcNG0LbX/4f66270d70ecfe0e269fd94d9e67a5ee/spec.jpg)

因為 PIXI.js 在邊界（Bounded Context）是非常強的，基本上所有顯示物件都要放進去主要的容器中（PIXI.Stage）這其實會讓遊戲邏輯跟顯示邏輯嚴重的混合再一起，這也是大多遊戲引擎開發時會遭遇到的問題，因此最後我們直接把 PIXI.js 的部分當作獨立的邊界，只處理顯示（或者說輸出）的部分，剩下的邏輯都抽離出來用 Domain Event（領域事件）當作介面來交換資訊。

因此在圖上看到的 `Core.KeyboardEvent` 和 `Game.KeyboardEvent` 會是兩種不同的物件（TypeScript 中我們只定義了結構）讓不同領域的邏輯取用需要的部分。

## 重構驅動開發

因為我們不是使用遊戲引擎，因此要馬上的開始讓團隊成員看到成果是有一定困難的，因此開發流程比較類似於「重構驅動」的方式，先由西瓜在我們設計的框架下，從 PIXI.js 的輸出端放置美術的素材來跟團隊成員確認，接著繼續堆疊一些遊戲邏輯上去確保能照我們預期的運作，再由我來進行重構。

如果有適合的測試框架，像是前端可以使用 Cypress、Playwright 來做測試的話，前面的步驟基本上就是端對端測試（E2E Testing）來實踐驗收測試驅動開發的自動化版本，但是遊戲大多還沒有成熟的工具做這件事情，因此我們會用人工的方式實踐，這也是過程中壓力最大的一環。

在西瓜完成基本的邏輯後，我則是將這些遊戲邏輯重構，抽離到 Core Domain 裡面，再讓 RxJS 能以 Domain Event 的方式跟兩邊互動，這部分也比較完整的實踐了 Domain-Driven Design 的設計，因此都是以 Use Case 為基礎下去加入測試，最後就順利的保護整個遊戲邏輯。

>可能會有人好奇遊戲的 Use Case 是怎麼設定的？這個其實就是 Domain-Driven Design 的戰略部分，包含像是需求跟規格的轉換、事件風暴（Event Storming）的技巧，以遊戲來說我們會去「打怪」來做判定，那麼打怪就是一個 Use Case 接下來就是要根據遊戲條件實作像是打擊點、環境的資訊等等機制，來讓「打怪」可以被判定

## 還可以更快

結束後這幾天的回顧，我認為我們在開發上其實還能「更快」雖然有一些條件在台灣的 Global Game Jam 場地規則下不容易達成（一定程度隨機組隊）然而在開發上還是有不少可以改進。

首先我們略過了規格的部分，這點其實在遊戲開發中有不少吃虧的地方。像是轉換 Use Case 的部分，就有幾個實作最後被拔掉或者修正，因為我們在規格上沒有明確定義遊戲規則，最後讓程式在實作的時候「白費力氣」這也是 ATDD 的價值所在，我們先根據想看到的實現，再去拆分就比較不會有多餘的處理。

另一個則是我們的測試機制不完善，這也是大多數情況會認為「寫測試花時間」的原因之一，因為這個原因我們不得不放棄從遊戲畫面的部分開始做驗證，也就間接的讓規格變得模糊，因為我們沒有特別去想這個畫面在某個瞬間的狀態是怎樣，一段時間後又會如何，最後變得得靠多次的人工驗證才找出規律。

最後是熟練度，這應該是導入整個機制最困難的地方。假設整個團隊都有這樣的意識，我們很快就能拿到有精確規格的文件或者資料開始協作，同時我也不需要依靠跟西瓜一起工作的熟練度來達成這件事情，而是可以更細的拆分進行協作也不需要太多確認（我們在 24 小時後才有自動部署，如果一開始就有甚至可以請其他組員協助測試）那麼開發速度還能再更快。

當然，最後的問題是每個開發團隊都要面臨的狀況，而且我們在開發遊戲初期有不少需要驗證的地方，像是使用 FMOD 還是 MIDI 來作為基礎，因為是跟音樂相關的遊戲需要讀取到特定的節奏資訊等等，假設有一定程度的熟練度，應該可以用更短的時間內達成目標，這點就期待下次 Global Game Jam 我能找到更好的方法讓團隊成員快速進入狀況了！

> 這次也是我這麼多次參加結束後，還有動力去修改遊戲的的一次，因為架構規劃已經相對完善，可以在相對不費力的狀況下修改跟重構，也算是讓自己過去幾年研究這個主題的效果得到了一定程度的驗證。

> 本文引用自弦而時習之的[在 Game Jam（黑客松）寫測試有用嗎？](https://blog.aotoki.me/posts/2023/02/08/does-write-test-in-game-jam-is-useful/)
> 
> 如果你喜歡這篇文章，想要更深入了解技術，我們有開設蒼時弦也的 📒 「[開發必學的需求分析法](https://5xruby.tw/courses/system-and-requirement-analysis)」以及「[Rails 開發者的進階實戰](https://5xruby.tw/courses/rails-foundation-skills)」課程唷 ❤️️ 歡迎報名！

在 Game Jam（黑客松）寫測試有用嗎

在 Game Jam（黑客松）寫測試有用嗎？

Image by <a href="https://www.freepik.com/free-photo/elevated-view-laptop-with-various-alphabets-white-background_3317835.htm">Freepik</a>

# 寫好程式的方法 - 加入程式的脈絡

對脈絡（Context）比較有清晰的概念是在今年研究 Domain-Driven Design 的時候，這幾天剛好因為工作需要修正 Golang 的靜態分析警告，想到這其實也跟脈絡有些關係，因此這篇文章會來跟大家分享幾種常見的「程式脈絡」

## 什麼是脈絡

脈絡，在許多技術文章中我們也會用「上下文」來稱呼，簡單來說就是「背景資訊」例如一段「加入購物車」的程式碼，我們會有著「購物車存在」這樣的前提。

要對程式的脈絡有所理解，就需要知道「資料（Data）」和「資訊（Information）」的差異，在英文字典中，資訊的解釋是「the data with context（有脈絡的資料）」這樣的定義，那麼當我告訴你「繼續」的時候因為缺乏上下文你會不清楚要「繼續什麼？」然而有了脈絡，像是「在紅燈停下來，接下來繼續前進」就會知道可能是在路上行駛中。

## 程式語言的脈絡

其實程式語言的設計中，也會使用 Context 這個單字。像是作業系統中的 [Context Switching](https://blog.aotoki.me/posts/2022/12/16/write-better-program-by-add-the-context/) 或者程式語言的原始碼都很常看到這個單字，對於使用這些程式語言開發的工程師，最常見的應該就是函式（或者方法）本身。

```ruby
def context_a
  val = true
end

def context_b
  val = false
end

context_a
context_b
# val => nil
```

因為兩個函式有著各自的上下文，因此變數並不會互相影響，而呼叫他們的最外層（主程式）也有自己的上下文，因此無法存取到他們。

> 這也是為什麼我們需要利用參數（Parameter）來傳遞資訊，或者使用全域變數（Global Variable）來突破上下文的限制。

## 程式碼區塊的脈絡

除了每一個能夠成「上下文」的區段之外，一整段的程式碼也是有其脈絡存在的，這也是我在修改 Golang 靜態分析警告遇到最多的狀況。其實就是經常被爭辯的「空行」和「變數聲明」的使用，雖然在不同語言會有細微的差異，然而整體上來說還是具備其特性的。

```ruby
def pay_to(order:, credit_card:)
  payment = Payment.new(order: order)
  payment.use(:credit_card)

  service = CreditCardService.new(credit_card)
  service.authorize!(payment)
  service.capture!(payment)

  service.update(order) # => order.paid
end
```

以上面的例子，我們可以看到三個以上的脈絡資訊。

- `pay_to()` 表示了跟付款相關的邏輯，參數 `order` 和 `credit_card` 表示了可能跟電商有關，而且使用信用卡付款
- `Payment.new `的段落明確的聲明「使用信用卡」
- `CreditCardService.new` 的段落描述了透過某張信用卡，對某筆付款進行扣款的情報
- `service.update(order)` 的段落則是根據付款的結果，對訂單進行更新

假如我們沒有留下空行在這幾個段落之間，那麼要理解這裡有著「三階段的小步驟」就會變得困難。另一方面，如果把 `payment` 和 `service` 都放到方法的開頭一次性的聲明，也會讓理解後續的「這個變數從何而來」的難度增加。

## 物件的脈絡

小到一行程式碼，大到一整個系統都會有脈絡存在。也因此在 [Domain-Driven Design](https://blog.aotoki.me/posts/2022/10/21/my-understand-of-domain-driven-design/) 之中定義了「領域模型」跟「分層架構」的觀念，就是要讓我們專注於「物件的脈絡」這一件事情上。

以 Value Object（值物件）來說，他是一種「資訊」也就是具備脈絡的資料，因此我們在談論「金錢」的時候，會用「幣種」加上「總數」作為一個「情報單位」

```ruby
class Money
  attr_reader :currency, :amount

  def initialize(amount, currency:)
    @amount = amount
    @currency = currency
  end

  def +(other)
    raise ArgumentError, 'invalid currency' unless other.currency == currency

    Money.new(amount + other.amount, currency: currency)
  end

  # ...
end
```

因此我們就可以很清楚的知道處理的是金錢，而且在「幣種錯誤」的狀況下無法進行換算，近一步延伸出去，還可以討論到像是 Clean Architecture 的單一職責、MVC 框架的補充 [DCI（Data Context Interaction）](https://blog.aotoki.me/posts/2022/12/16/write-better-program-by-add-the-context/)等等不同的議題，而一個系統的「架構」也是基於脈絡所構成，因此當我們在實作一個功能時沒有考慮到脈絡，就會讓整個系統變得難以理解。

## 用脈絡設計系統

假設我們用「電商網站」作為一個系統的開發目標，在沒有脈絡的狀況下我們只會將各種「電商」要素加入到這個系統中，然而有脈絡之後，可能會更清楚的知道「這是一站式網站」「使用者只會購買一種商品」等等資訊，那麼在設計的過程中就會更加清晰。

這也是實踐 Domain-Driven Design 過程中會發現的一個面向，因為我們想要畫分出 Bounded Context（上下文邊界）其實就是在整個大的系統中，繼續細分到一個「恰當的」資訊群組來一起處理這些問題。

從產品的角度 UX（使用者體驗）的使用者研究，也是在尋找「行為」上的脈絡，我們從不同的來源搜集情報並且加以彙整，最後就能找到一條符合產品需要的脈絡，進而實現更加「正確」的應用軟體。

> 這樣來看，整個程式的設計跟撰寫「小說」其實是一樣的，我們需要定義角色、場景、物件等等不同的資訊資訊，然後讓他們在舞台上互動，只不過換成軟體後變成用「物件」去定義出整個故事的要素，然後讓他動起來。

本文引用自[弦而時習之](https://blog.aotoki.me/)的[寫好程式的方法 - 加入程式的脈絡](https://blog.aotoki.me/posts/2022/12/16/write-better-program-by-add-the-context/)

如果你喜歡這篇文章，想要更深入了解技術，我們有開設蒼時弦也的 📒 「[開發必學的需求分析法](https://5xruby.tw/courses/system-and-requirement-analysis)」以及「[Rails 開發者的進階實戰](https://5xruby.tw/courses/rails-foundation-skills)」課程唷 ❤️️ 歡迎報名！

寫好程式的方法 - 加入程式的脈絡

Image by <a href="https://www.freepik.com/free-photo/close-up-man-writing-code-laptop_7621115.htm">ArthurHidden on Freepik</a>

# 用 Ruby 的 Mixin 加入脈絡增加可讀性

大多數使用過 Ruby 的工程師都知道 Ruby 有一個特別的語言特性叫做 Mixin（混合）可以透過定義一個 Module（模組）然後被其他類別引用，如果從 DCI（Data Context Interaction）的角度來看，其實是一種脈絡的表現。

## Mixin 的運作

Ruby 的 Mixin 運作機制大致上來說不複雜，我們可以使用 `include` 、 `extend` 以及 `perpend` 這三個方法根據情境「插入模組」到繼承鏈之中，以比較常用的 `include` 為例子會像這樣。

```ruby
module Attackable
  def attack(target)
    # ...
  end
end

class Actor
  include Attackable
end

pp Actor.ancestors
# => [Actor, Attackable, Object, Kernel, BasicObject]
```

簡單來說 Mixin 的運作是將原本搜尋方法的順序改變，從 `Actor` 到 `Object` 的順序中，加入了` Attackable` 模組，因此就可以搶在 `Object` 之前找到 `#attack` 方法來使用，而 `prepend` 和 `extend` 則是跟 `include` 插入到不同的位置來達到不同的效果。

## Ruby on Rails 的脈絡呈現

若是要舉例，用 Ruby on Rails 會容易些，因為在框架的設計上就有很深入的考慮到 DCI 的概念，如果還不清楚可以參考[自然地在 Rails 中應用 Data Content Interaction](https://blog.aotoki.me/posts/2022/10/28/use-data-context-interaction-natively-in-rails/) 這篇文章的簡介。

大多數時候，我們的 Controller 就是作為「描述脈絡」的角色，因此通常會看到如下的實現。

```ruby
class AttackController < ApplicationController
  before_action :find_player
  before_action :find_activate_battle

  def create
    @monster = @battle.monsters.find(params[:monster_id])
    @battle.attack(
      from: @player,
      target: @monster
    )
    @battle.save!

    render json: @battle.events
  end

  # ...
end
```

如果我們轉換成 Cucumber 的描述，就可以變成類似這樣的敘述

```
#language: zh-TW
功能: 戰鬥系統
  # AttackController
  場景: 玩家對指定怪物發起攻擊
    # before_action :find_player
    假定 這裡有一個玩家 "蒼時"
    # before_action :find_activate_battle
    而且 這裡有一個進行中的戰鬥
      | name    | monster_id | monster_type |
      | Slime-1 | 1          | Slime        |
    # @battle.attack(...)
    當 玩家對名為 "Slime-1" 的怪物攻擊
    # render json: @battle.events
    那麼 將會看到 "Attack Slime-1 success" 的結果
```

由此可見，像是 `before_action` 這些 DSL（Domain Specific Language，領域特訂語言）能夠用於「描述脈絡」而使用的。

如果想要擴充這些行為，在 Rails 可以使用基於 Ruby Mixin 所設計的 Concern 機制來增加可以用的「描述方式」

## Mixin 的使用案例

要利用 Mixin 來增加脈絡的資訊，就用我最近針對 Feature Flag（特性切換）的實作來作為例子。

我使用的是 [Flipper](https://www.flippercloud.io/) 這個套件，他能讓我使用類似這樣的方式保護某個尚未釋出的功能。

```ruby
def index
  raise UnreleasedError unless Flipper.enabled?(:preview, current_user)

  # ...
end
```

假設不是指定的使用者，就無法使用「預覽版（Preview）」的功能，然而要在每個地方都重複寫 `Flipper.enabled`? 其實是有點麻煩的，因此大多數人都會封裝成一個方法。

但是，如果考慮到「脈絡」跟「DSL」的特性，我們會實現像這樣的 Concern 模組。

```ruby
module Previewable
  class UnreleasedError < RuntimeError; end

  extend ActiveSupport::Concern

  included do
    helper_method :preview?
  end

  class_methods do
    def unreleased(**options)
      before_action -> { raise UnreleasedError unless preview? }, **options
    end
  end

  def preview?
    Flipper.enabled?(:preview, current_user)
  end
end
```

在這裡我們利用 `extend` 讓這個模組可以使用 `ActiveSupport::Concern` 的機制，這點大家應該不陌生，這其實就已經是一種脈絡的表現用來表明「這是一種 Concern」而我們會自然地使用 `included` 和 `class_methods` 這兩個 DSL 來描述。

首先，我們先將 `Flipper.enabled?` 封裝成 `preview?` 來加強語意，接下來用 `included` 透過 `helper_method` 聲明「可以被 View 使用」同時在 class_methods 中定義了新的 DSL 叫做 `unreleased`（未釋出），他會在這個 Controller 開始前檢查「是否可以使用這個動作」

放到 Controller 裏面，就會發現「可讀性被提高」

```ruby
class AutoAttackController < ApplicationController
  # 表示「包含預覽」
  include Previewable
  # 描述未釋出的部分，除了 index 動作外
  unreleased except: %i[index]

  def index
    # 如果是預覽模式，用不同畫面呈現
    return render :index_v2 if preview?

    # ...
  end

  # ...
end
```

基於 Mixin 的方式，我們會發現對於整個 Controller 的行為描述變的非常清晰，我們可以透過 DSL 的擴充對整個情境補充，或者方法來提供這個情境可以「做特定行為」

> 也許我們該反思，許多時候我們利用 Rails 的 Callback 機制（before_action）是否是在描述「前提」還是單純的想把過長的重複程式碼分離出去

本文引用自[弦而時習之](https://blog.aotoki.me/)的[用 Ruby 的 Mixin 加入脈絡增加可讀性](https://blog.aotoki.me/posts/2023/01/11/the-ruby-mixin-can-describe-the-context/)

如果你喜歡這篇文章，想要更深入了解技術，我們有開設蒼時弦也的 📒 「[開發必學的需求分析法](https://5xruby.tw/courses/system-and-requirement-analysis)」以及「[Rails 開發者的進階實戰](https://5xruby.tw/courses/rails-foundation-skills)」課程唷 ❤️️ 歡迎報名！

用 Ruby 的 Mixin 加入脈絡增加可讀性

過去是平面設計師的 Tim，面對工作瓶頸和疫情衝擊，興起轉職的念頭。在這轉職的歷程中，遭遇很多挫折，卻也受到很多人的支持和協助，而 Tim 是如何逐步實踐前端夢想呢？

Nothing is Impossible!
如今，成功轉職成前端工程師的 Tim，找到一份讓生活和家庭平衡的工作，並出版了電腦技術書 『 Tailwind CSS 3.0 從零開始 - 入門到實戰』書中和大家介紹新世代排版神器 —— Tailwind CSS，並分享實作上會遇到的問題，讓團隊可以有效提升開發效率。

五倍紅寶石這次很榮幸邀請到 Tim 來到五倍直播間和大家分享，這條探索到成就自我的出版之路的甘苦談，如果你也在職涯之路徬徨，或是你還在努力地往前端工程師這個夢想前進，透過 Tim 的經驗，讓你在設定職涯目標不迷網。

## 講者介紹

許智庭 Tim Hsu | 前端工程師
從事平面設計七年，目前為前端工程師，開發經驗三年，樂於分享新知與所學技術，「提姆寫程式」部落格作者。

## 從鐵人賽到 Tailwind CSS 的出書之路

![Tailwind CSS Book](//images.ctfassets.net/8er52l3j5u76/1YIy6niBqUOluDT52xbrMg/d0ac4009995781df8e8dded99d34d85a/book.jpg)

如果你也想提升切版技術力，從初階到進階必學的排版神器！[Tailwind CSS 3.0 從零開始 - 入門到實戰](https://www.tenlong.com.tw/products/9786267146460?list_name=lv)是你最強的參考書籍。

### 持續寫文章對自己有什麼幫助？

一開始會覺得這些技術已經有許多人寫過了，甚至文章內容寫得比我還要好，出現「為什麼我還要寫技術文章」這樣的心態？後來想想，寫文章最重要的是幫助自己，倘若在一個月或三個月後，遇到相同的技術問題，發現之前自己已經有針對此問題寫筆記，再重新複習，說不定能解決技術卡關的狀況，這樣就是對自己最好的幫助，也不需擔心文章寫得好與不好。

透過文字可以把當下遇到的情境以及想要學習的觀念寫下，將吸收的知識內化成理解的知識，在書寫過程中，輸出成文字，其實也是在整理你的邏輯思考與言詞。

畢竟，程式有太多東西要學，但每天需要處理的事情太多，而無法記得所有的技術知識，寫文可以幫助自己整理所學以及成為自己的技術字典。

### 從個人學習筆記到撰寫成文章再到教學書籍，這之間你認為有什麼樣的差異？

個人筆記就屬「個人」，不會有太多包袱，因為主要幫助對象是自己，記錄筆記的當下，多是閱讀他人的文章或是技術教學影片，而如實地呈現你所學的內容。但是，教學書籍的內容就需要言之有物了，畢竟出版品具有一定效力，在用字遣詞上以及資料考究都需要更加謹慎與精準，因為出版品無法在短時間內修改，如果誤人子弟就不好了。

### 這本書你覺得適合什麼樣的讀者呢？

《Tailwind CSS 3.0 從零開始 – 入門到實戰》這本書籍中，整理了明確的開發方式與基礎核心知識，讓開發者能較快上手 Tailwind CSS。

適合有實戰過 CSS 的開發者，因為對 CSS 有基本概念，也熟悉常用的語法，不需一直查詢想使用的樣式，不管是自己個人 side project 或是現在的工作上有碰到，而且自己能獨立手刻完成 RWD CSS 樣式的話，對於這本 Tailwind CSS 技術工具書較能快速吸收。

## 工程師聊技術

### 你如何看待 Tailwind、Bootstrap 和純手刻 CSS？

Tim 認為需要看專案的性質來定義，他認為 Bootstrap 像是一次性的 Landing Page，有許多元件化的模組所組成，可以透過元件反覆堆疊能快速組成一個網站，相對的，一次性網頁也不需要後續的維護。

純手刻的 CSS，比較像是客製化的網頁，像是大型的專案。

而，Tailwind CSS 是比較屬於純手刻的進階版，手刻 CSS 需要一直命名 class name，再將 CSS 的樣式寫進 class name 裡，除了難閱讀外，檔案也比較大，這樣的開發效率低。透過 Tailwind CSS，解決命名困擾，不需要撰寫冗長的 CSS，增加可讀性，能提升開發效率。

### 學 Tailwind 會需要對 CSS 有一定的基礎嗎？建議新手直接先從 Tailwind 學起嗎？

不建議新手直接學習 Tailwind CSS，因為 Tailwind CSS 是 CSS 框架，基礎概念是從 CSS 開始，程式新手還是要把基本功練好，紮穩基礎後再挑戰更進階的框架工具會比較適合。

### 你如何規劃 Tailwind 學習路徑？

Tim 認為可以從官方文件開始閱讀，且官方文件也寫得相當清楚，包含使用 npm 安裝、運作方式、設定方式等，只要了解如何起手，並跟著範例實作，能快速掌握 Tailwind CSS 的基礎，也可以利用 Tailwind CSS 執行基本開發。對於比較深且難的技術部分則需要繼續找尋相關文件閱讀。

### Tailwind 是不是在網路上就有足夠的資源可以學習呢？網路有蠻多類似課程，不確定是否需要實體課來讓自己學會 Tailwind？

其實任何一門程式語言都是一樣的，端看自己決定想要以什麼方式學習程式，如果想要快速上手，可以找尋有系統性的方式來學習，不管是線上課程、實體課程，甚至是以書籍進修，找到一個可依賴的資源或是課程來幫助你入門程式，當你擁有一定的開發經驗後，再去看官方文件，慢慢地也可以自學起來。

如果你也想精深 coding 能力，五倍有開設眾多[實體課程](https://5xruby.tw/courses)，很歡迎報名課程精進你的技能。

## 工程師生存的力量

### 兼顧生活、工作、學習的方法？

Tim 因為家庭、小孩又有工作的狀況下，能學習的時間相對少也非常零碎。Tim 是花了一年的時間利用線上課程與實體課程來學習程式，以定時定量來規劃工作與學習時間，每天固定時間學習程式，並改變原本的生活，將飲食單一化，休閒娛樂的時間改為練習程式，就發現學習時間變多了，這樣的生活其實是需要相當高的自律，才有辦法達成。 

### 當你想轉職去面試前端的時候，做了哪些事前準備與克服不同領域的面試壓力呢？

之前在面試時有遇過面試官問「你都已經有年紀了，為什麼現在才要寫程式？」當下Tim 覺得自己好像真的很菜，也會自卑。

Tim 認為能做的準備就是將心理建設好，因為是轉職者，沒有這工作領域的經驗，因為程式開發需要靠經驗累積，所以無法與面試官闡述哪些技術是精通的，所學的知識是從線上課程與實體課程中得到，可能無法立即運用在工作情境中。遇到這樣的面試問題只能放寬心，誠實面對自己，讓對方知道自己就是新手，不過也要讓對方知道你是有潛力能成為一位優秀工程師。

### Tim 是平面設計師跨領域轉職前端工程師，在鐵人賽也有一系列的轉職心得文，你會給正在迷惘的大家什麼建議嗎？

轉職其實本身需要很大的勇氣，面對轉職這件事，沒有最好的決定，但是既然已決定就需要努力做到最好。在轉職路上遇到的困難與挑戰，也許會比想像中多很多，需要時刻保持開放的心，保持正向與挫折相處，就算是進入職場，也是有許多時間需要與挫折相處，當你解完這個 bug 後又會有下個  bug 出現，要享受寫 code 的過程，能學習到更多技術。

## 小結

![Tailwind CSS on Youtube](//images.ctfassets.net/8er52l3j5u76/6lzcLYu766SQLzDIQP4oXQ/06b7cd525295708885686e98e441b25b/youtube-cover.jpg)

以上摘錄五倍紅寶石在今年 10 月的[【直播分享會】鐵人鍊成！從平面設計跳轉程式領域，步步實踐前端夢想之路](https://www.youtube.com/watch?v=pO4KwsFU_rc&t=329s)。

希望這場包含技術主題與轉職心路歷程的直播，對於正在轉職路上前進，或是還未出發，但想往程式領域前進的你，帶給你幫助與收穫。

如果你也希望透過習得一技之長來翻轉職涯，歡迎認識 [ASTRO Camp 全端工程師訓練營](https://astro.5xruby.tw/)。

平面設計師踏入程式領域，走上前端技術的道路

> 我是一個熱愛設計、喜歡嘗試新事物、不斷學習的人。

從小，就對任何視覺圖片或符號文字感興趣的我，一頭栽進了設計文化這個領域裡，除了平常會閱讀大量與設計、平面、美感相關的書籍，假日也時常去藝文景點或展覽會場參觀。我的第一份工作就是在設研院齊下的「不只是圖書館」品牌擔任企劃與小編的角色，負責統籌與近期展覽相關的衍生活動與傳遞設計閱讀知識給大眾。

在一次偶然遇到品牌整合到設研院齊下的情況中，原本松菸口的官網也被迫取消並重新改版，而重新改版後的品牌官網也讓我思考到說是否有能更加以優化的部份。

> 於是，基於對網頁視覺效果及渲染力的好奇心下，我參加了五倍紅寶石的『[網頁前端設計女性專班](https://5xruby.tw/courses/code-for-girl)』。

帶領我們的是業界經驗豐富的 Amos 講師，不僅在各大教學平台可以看到他的身影，他自己也擁有自己的 YouTube 教學頻道，讓各大年齡層、甚至是沒有學習過 HTML、CSS 的人，都能透過簡單的介面環境，進入非程式語言的世界。

➥ 以下是紅寶石的女性前端課程大綱

```
Day 01. 初識網頁
    ⇒ 網頁是什麼？
    ⇒ 前端設計師或工程師會運用到的工具有哪些？
    ⇒ VS Code 下載及架設的必要外掛裝置

Day 02. ＨＴＭＬ 的起手式
    ⇒ HTML 的標籤及語法功能
    ⇒ 網頁色碼的基礎教學與運用（包含 RGB、HSL、Hex )
    ⇒ 基本圖片插入學習與網頁互連運用

Day 03. ＣＳＳ 風格頁面語言學習及注意事項
    ⇒ 權重的重要性及如何影響網頁渲染力
    ⇒ 常用選擇器介紹與實作
    ⇒ box-sizing 盒模型的重要性

Day 04. 網頁排版實作     
    ⇒ Float 及 Flex 的介紹       
    ⇒ CSS Reset / Normalize 操作
    ⇒ CSS 動畫實作（Transition 及 Animation 介紹）

Day 05. 網頁框架教學及課堂作業檢討
    ⇒ Bootstrap 介紹與使用方式、網格系統的重要性
    ⇒ 檢討業界常切版型與效率提升方法

Day 06. 結業式
    ⇒ 網站作業分享
    ⇒ Javascript 進階教學
    ⇒ Q&A
```

> 製作網頁其實沒有想像中的那麼難，只是你必須要先搞懂箇中翹楚，不然會花費很多時間在了解電腦跑出來的畫面及除錯。

我還記得，在前幾堂 HTML & CSS 的基本課程中，學習的倒算快也能理解，但當講師講解到盒模型的部份時，倒算有點小卡住也需特別思考網頁的架構邏輯 – – 像是使用 padding 跟 margin 的不同，會造成網頁的編排效果及後續RWD 在伸縮畫面時的編排位置。

![from-planner-to-frontend-developer-01](//images.ctfassets.net/8er52l3j5u76/4Kkni8dVD9Od0PnxpZUJP7/1b63aeae67a84f1cf6bdfc8e6fb85f02/from-planner-to-frontend-developer-01.png)

※ 老師有提醒過，在做所有設計前，都要先列好網頁每一塊布局的尺寸大小，否則會花費很多時間在微調位置。

![from-planner-to-frontend-developer-02](//images.ctfassets.net/8er52l3j5u76/2sITgB7VgjNZv2pnP94JlP/25697f7e6d1905313702beec5488d872/from-planner-to-frontend-developer-02.jpeg)

※ 以這一塊基礎版型為例，當我們確定了網頁置中的位置後，左右兩邊的 padding 要記得預留空間 – – 而卡片與卡片之間的 margin 也必須要拉出來，因為 margin 主要處理的是「物件與外在環境之間的空間」，所以在使用 margin 或 padding 上，要格外小心。

>最後當自己製作的作品成功出現在網頁上時，那種成就感是難以言喻的！

經歷過 box-sizing、flex、CSS 動畫、Bootstrap 的洗禮之後，重新思索如何將所學到的知識包套用到最後產出的專案中 – – 最後以符合品牌調性的蔚藍色為主色調，搭配點選卡片就產生陰影的並排效果來呈現其所提供的服務項目及知識技能樹，期望讓看到網頁的民眾能立刻搜尋到他們所想找到的目標並提供精準的知識傳遞。

Youtube 連結：[專案作品—不只是圖書館官網再設計](https://www.youtube.com/watch?v=hnfWB0XYV9w)

> 然而，課程的結束並不是學習的結束，前端仍有許多未知的領域等著自己去發掘！

如同學習任何專精的領域，一項技能要達到熟練的程度需仰賴每天不斷的練習 – – 積少成多、聚沙成塔。相信透過練習，自己對網頁的熟練程度也會越來越好！

---

全文引用自 Michelle Tien 的 Medium 文章 - [以企劃身份踏入網頁前端的第一步](https://medium.com/@michelletien0521/%E4%BB%A5%E4%BC%81%E5%8A%83%E8%BA%AB%E4%BB%BD%E8%B8%8F%E5%85%A5%E7%B6%B2%E9%A0%81%E5%89%8D%E7%AB%AF%E7%9A%84%E7%AC%AC%E4%B8%80%E6%AD%A5-b61d9b612e38?_branch_match_id=1052809644765978058&_branch_referrer=H4sIAAAAAAAAA8soKSkottLXz8nMy9bLTU3JLM3VS87P1Q9PDff39C0zCClMAgD%2B0KfeIwAAAA%3D%3D)。
