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

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

什麼是脈絡

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

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

程式語言的脈絡

其實程式語言的設計中，也會使用 Context 這個單字。像是作業系統中的 Context Switching 或者程式語言的原始碼都很常看到這個單字，對於使用這些程式語言開發的工程師，最常見的應該就是函式（或者方法）本身。

def context_a
  val = true
end

def context_b
  val = false
end

context_a
context_b
# val => nil

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

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

程式碼區塊的脈絡

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

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 之中定義了「領域模型」跟「分層架構」的觀念，就是要讓我們專注於「物件的脈絡」這一件事情上。

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

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）等等不同的議題，而一個系統的「架構」也是基於脈絡所構成，因此當我們在實作一個功能時沒有考慮到脈絡，就會讓整個系統變得難以理解。

用脈絡設計系統

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

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

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

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

本文引用自弦而時習之的寫好程式的方法 - 加入程式的脈絡

如果你喜歡這篇文章，想要更深入了解技術，我們有開設蒼時弦也的 📒 「開發必學的需求分析法」以及「Rails 開發者的進階實戰」課程唷 ❤️️ 歡迎報名！